Re: [PATCH v2 2/2] gas: re-work line number tracking for macros and their expansions

[Andrew Burgess <aburgess@redhat.com>]

Andrew Burgess <aburgess@redhat.com> writes:

> Luis Machado via Binutils <binutils@sourceware.org> writes:
>
>> Hi,
>>
>> I'm not yet sure how, but this patch has broken at least one gdb test (gdb.asm/asm-source.exp) for aarch64-linux (Ubuntu 22.04 and 20.04).
>>
>> Could you please take a look at it? I can do some testing with the aarch64 machines if that's helpful.
>>
>> FAIL: gdb.asm/asm-source.exp: f at main
>> FAIL: gdb.asm/asm-source.exp: n at main
>> FAIL: gdb.asm/asm-source.exp: next over macro
>> FAIL: gdb.asm/asm-source.exp: list
>> FAIL: gdb.asm/asm-source.exp: f in foo2
>> FAIL: gdb.asm/asm-source.exp: n in foo2
>> FAIL: gdb.asm/asm-source.exp: bt ALL in foo2
>> FAIL: gdb.asm/asm-source.exp: bt 2 in foo2
>> FAIL: gdb.asm/asm-source.exp: bt 3 in foo3
>> FAIL: gdb.asm/asm-source.exp: finish from foo3
>> FAIL: gdb.asm/asm-source.exp: info source asmsrc2.s
>> FAIL: gdb.asm/asm-source.exp: info line
>> FAIL: gdb.asm/asm-source.exp: next over foo3
>> FAIL: gdb.asm/asm-source.exp: return from foo2
>
> Can confirm I'm seeing the same set of failures on x86-64 gdb when using
> gas that includes this patch.

I think I understand the issue a little more now.  I have a simple
reproducer which can be run outside the gdb testsuite (see below).

It appears that the DWARF for macros now tries to associate the
instructions within the macro the source location within the macro
definition, rather than the macro use site.  I'm not entirely convinced
this is a good idea (as a macro could be used multiple times), or even
if this was an intended change of this series.

If this is the direction gas is moving in then I guess we will need to
update the GDB test, but there is, I think, a bug in the generated
DWARF, in that it appears that the wrong file name is being used.

Here's my steps to reproduce:

  $ cat test.s 
          .include "other.inc"
  
          .global _start
  _start:
          xor	%rbp, %rbp
          call    main
          hlt
  
          .global main
  main:
          gdbasm_enter
          hlt
  $ cat other.inc 
  	.macro gdbasm_enter
  	push	%rbp
  	mov	%rsp,%rbp
  	.endm
  $ cat Makefile 
  all:
  	$(AS) --gdwarf-2 -o test.o test.s
  	$(LD) -o test test.o
  
  clean:
  	-rm -f test.o test
  
  $ make AS=/path/to/recent/build/of/gas/as-new
  /path/to/recent/build/of/gas/as-new --gdwarf-2 -o test.o test.s
  ld -o test test.o
  $ cat cmd.gdb 
  set height 0
  set trace-commands on
  start
  frame
  
  $ gdb -q -x cmd.gdb test
  Reading symbols from test...
  +start
  Temporary breakpoint 1 at 0x401009: file test.s, line 2.
  
  Temporary breakpoint 1, main () at test.s:2
  2	
  +frame
  #0  main () at test.s:2
  2	
  (gdb)

Notice that when we stopped at 'main' in gdb the location was reported
as test.s:2.  The '2' here is correctly indicating line 2, but the file
should be 'other.inc', not 'test.s'.

If I rebuild using an older version of gas, then repeat the gdb step,
the old behaviour was:

  $ make
  as --gdwarf-2 -o test.o test.s
  ld -o test test.o
  $ gdb -q -x cmd.gdb test
  Reading symbols from test...
  +start
  Temporary breakpoint 1 at 0x401009: file test.s, line 11.
  
  Temporary breakpoint 1, main () at test.s:11
  11	        gdbasm_enter
  +frame
  #0  main () at test.s:11
  11	        gdbasm_enter
  (gdb) 

Now the location is 'test.s:11', pointing at the macro invocation.  To
me, this seems more helpful, but that's just my $0.02 worth.

As a separate idea from the above, I wonder if we could have gas
generate the DWARF required to represent the macro expansion as an
inlined function.  This might solve the problem of whether the DWARF
should point at the location of the macro definition, or the macro
invocation...

Anyway, hopefully the reproducer helps track down the problem.

Thanks,
Andrew