From: Simon Marchi <simon.marchi@polymtl.ca>
To: Carl Love <cel@us.ibm.com>,
gdb-patches@sourceware.org,
Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Cc: Rogerio Alves <rogealve@br.ibm.com>,
Will Schmidt <will_schmidt@vnet.ibm.com>
Subject: Re: [PATCH ver3] gdb: Add PowerPC support to gdb.dwarf2/frame-inlined-in-outer-frame.exp
Date: Mon, 6 Dec 2021 11:43:49 -0500 [thread overview]
Message-ID: <b489b388-8f45-29f3-0999-b616ba3f04bf@polymtl.ca> (raw)
In-Reply-To: <73426fba8d9ce1eb5fc60ae64a2ecd57074c510a.camel@us.ibm.com>
On 2021-12-06 11:37 a.m., Carl Love wrote:
> Simon:
>
> On Fri, 2021-12-03 at 21:13 -0500, Simon Marchi wrote:
>> <snip>
>>
>> Format like this:
>>
>> #if defined (__powerpc64__)
>> # if _CALL_ELF == 2
>> ...
>> # else
>> ...
>> # endif
>> #endif
>>
>> Put the assembly statements at column 0, as they would be without the
>> preprocessor conditionals.
>
> I made the requested changes, above, to the patch.
>
>> I guess I'll have to trust you because I know nothing about PowerPC
>> assembly but... this is all really necessary for such a simple
>> program?
>
> Per Will Schmidt's commnets
>
> Yes.. Details as I paraphrase them are that
> ElfV1 (Powerpc Big Endian) requires an opd (Official Procedure
> Descriptor) section that contains the function descriptors.
> So, the assembly here is defining the abiversion, and the .opd
> section
> (with required alignment), and adding an entry for the _start
> function
> in that section.
>
> This requirement was eliminated in the ELF V2 ABI, as
> seen in the simpler #ifdef branch above.
>
> Thanks
> -Will
>
> Yes unfortunately. I would also add to what Will said that we need tp
> explicitly specify which abi version ( directive .abiversion ) for the
> assembler to use. Otherwise it will assume version 1 by default.
Thanks to both for the explanations.
>
> Please let me know if the patch is acceptable for mainline. Thanks.
>
> Carl
>
> ---------------------------------------------------------------------
> gdb: Add PowerPC support to gdb.dwarf2/frame-inlined-in-outer-frame
>
> This patch adds an #elif defined for PowerPC to setup the exit_0 macro.
> This patch addes the needed macro definitionald logic to handle both elfV1
> and elfV2.
>
> The patch has been successfully tested on both PowerPC BE, Powerpc LE and
> X86_64 with no regressions.
> ---
> .../gdb.dwarf2/frame-inlined-in-outer-frame.S | 30 +++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/gdb/testsuite/gdb.dwarf2/frame-inlined-in-outer-frame.S b/gdb/testsuite/gdb.dwarf2/frame-inlined-in-outer-frame.S
> index 9fb6e7b7164..09fe75d8132 100644
> --- a/gdb/testsuite/gdb.dwarf2/frame-inlined-in-outer-frame.S
> +++ b/gdb/testsuite/gdb.dwarf2/frame-inlined-in-outer-frame.S
> @@ -65,6 +65,16 @@
> swi 0x0
> .endm
>
> +#elif defined __powerpc64__
> +
> +# define RETURN_ADDRESS_REGNO 65
> +
> +.macro exit_0
> + li 0, __NR_exit /* r0 - contains system call number */
> + li 3, 0 /* r3 - contains first argument for sys call */
> + sc
> +.endm
> +
> #else
> # error "Unsupported architecture"
> #endif
> @@ -90,8 +100,28 @@
> 16 }
> */
>
> +#if defined __powerpc64__
> +# if _CALL_ELF == 2
> +.abiversion 2 /* Tell gdb what ELF version to use. */
> +.global _start
> +_start:
> +# else
> +.abiversion 1 /* Tell gdb what ELF version to use. */
> +.align 2
> +.global _start
> +.section ".opd", "aw"
> +.align 3
> +_start:
> +.quad ._start,.TOC.@tocbase,0
> +.previous
> +.type ._start,@function
> +._start:
> +# endif
> +#else
> .global _start
> _start:
> +#endif
My only question is whether these two lines:
.global _start
_start:
could be kept unconditional, and just not put in the powerpc-specific
sections of the code at all.
Simon
next prev parent reply other threads:[~2021-12-06 16:43 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-29 21:43 [PATCH] " Carl Love
2021-11-29 23:22 ` will schmidt
2021-12-04 0:38 ` [PATCH ver2] " Carl Love
2021-12-04 2:13 ` Simon Marchi
2021-12-06 5:56 ` will schmidt
2021-12-06 16:37 ` [PATCH ver3] " Carl Love
2021-12-06 16:43 ` Simon Marchi [this message]
2021-12-06 18:06 ` Carl Love
2021-12-06 18:50 ` Simon Marchi
2021-12-06 19:35 ` Carl Love
2021-12-06 19:38 ` Simon Marchi
2021-12-07 8:37 ` Ulrich Weigand
[not found] ` <OF8B2BBF19.16E7F948-ONC12587A4.002F3132-C12587A4.002F617F@us.ibm.com>
2021-12-08 20:49 ` Carl Love
2021-12-09 17:30 ` 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=b489b388-8f45-29f3-0999-b616ba3f04bf@polymtl.ca \
--to=simon.marchi@polymtl.ca \
--cc=Ulrich.Weigand@de.ibm.com \
--cc=cel@us.ibm.com \
--cc=gdb-patches@sourceware.org \
--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).