From: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
To: Andreas Schwab <schwab@linux-m68k.org>
Cc: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] [gdb/testsuite] Fix 64-bit dwarf test-cases with -m32
Date: Fri, 19 Nov 2021 15:08:12 +0100 [thread overview]
Message-ID: <5b27d378-9468-e299-8e80-96659c24aa17@suse.de> (raw)
In-Reply-To: <87a6il0yp7.fsf@igel.home>
On 11/3/21 9:30 PM, Andreas Schwab wrote:
> On Nov 03 2021, Tom de Vries wrote:
>
>> On 11/1/21 9:54 PM, Andreas Schwab wrote:
>>> On Nov 01 2021, Tom de Vries via Gdb-patches wrote:
>>>
>>>> When running test-case gdb.dwarf2/loc-sec-offset.exp with target board -m32,
>>>> I run into:
>>>> ...
>>>> builtin_spawn -ignore SIGHUP gcc -fno-stack-protector -m32 \
>>>> -fdiagnostics-color=never -c -o loc-sec-offset-dw641.o \
>>>> loc-sec-offset-dw64.S^M
>>>> as: loc-sec-offset-dw641.o: unsupported relocation type: 0x1^M
>>>> loc-sec-offset-dw64.S: Assembler messages:^M
>>>> loc-sec-offset-dw64.S:29: Error: cannot represent relocation type \
>>>> BFD_RELOC_64^M
>>>> ...
>>>>
>>>> Looking at line 29, we have:
>>>> ...
>>>> .8byte .Labbrev1_begin /* Abbrevs */
>>>> ...
>>>>
>>>> It would be nice if the assembler could handle this somehow. But I guess
>>>> it's not unreasonable that an assembler for a 32-bit architecture will object
>>>> to handling 64-bit labels.
>>>
>>> Shouldn't the 64-bit dwarf tests just be skipped on 32-bit targets?
>>
>> Because ?
>
> Because 32-bit targets have no way to represent 8-byte relocations.
>
> Andreas.
>
I tried a hello world with gcc-11, -m32 and -gdwarf64:
...
$ gcc-11 ~/hello.c -g -gdwarf64 -m32 -save-temps -dA
...
and looked at a section offset:
...
.long .Ldebug_line0, 0 # DW_AT_stmt_list
...
This comes from dw2_assemble_integer, where we have:
...
void
dw2_assemble_integer (int size, rtx x)
{
if (size == 2 * (int) DWARF2_ADDR_SIZE && !CONST_SCALAR_INT_P (x))
{
/* On 32-bit targets with -gdwarf64, DImode values with
relocations usually result in assembler errors. Assume
all such values are positive and emit the relocation only
in the least significant half. */
...
So, it seems I chose the same solution as gcc.
I'll commit this shortly.
Thanks,
- Tom
prev parent reply other threads:[~2021-11-19 14:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-01 17:56 Tom de Vries via Gdb-patches
2021-11-01 20:54 ` Andreas Schwab
2021-11-03 20:00 ` Tom de Vries via Gdb-patches
2021-11-03 20:30 ` Andreas Schwab
2021-11-19 14:08 ` Tom de Vries via Gdb-patches [this message]
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=5b27d378-9468-e299-8e80-96659c24aa17@suse.de \
--to=gdb-patches@sourceware.org \
--cc=schwab@linux-m68k.org \
--cc=tdevries@suse.de \
/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