linux, threads and auto-solib-add

linux, threads and auto-solib-add

[Martin M. Hunt]

I am trying to answer a question about debugging threaded applications
when auto-solib-add is off. You cannot debug pthreads programs without
first loading the symbols for libpthread.  

Given that, does it make sense to modify solid_add to always read the
symbols for libpthread, if it is in the library list? Or is expected the
user knows enough to always immediately do "shar libpthread" after
starting debugging a threaded program?

Martin

Re: linux, threads and auto-solib-add

[Kevin Buettner]

On Jan 29,  4:24pm, Martin M. Hunt wrote:

> I am trying to answer a question about debugging threaded applications
> when auto-solib-add is off. You cannot debug pthreads programs without
> first loading the symbols for libpthread.  
> 
> Given that, does it make sense to modify solid_add to always read the
> symbols for libpthread, if it is in the library list?

I'm not in favor of this.

> Or is expected the user knows enough to always immediately do "shar
> libpthread" after starting debugging a threaded program?

IMO, when the user disables auto-solib-add, then the user is
responsible for "hand" loading the shared libraries needed for
debugging the program.

Kevin

Re: linux, threads and auto-solib-add

[Dan Mosedale]

Kevin Buettner wrote:

>On Jan 29,  4:24pm, Martin M. Hunt wrote:
>  
>
>>I am trying to answer a question about debugging threaded applications
>>when auto-solib-add is off. You cannot debug pthreads programs without
>>first loading the symbols for libpthread.  
>>
>>Given that, does it make sense to modify solid_add to always read the
>>symbols for libpthread, if it is in the library list?
>>    
>>
>I'm not in favor of this.
>  
>
>>Or is expected the user knows enough to always immediately do "shar
>>libpthread" after starting debugging a threaded program?
>>    
>>
>
>IMO, when the user disables auto-solib-add, then the user is
>responsible for "hand" loading the shared libraries needed for
>debugging the program.
>
Can you elaborate a bit on what it is about this you don't like?  This 
doesn't strike me as terribly intuitive behavior, since (unlike most 
other shared libraries), not having the symbols loaded effects the 
operation of things other than just the stack trace commands (at least 
"info threads").  It's worth keeping in mind that with larger software 
projects (eg Mozilla), developers may be turning auto-solib-add off 
because, given performance constraints, there's no practical alternative 
if you don't have a suitably beefy machine.

Dan

Re: linux, threads and auto-solib-add

[Kevin Buettner]

On Jan 30,  2:14am, Dan Mosedale wrote:

> Kevin Buettner wrote:
> 
> >On Jan 29,  4:24pm, Martin M. Hunt wrote:
> >
> >>I am trying to answer a question about debugging threaded applications
> >>when auto-solib-add is off. You cannot debug pthreads programs without
> >>first loading the symbols for libpthread.  
> >>
> >>Given that, does it make sense to modify solid_add to always read the
> >>symbols for libpthread, if it is in the library list?
> >    
> >I'm not in favor of this.
> >
> >>Or is expected the user knows enough to always immediately do "shar
> >>libpthread" after starting debugging a threaded program?
> >
> >IMO, when the user disables auto-solib-add, then the user is
> >responsible for "hand" loading the shared libraries needed for
> >debugging the program.
>
> Can you elaborate a bit on what it is about this you don't like?  This 
> doesn't strike me as terribly intuitive behavior, since (unlike most 
> other shared libraries), not having the symbols loaded effects the 
> operation of things other than just the stack trace commands (at least 
> "info threads").  It's worth keeping in mind that with larger software 
> projects (eg Mozilla), developers may be turning auto-solib-add off 
> because, given performance constraints, there's no practical alternative 
> if you don't have a suitably beefy machine.

IMO, it adds needless complexity to gdb's shared library machinery and
to the documentation.  On the gdb side, we have to check for a
particular thread library, the name of which is platform dependent. 
On the documentation side, we now have an exception to the rule that
no shared libraries are automatically loaded when auto-solib-add is
disabled.  Also, there may be occasions when the user truly doesn't
want _any_ shared libraries to be automatically loaded.

I used the word "needless" above because I think there's a perfectly
reasonable way that the user can achieve the same effect without
modifying gdb.  Simply place the following commands in a suitable
.gdbinit file:

    set auto-solib-add off
    define hook-stop
    sharedlibrary libpthread
    end

The ``hook-stop'' definition above will attempt to load the libpthread
shared library every time gdb stops.  Of course, once a shared library
has been loaded, future attempts to load the shared library are
effectively no-ops since gdb knows that the library is already loaded.

Kevin

Re: linux, threads and auto-solib-add

[Andrew Cagney]

> I used the word "needless" above because I think there's a perfectly
> reasonable way that the user can achieve the same effect without
> modifying gdb.  Simply place the following commands in a suitable
> .gdbinit file:
> 
>     set auto-solib-add off
>     define hook-stop
>     sharedlibrary libpthread
>     end
> 
> The ``hook-stop'' definition above will attempt to load the libpthread
> shared library every time gdb stops.  Of course, once a shared library
> has been loaded, future attempts to load the shared library are
> effectively no-ops since gdb knows that the library is already loaded.

Hey, wow!  Consider adding this to the documentation.

Andrew