gdb: fdpic/frv: fix shared library loading
authorMike Frysinger <vapier@gentoo.org>
Fri, 16 Apr 2010 22:47:42 +0000 (22:47 +0000)
committerMike Frysinger <vapier@gentoo.org>
Fri, 16 Apr 2010 22:47:42 +0000 (22:47 +0000)
commitcb7db0f2a917b4fe945f091f665f5eb1800e0e20
treeaa263a5edadeb22050afb4b3c2e9426ebe014976
parentd77b48cf13221fee2bd7047d12f5594db3127cb3
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