[RFA] Fix regression introduced in "break *<EXPR>" by explicit location patches (was: "Re: [PATCH v6 4/9] Explicit locations: introduce address locations")

  >  > gdb/ChangeLog:
>  >
>  >         * location.h (new_address_location): Add new parameters
>  >         "addr_string" and "addr_string_len".
>  >         (get_address_string_location): Add declaration.
>  >         * location.c (new_address_location): Add new parameters
>  >         "addr_string" and "addr_string_len".  If not NULL, store
>  >         a copy of the addr_string in the new location as well.
>  >         (get_address_string_location): New function.
>  >         (string_to_event_location): Update call to new_address_location.
>  >         * linespec.c (event_location_to_sals) <ADDRESS_LOCATION>:
>  >         Save the event location in the parser's state before
>  >         passing it to convert_address_location_to_sals.
>  >         * breakpoint.c (create_thread_event_breakpoint): Update call
>  >         to new_address_location.
>  >         (init_breakpoint_sal): Get the event location's string, if any,
>  >         and use it to update call to new_address_location.
>  >         * python/py-finishbreakpoint.c (bpfinishpy_init):
>  >         Update call to new_address_location.
>  >         * spu-tdep.c (spu_catch_start): Likewise.
>  >
>  >         * config/djgpp/fnchange.lst: Add entries for
>  >         gdb/testsuite/gdb.base/break-fun-addr1.c and
>  >         gdb/testsuite/gdb.base/break-fun-addr2.c.
>  >
>  > gdb/testsuite/ChangeLog:
>  >
>  >         * gdb.base/break-fun-addr.exp: New file.
>  >         * gdb.base/break-fun-addr1.c: New file.
>  >         * gdb.base/break-fun-addr2.c: New file.
>  >
>  > Tested on x86_64-linux.
>  > +const char *
>  > +get_address_string_location (const struct event_location *location)
>  > +{
>  > +  gdb_assert (EL_TYPE (location) == ADDRESS_LOCATION);
>  > +  return EL_STRING (location);
>  > +}
>  > +
>  > +/* See description in location.h.  */
>  > +
> 
> Given that the argument must be an address location,
> "get_address_location_string" reads better to me.

I am not sure what my exact thinking was, at the time, and
whether it was flawed or not, but I chose the naming at the time
to be consistent with the other functions that looked similar in
they functionality. The ideal name for the function would probably
be something like "get_address_string_from_location", in other
words, what I meant is to return the "address string" (as opposed
to the address itself).

For now, I pushed the patch as is, but if you think the name
should be changed, here is a patch that does that. So, it's ready
to go in, if you give the signal.

What I would (counter-)propose, on the other hand, is that we
look at renaming the function to use "_from_location". Or, maybe
have the functions start with "location_" (Eg:
location_get_address_string, which actually might be closer
to our typical namespace strategy).