This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: (linux/threads) Interesting side-effect of "auto-solib-add 0"


> Ah, simple: they're not there.  Take a look at the ps_* routines in
> proc-service.c.  In particular, ps_pglobal_lookup.  It's not at all
> surprising that you couldn't find them; this is a very rare library
> interface.  The shared library actually has undefined symbols which
> must be satisfied by GDB.

Ah ha, I see! I didn't realize it was using undefined references...
I've been used to seeing callbacks...

> Do you want to stick a comment in linux-thread-db.c somewhere
> suggesting a look over there too?

Absolutely, might be useful to someone else. I'll do that tomorrow.

> The technical alternative, if you want to implement it, would be to
> always load symbols for libpthread.  What do you think?  We don't even
> really need debugging symbols - just the minimal (ELF) symbol table.

I have been thinking about that, but there were several little factors
that made me reconsider. The one that I didn't like the most was the
fact that the only way I could see to detect the pthread library being
loaded is by looking at its name. It doesn't feel very elegant to have
to search for "/libpthread.so" or somesuch in GDB. I don't know very
well how GNU/Linux distributions are made, but couldn't that library
be named libpthread-1.8.0.so, for instance, making its identification
harder?

At one point, I considered the idea of detecting libpthread.so, and
printing a warning saying that, because auto-solib-add has been
deactivated, thread support hasn't been enabled. But that's almost
no less work than the above, so pointless.

In the end, because I wasn't able to produce any unexpected behavior
except maybe lack of thread support, and given the probable little
number of times this capability is used (I'm guessing, though), it
didn't seem worth the effort.

I do realize, however, that it shouldn't be too much work, though.
I'm open to both alternatives:

  1. Enhance GDB
  2. Document the limitation (Eli also agreed with the idea)

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]