Re: Change in relocation of debug info

> When I link using gcc 5.4:
> 
>   $gcc --version:
>   gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609,
> 
> giving executable named prog I see:
> 
>   $objdump -g prog
>   ...
>   /* file ../src/SetElem.m3 line 11 addr 0x4008ee */
>   ...

> But when linking with gcc 9.3:
> 
>   $gcc --version:
>   gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
> 
> I see:
> 
>   $objdump -g prog
>   ...
>   /* file ../src/SetElem.m3 line 11 addr 0x9b1 */

It just sounds like your gcc 9.3.0 is producing position-indenpendent
executables by default, whereas your gcc 5.4.0 did not.  In the recent
years, this has become the norm.

The executable produced by your gcc 5.4.0 is made to always be loaded at
the same address, so the code at virtual address 0x4008ee in the
executable will always end up at address 0x4008ee in the virtual address
space of the process.

With the executable produced by your gcc 9.3.0, the OS / dynamic linker
will choose a different random base address for the executable
every time it's loaded (except when address randomization is disabled,
which GDB tries to do by default, then it will always be the same random
address).  So the virtual address 0x9b1 in the executable will end up at
<load address> + 0x9b1 in the virtual address space of the process.  GDB
has to account for that: detect the load address of the executable,
adjust the addresses of the symbols.

This works for DWARF but doesn't seem to work for stabs for some reason
(based on what you have shown, I didn't try it myself).  I don't know
how difficult it would be to make it work for stabs, but it's unlikely
that anybody working on GDB will do it, given that stabs is pretty much
a dead format.  You can try if you want though.

An alternative is to instruct your gcc 9.3.0 to produce good old
position-dependent executables, as your gcc 5.4.0 does.  This is done
using -fno-pie at link time, IIRC.

Simon