OSDN Git Service

gdb: fdpic/frv: fix shared library loading
authorvapier <vapier>
Fri, 16 Apr 2010 22:47:42 +0000 (22:47 +0000)
committervapier <vapier>
Fri, 16 Apr 2010 22:47:42 +0000 (22:47 +0000)
commitd83e0e35daa4ca60c7bcecd2055309dd899458db
tree0e542d4948072fed509dabc8598509722b9e39ce
parent7393a49764ebce0971bc6f08d88aba75c358ab3f
gdb: fdpic/frv: fix shared library loading

The recent change to reload_shared_libraries() broke FDPIC shared libraries as
the solib-frv.c code was implicitly relying on the initial order of calls
(first solib_addr() and then solib_create_inferior_hook()).  It was
maintaining internal state via enable_break{1,2}_done to handle this.

While I could tweak these values a bit more, the original code wasn't terribly
bullet proof -- if during the initial debug you attempted to view shared
libraries, the enable2_break() code would whine about the ldso internal debug
addresses being unfetchable (and would actually attempt to read address 0x8 on
the target).  So I've dropped this implicit dependency on order (i.e.
enable_break1_done) and updated the ldso poking code (i.e. enable_break2) to
silently return when the internal debug address is still set to 0.  It will
remain this way until the ldso gets a chance to initialize at which point the
code will act the same as before.

While I have no way of testing the FRV, the Blackfin FDPIC code is using this
same base in a 100% copy & paste method since we implemented FDPIC the same
way as the FRV guys (I'll address this in the future).  This fix was required
in order to handle shared libraries with Blackfin FDPIC properly, and I see no
reason why it wouldn't also work for FRV (since the uClibc ldso FDPIC code is
the same too and that's really what this is poking).

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
gdb/ChangeLog
gdb/solib-frv.c