Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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

      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