Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <kettenis@wins.uva.nl>
To: hjl@lucon.org
Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com
Subject: Re: Shared libraries on Linux
Date: Sat, 01 Apr 2000 00:00:00 -0000	[thread overview]
Message-ID: <200002110749.e1B7nkw00408@delius.kettenis.local> (raw)
In-Reply-To: <20000210162640.A24492@lucon.org>

   Date: Thu, 10 Feb 2000 16:26:40 -0800
   From: "H . J . Lu" <hjl@lucon.org>

   On Wed, Feb 09, 2000 at 11:39:49PM -0500, Jim Kingdon wrote:
   > > Tue Feb  8 18:19:22 2000  H.J. Lu  <hjl@gnu.org>
   > 
   > Well, this one does work for me.
   > 
   > Based on reading the code (I didn't actually step through it), it
   > looks to me like the way it works is in the relevant case it calls
   > clear_solib, dumps all symbols, and then reloads them (even for
   > libraries which are still loaded).  That seems slow so I wonder why
   > the code was written that way.

   I believe there are 2 problems Sam tried to fix:

   1. Restart the problem when you have breakpointers set in a DSO
   which can be a shared library or loded in via dlopen.
   2. You have DSOs loaded/unloced via dlopen/dlclose. "info shared"
   may be wrong.

And again, I ask you for proof of 1.  As far as my experience goes,
restarting after setting a breakpoint in a shared object works
flawlessly.

   Sam's patch may not be the best. But it addresses those 2 problems.
   If there are no better alternatives, I don't see why we cannot use
   it even if it is slow.

I don't know if anybody uses remote debugging with systems that use
solib.c, but that could become really painful if it's done over a slow
link.

Otherwise, we might want to add the patch to the release branch once
that's been created, but I think a FIXME should be added.  Also people
should expect some regressions at the moment we really try to fix
things.  This "solution" has the potential of hiding bugs that might
be uncovered if a more intelligent solution is found.

Mark


      parent reply	other threads:[~2000-04-01  0:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200002082201.RAA18487@devserv.devel.redhat.com>
2000-04-01  0:00 ` H . J . Lu
2000-04-01  0:00   ` Jim Kingdon
     [not found]     ` <20000210162640.A24492@lucon.org>
2000-04-01  0:00       ` Mark Kettenis [this message]

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=200002110749.e1B7nkw00408@delius.kettenis.local \
    --to=kettenis@wins.uva.nl \
    --cc=gdb@sourceware.cygnus.com \
    --cc=hjl@lucon.org \
    --cc=kingdon@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