From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: kevinb@redhat.com
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC] solib-svr4.c: Never attempt to place breakpoints on _start, __start, or main
Date: Fri, 17 Sep 2010 12:29:00 -0000 [thread overview]
Message-ID: <201009170810.o8H8AITW028258@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <20100916152334.7e4f1ee5@mesquite.lan> (message from Kevin Buettner on Thu, 16 Sep 2010 15:23:34 -0700)
> Date: Thu, 16 Sep 2010 15:23:34 -0700
> From: Kevin Buettner <kevinb@redhat.com>
>
> I recently had a discussion with a colleague who, while debugging the
> linux kernel using GDB, noticed that GDB is writing a breakpoint to
> the _start address on every "step" and "continue". He had not placed
> a breakpoint at that address, nor did he want that address being
> written to in the event that the page containing that address had
> been recycled and was now being used for other purposes.
>
> I have found some cruft in solib-svr4.c which is responsible for this
> behavior -- well, I think it's cruft anyway. There's a bit of code at
> the end of enable_break() which, in desperation, attempts to place a
> breakpoint on one of _start, __start, or main, in that order only when
> all earlier attempts to place a shared library event breakpoint have
> failed. I have no doubt that there was probably some platform for
> which this once worked and was perhaps even needed, probably back in
> the days when GDB's SunOS and SVR4 shared library support was jumbled
> together in one file. I suspect that it may have been needed for
> SunOS support but was copied over to the SVR4 file in an abundance of
> caution. I doubt that there's any recent SVR4-like platform which
> requires this code.
>
> I've tested the patch below on Fedora 13 x86_64 (native) and do not
> see any regressions.
>
> Comments? (I.e. does anyone know of a platform or a situation where
> the code that I'm deleting is still needed?)
Sorry, but I think that code is still useful. Over the years I've
seen various cases where setting the breakpoint in the proper place
failed: the magic ld.so breakpoint function was renamed, somebody
stripped ld.so, GDB misinterpreted the debug information in ld.so.
The code you're removing makes sure (or at least attempts too make
sure) that you have a valid list of shared libraries as soon as you
hit main().
Obviously it is pointless to keep removing and reinserting these
breakpoints. Perhaps they should be disabled as soon as one of them
has been hit?
Also, I think it is pointless to insert these if the program you're
debugging isn't using the dynamic linker. I'm a little bit suprised
that the solib-svr4.c code is used at all when debugging the Linux
kernel. Does the same thing happen for static binaries?
next prev parent reply other threads:[~2010-09-17 8:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-17 2:13 Kevin Buettner
2010-09-17 8:10 ` Daniel Jacobowitz
2010-09-17 12:29 ` Mark Kettenis [this message]
2010-09-18 14:13 ` Kevin Buettner
2010-09-18 16:03 ` Mark Kettenis
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=201009170810.o8H8AITW028258@glazunov.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=gdb-patches@sourceware.org \
--cc=kevinb@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