Re: gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform?

Re: gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform?

[Daniel Jacobowitz]

On Fri, Jan 23, 2004 at 02:15:28PM -0800, John Utz wrote:
> > Strace gdb if necessary to see what it finds.
> 
> that was interesting, and supports your argument, note that it's
> loading the host thread_db, and the correct target libpthread.so.0
> 
> [johnut01@gbcxdev johnut01]$ grep thread stracegdb.txt
> open("/lib/tls/libthread_db.so.1", O_RDONLY) = 3
> open("/home/johnut01/GBCX/crosstool-0.25/result/i486-unknown-linux-gnu/gcc-2.95.3-glibc-2.2.5/i486-unknown-linux-gnu/lib/libpthread.so.0",
> O_RDONLY) = 8
> stat64("/home/johnut01/GBCX/crosstool-0.25/result/i486-unknown-linux-gnu/gcc-2.95.3-glibc-2.2.5/i486-unknown-linux-gnu/lib/libpthread.so.0",
> {st_mode=S_IFREG|0755, st_size=464868, ...}) = 0
> open("/home/johnut01/GBCX/crosstool-0.25/result/i486-unknown-linux-gnu/gcc-2.95.3-glibc-2.2.5/i486-unknown-linux-gnu/lib/libpthread.so.0",
> O_RDONLY) = 11
> 
> it doesnt appear to me that solib-absolute-prefix has anything to do
> with what libthread_db gdb loads, and from what little i understand
> about sharedlibs under linux, it's not *supposed* to.
> 
> as i understand it the solib* variables manage the 'internal universe'
> of gdb and by implication, gdbserver.
> 
> but which sharedlibs the linker chooses to use to resolve gbd's needs
> from the 'external universe' isnt manageable from inside of gdb...this
> looks like a job for LD_LIBRARY_PATH ( boo, hiss! )????

Sorry, I misspoke, it doesn't matter what libthread_db the client uses. 
My concern was actually that it loads the correct libpthread.so.

If it's still segfaulting you've found a new or unique problem.  You'll
have to figure out what gdbserver is doing :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform?

[Daniel Jacobowitz]

On Fri, Jan 23, 2004 at 09:13:05PM -0800, John Utz wrote:
> if i take my libpthread-0.9.so and copy it to libpthread-0.9.so.db and
> then *strip* libpthread-0.9.so i can run  'share' successfully, ie not
> crash gdbserver.

This process just serves to disable gdb threads support.

> failing that, how do i debug gdsbserver?

With strace and gdb! :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform?

[John Utz]

Hi again, more informatoin....

>>> Daniel Jacobowitz <drow@mvista.com> 01/23/04 02:50PM >>>
> If it's still segfaulting you've found a new or unique problem. 
You'll
> have to figure out what gdbserver is doing :)

ok, so here's a slight improvement, but still weird...hope that it
might jog your brain....

if i take my libpthread-0.9.so and copy it to libpthread-0.9.so.db and
then *strip* libpthread-0.9.so i can run  'share' successfully, ie not
crash gdbserver.

that's good.

of course, this means that i have no symbols for libpthread-0.9.so.

But, better yet. i can do an add-symbol-file on the
libpthread-0.9.so.db and *not* crash gdbserver and get symbols for
libpthread-0.9.so!!

But, the bad news is that i then get a noncrashing error from gdbserver
when i do this:

gdb: Unable to set global thread event mask: generic error

then, if i step thru my sample thread app i suddenly get an apparent
infinite loop of something..i think, because i get a SIGSEV.

when i do a bt it
shows that i am in longjmp:
#0 0x4001a3c2 in longjmp
#1 0xffffffff in ?? ()
<...>
#4345 0xffffffff in ?? ()
#4346 0xffffffff in ?? ()
#4347 0xffffffff in ?? ()
<...> and on and on until i reboot the target...

does this collection of facts provide any additional insight?

failing that, how do i debug gdsbserver?

tnx!

johnu

Re: gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform?

[John Utz]

Further information:

>>> Daniel Jacobowitz <drow@mvista.com> 01/23/04 12:34PM >>>
> On Fri, Jan 23, 2004 at 12:32:18PM -0800, John Utz wrote:
> 
> problem i am having is that when gdbserver tries to load the symbols
> for for libpthread-0.9.so, it segfaults.
>
> It doesn't matter what's on your search path on the _TARGET_.  The
> segfault is usually a symptom that the libthread_db loaded on the
> _HOST_ does not match the one in use on the target system.
>
> Google for solib-absolute-prefix.

went to the manual. :-)

here's my updated .gdbinit

[johnut01@gbcxdev johnut01]$ more .gdbinit
define rstpc
set solib-absolute-prefix
/home/johnut01/GBCX/crosstool-0.25/result/i486-unknown-linux-gnu/gcc-2.95.3-glibc-2.2.5/i486-unknown-linux-gnu/
set solib-search-path
/home/johnut01/GBCX/allegro4.0.3/:/home/johnut01/GBCX/gbc
x-cvs-tree/gbcxlinux/mas-seatapi
file /home/johnut01/GBCX/noa/gbcxLinux
target remote dseb:2345
break main
continue
#share
#break dlopen
#c
end


> Strace gdb if necessary to see what it finds.

that was interesting, and supports your argument, note that it's
loading the host thread_db, and the correct target libpthread.so.0

[johnut01@gbcxdev johnut01]$ grep thread stracegdb.txt
open("/lib/tls/libthread_db.so.1", O_RDONLY) = 3
open("/home/johnut01/GBCX/crosstool-0.25/result/i486-unknown-linux-gnu/gcc-2.95.3-glibc-2.2.5/i486-unknown-linux-gnu/lib/libpthread.so.0",
O_RDONLY) = 8
stat64("/home/johnut01/GBCX/crosstool-0.25/result/i486-unknown-linux-gnu/gcc-2.95.3-glibc-2.2.5/i486-unknown-linux-gnu/lib/libpthread.so.0",
{st_mode=S_IFREG|0755, st_size=464868, ...}) = 0
open("/home/johnut01/GBCX/crosstool-0.25/result/i486-unknown-linux-gnu/gcc-2.95.3-glibc-2.2.5/i486-unknown-linux-gnu/lib/libpthread.so.0",
O_RDONLY) = 11

it doesnt appear to me that solib-absolute-prefix has anything to do
with what libthread_db gdb loads, and from what little i understand
about sharedlibs under linux, it's not *supposed* to.

as i understand it the solib* variables manage the 'internal universe'
of gdb and by implication, gdbserver.

but which sharedlibs the linker chooses to use to resolve gbd's needs
from the 'external universe' isnt manageable from inside of gdb...this
looks like a job for LD_LIBRARY_PATH ( boo, hiss! )????

feel free to humilate me publicly if i have this wrong and there is a
solution other than the one i propose..... :-)

tnx!

johnu 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform?

[John Utz]

Hi Daniel!

tnx so much for responding.

>>>> Daniel Jacobowitz <drow@mvista.com> 01/23/04 12:34PM >>>
>On Fri, Jan 23, 2004 at 12:32:18PM -0800, John Utz wrote:
>> Hi;
>> problem i am having is that when gdbserver tries to load the
symbols
>> for for libpthread-0.9.so, it segfaults.
>> 
>> it seems to not matter *which* libthread_db.so i stuff into my
search
>> path on the target
>
> It doesn't matter what's on your search path on the _TARGET_.  The
> segfault is usually a symptom that the libthread_db loaded on the
> _HOST_ does not match the one in use on the target system.

remarkably interesting! what does gdbserver us thread_db for? i noticed
that when i puposefully deleted -lthread_db it actually only uses a few
calls from libthread_db....if you could enlighten me about that i would
be really grateful.

> Google for solib-absolute-prefix.  Strace gdb if necessary to see
what
> it finds.

i'll do this ASAP!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform?

[Daniel Jacobowitz]

On Fri, Jan 23, 2004 at 12:42:25PM -0800, John Utz wrote:
> Hi Daniel!
> 
> tnx so much for responding.
> 
> >>>> Daniel Jacobowitz <drow@mvista.com> 01/23/04 12:34PM >>>
> >On Fri, Jan 23, 2004 at 12:32:18PM -0800, John Utz wrote:
> >> Hi;
> >> problem i am having is that when gdbserver tries to load the
> symbols
> >> for for libpthread-0.9.so, it segfaults.
> >> 
> >> it seems to not matter *which* libthread_db.so i stuff into my
> search
> >> path on the target
> >
> > It doesn't matter what's on your search path on the _TARGET_.  The
> > segfault is usually a symptom that the libthread_db loaded on the
> > _HOST_ does not match the one in use on the target system.
> 
> remarkably interesting! what does gdbserver us thread_db for? i noticed
> that when i puposefully deleted -lthread_db it actually only uses a few
> calls from libthread_db....if you could enlighten me about that i would
> be really grateful.

It uses it for those calls, of course.  Specifically, to locate new
threads after pthread_create.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform?

[John Utz]

Hi;

i am using crosstool to build a complex app on a i686-unknown-linux-gnu
redhat 9 for a i486-unknown-linux-gnu redhat 7.3-ish( it's a somewhat
custom build, as near as i can tell).

problem i am having is that when gdbserver tries to load the symbols
for for libpthread-0.9.so, it segfaults.

it seems to not matter *which* libthread_db.so i stuff into my search
path on the target, it can be the one from rh9, or the one that i built
with crosstool, or the one that the system integrator has lying around
on the server-parent box :-)

i've been using gdbserver for several months now on a previous
incarnation of this project with both the host and the target running
redhat 7.2, so i have a pretty good idea how this works when it works
properly.

i *have* built a static gdbserver based on some mail from DanielJ about
how to build a static libthread_db.a and the *good* news is that it
*doesnt* coredump, but it does have the almost as aggravating

gdb: error initializing thread_db library


hope that someone can help me figure out what is broken and how to fix
it.

tnx!

johnu

Re: gdbserver coredumps,what is the *right* libthread_db.so for gdbserver on a given platform?

[Daniel Jacobowitz]

On Fri, Jan 23, 2004 at 12:32:18PM -0800, John Utz wrote:
> Hi;
> 
> i am using crosstool to build a complex app on a i686-unknown-linux-gnu
> redhat 9 for a i486-unknown-linux-gnu redhat 7.3-ish( it's a somewhat
> custom build, as near as i can tell).
> 
> problem i am having is that when gdbserver tries to load the symbols
> for for libpthread-0.9.so, it segfaults.
> 
> it seems to not matter *which* libthread_db.so i stuff into my search
> path on the target

It doesn't matter what's on your search path on the _TARGET_.  The
segfault is usually a symptom that the libthread_db loaded on the
_HOST_ does not match the one in use on the target system.

Google for solib-absolute-prefix.  Strace gdb if necessary to see what
it finds.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer