From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: palves@redhat.com
Cc: jan.kratochvil@redhat.com, macro@codesourcery.com,
Joakim.Tjernlund@transmode.se, gdb-patches@sourceware.org
Subject: Re: [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot
Date: Fri, 08 Jun 2012 13:37:00 -0000 [thread overview]
Message-ID: <201206081336.q58Dar6Y019154@glazunov.sibelius.xs4all.nl> (raw)
In-Reply-To: <4FD1F902.5000705@redhat.com> (message from Pedro Alves on Fri, 08 Jun 2012 14:07:14 +0100)
> Date: Fri, 08 Jun 2012 14:07:14 +0100
> From: Pedro Alves <palves@redhat.com>
>
> On 06/08/2012 01:38 PM, Jan Kratochvil wrote:
> > I still do not see why 'main' was not left there as it would not hurt and it
> > could help.
>
> The original patch was trivial, and a one liner. I preferred not
> requiring bigger changes and risk needing to require copyright
> assignment for that patch. Then, GDB has not been trapping on
> "main", but on "_start" for static binaries for a long time, so that
> even feels like a separate "feature" to me.
The problem here is that "_start" is by no means a standardized name,
whereas "main" is (although there are some exceptions).
> I even feel like we could/should drop the "_start/main" fallback
> from svr4 handling. It's just historic at this point, as far as I
> could ascertain. If those are really needed on some system, then a
> comment in the code mentioning such system is warranted.
Please don't do this. The fallback is useful when bringing up GDB on
a new platform that decided to use yet another name for the ld.so
state point "function". Or in other cases where for some reason
placing breakpoints in ld.so doesn't work but putting them in the
executable itself does work. I've been in that situation at least a
couple of times in the past couple of years.
next prev parent reply other threads:[~2012-06-08 13:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-01 15:01 [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot with Abatron BDI emulator an error occurs: .. (gdb) tar remote bdi:2001 Remote debugging using bdi:2001 0xeff80050 in ?? () (gdb) mon reset (gdb) cont Continuing. Warning: Cannot insert breakpoint -1. Error accessing memory address 0xc0000000: Unknown error 4294967295 Joakim Tjernlund
2012-06-01 16:21 ` [PATCH] solib-svr4: Avoid unwanted shlib internal BPs When debugging Linux kernel or u-boot Pedro Alves
2012-06-01 18:05 ` Jan Kratochvil
2012-06-01 17:37 ` Pedro Alves
2012-06-01 18:05 ` Jan Kratochvil
2012-06-01 18:19 ` Pedro Alves
2012-06-01 19:08 ` Jan Kratochvil
2012-06-01 20:25 ` Mark Kettenis
2012-06-07 0:00 ` Maciej W. Rozycki
2012-06-08 12:10 ` Pedro Alves
2012-06-08 12:39 ` Jan Kratochvil
2012-06-08 13:07 ` Pedro Alves
2012-06-08 13:37 ` Mark Kettenis [this message]
2012-06-08 13:45 ` Pedro Alves
2012-06-08 15:45 ` Maciej W. Rozycki
2012-06-01 18:07 ` Jan Kratochvil
2012-06-05 15:45 ` Pedro Alves
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=201206081336.q58Dar6Y019154@glazunov.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=Joakim.Tjernlund@transmode.se \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=macro@codesourcery.com \
--cc=palves@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