Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: Dan Mosedale <dmose@mozilla.org>
Cc: "Martin M. Hunt" <hunt@redhat.com>, gdb@sources.redhat.com
Subject: Re: linux, threads and auto-solib-add
Date: Thu, 30 Jan 2003 18:13:00 -0000	[thread overview]
Message-ID: <1030130181325.ZM25461@localhost.localdomain> (raw)
In-Reply-To: Dan Mosedale <dmose@mozilla.org> "Re: linux, threads and auto-solib-add" (Jan 30,  2:14am)

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


  reply	other threads:[~2003-01-30 18:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-30  0:24 Martin M. Hunt
2003-01-30  0:50 ` Kevin Buettner
2003-01-30 10:20   ` Dan Mosedale
2003-01-30 18:13     ` Kevin Buettner [this message]
2003-01-30 21:31       ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1030130181325.ZM25461@localhost.localdomain \
    --to=kevinb@redhat.com \
    --cc=dmose@mozilla.org \
    --cc=gdb@sources.redhat.com \
    --cc=hunt@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox