From: Luis Machado <luisgpm@linux.vnet.ibm.com>
To: Ulrich Weigand <uweigand@de.ibm.com>
Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sourceware.org
Subject: Re: [rfc] Simplify ppc64_sysv_abi_adjust_breakpoint_address
Date: Thu, 09 Oct 2008 17:57:00 -0000 [thread overview]
Message-ID: <1223574985.5110.1.camel@gargoyle> (raw)
In-Reply-To: <200810091751.m99HpuoM001681@d12av02.megacenter.de.ibm.com>
On Thu, 2008-10-09 at 19:51 +0200, Ulrich Weigand wrote:
> Luis Machado wrote:
>
> > It seems we have a situation in which
> > "ppc64_sysv_abi_adjust_breakpoint_address" is still required, in a way.
> >
> > Before removing this function, GDB was smart enough to know that the
> > entry point of a 64-bit PPC binary is, in reality, a function
> > descriptor, thus grabbing the correct breakpoint location from within
> > that address and setting it correctly.
> >
> > After removing this function, GDB no longer knows that a specific
> > address is a function descriptor, and places a breakpoint at a data
> > section. The binary's code tries to fetch the correct address from the
> > function descriptor's address and ends up fetching the breakpoint
> > instruction, which makes no sense.
> >
> > So, i see two ways:
> >
> > 1 - Make GDB smart again, being able to determine if the address is of a
> > function descriptor or not, basically the way i was before this patch.
> >
> > 2 - Assume the user knows what he's doing and that he knows where to
> > place a breakpoint when using the address of a function descriptor.
>
> I'm not sure exactly what situation you're refering to ... is this
> about
> break *0x.....
> where the address that was manually specified refers to a function
> descriptor instead of the function code?
>
> In that case, I'd tend to consider this user error -- if you use
> hard-coded addresses, you should know what you're doing on the
> platform.
>
> If this is about something else, could you show a command line
> that does the wrong thing for you?
>
> Bye,
> Ulrich
>
This is exactly about placing breakpoint on numberic addresses like
"break *0x...". GDB used to do that correctly before that patch, but it
doesn't anymore. So, maybe it's OK to consider this is something the
user should be aware of...
Luis
next prev parent reply other threads:[~2008-10-09 17:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-15 10:11 Ulrich Weigand
2008-05-15 17:03 ` Daniel Jacobowitz
2008-05-16 16:21 ` Ulrich Weigand
2008-10-07 16:31 ` Luis Machado
2008-10-09 17:53 ` Ulrich Weigand
2008-10-09 17:57 ` Luis Machado [this message]
2008-10-09 17:59 ` Ulrich Weigand
2008-10-09 18:02 ` Luis Machado
2008-10-09 18:06 ` Ulrich Weigand
2008-10-09 18:06 ` Luis Machado
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=1223574985.5110.1.camel@gargoyle \
--to=luisgpm@linux.vnet.ibm.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=uweigand@de.ibm.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