public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <pedro@palves.net>
To: will schmidt <will_schmidt@vnet.ibm.com>,
	Carl Love <cel@us.ibm.com>, Kevin Buettner <kevinb@redhat.com>,
	gdb-patches@sourceware.org
Cc: Rogerio Alves <rogealve@br.ibm.com>
Subject: Re: [PATCH V2] PowerPC: fix for gdb.base/eh_return.exp
Date: Tue, 10 May 2022 12:43:09 +0100	[thread overview]
Message-ID: <40d76dce-1331-3af5-f6f2-0de9d956d76c@palves.net> (raw)
In-Reply-To: <37d2a4b6a57b62662f0417f123bda6ba48066554.camel@vnet.ibm.com>

On 2022-05-09 21:57, will schmidt wrote:
> On Mon, 2022-05-09 at 12:17 -0700, Carl Love wrote:
>> Will, Pedro, Kevin, GDB maintainers:
>>
>> Sorry, resend, the first attempt was missing the mailing list.
>>
>> I have updated the patch per the comments from Will.  The new version
>> of the patch uses a PowerPC specific gcc option to suppress the
>> generation of the Traceback Table information.  The Traceback
>> information is contained in the .long statements following the last
>> instruction in the function.  Now the existing test to locate the last
>> instruction in the function works without any changes.
> 
> 
> In this cases the disassembly is presenting the traceback table
> contents as .long values, but with an (un)lucky combination of bits, it
> may also represent parts of that table as instructions.  Thats all
> chance on which bits/fields are set.  That can show up readily with the
> "-mtraceback=full" option, probably unlikely with the default trace
> table contents.   (tldr; it won't always be represented as .long
> 0xfoo...).


OOC, does the ABI specify that the size of the function covers the
Traceback information as well?  I didn't find anything about that, and my initial
reading of the wording used in the ABI "following the end of the code" would
make me think that it should not.  If it wasn't, then of course disassembling
a function would not run into the table.  Maybe it's done this way today to make it
easier on the linker.

Regardless, I was wondering whether there's any way for GDB to know that
a given PC range is a traceback table, so that it wouldn't try to disassemble
such a range as instructions?  The ABI you pointed out says:

"Compilers should generate a traceback table following the end of the code for every function. Debuggers
and exception handlers can locate the traceback tables by scanning forward from the instruction address
at the point of interruption. The beginning of the traceback table is marked by a word of zeroes, which is
an illegal instruction. If read-only constants are compiled into the same section as the function code, they
must follow the traceback table. A word of zeroes as read-only data must not be the first word following
the code for a function. A traceback table is word-aligned."

Naively, we could use the "word of zeroes" marker to see where the table starts, but it
wouldn't work when you're disassembling a PC range instead of the whole function.

Is there perhaps some symbol that points to the start of the table, or some section with the list
of traceback tables in the program or some such?

  reply	other threads:[~2022-05-10 11:43 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-05 20:07 [PATCH] " Carl Love
2022-05-06 18:08 ` Kevin Buettner
2022-05-06 21:16   ` Pedro Alves
2022-05-06 22:45     ` will schmidt
2022-05-09 19:17       ` [PATCH V2] " Carl Love
2022-05-09 20:57         ` will schmidt
2022-05-10 11:43           ` Pedro Alves [this message]
2022-05-11 21:52             ` Carl Love
2022-05-11 21:52           ` [PATCH V3] " Carl Love
2022-05-11 22:48             ` Kevin Buettner
2022-05-12 16:00               ` Carl Love
2022-06-02 16:52               ` Carl Love
2022-06-08 18:32                 ` Pedro Alves
2022-06-08 18:51                   ` Carl Love
2022-06-09 15:24                   ` Carl Love
2022-06-02 17:00             ` [PATCH V4] " Carl Love
2022-06-07 17:54               ` will schmidt
2022-06-08 15:33                 ` [PATCH V5] " Carl Love
2022-06-08 15:36                   ` Carl Love
2022-06-08 16:29                     ` will schmidt
2022-07-13 17:07                     ` [Ping] " Carl Love
2022-07-15 13:41                     ` Ulrich Weigand

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=40d76dce-1331-3af5-f6f2-0de9d956d76c@palves.net \
    --to=pedro@palves.net \
    --cc=cel@us.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=kevinb@redhat.com \
    --cc=rogealve@br.ibm.com \
    --cc=will_schmidt@vnet.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).