symbol-file command working with older gdb but not with newer gdb - c

Question

I have an issue where gdb on one system I can't get gdb to use a symbol-file in order to show me source files and line numbers in a backtrace, but on an older system with the exact same commands it works fine. The older system where this is woking is a 32-bit Debian 6, and the modern one where it isn't working is a 64-bit Debian 10.
In both cases I've built, run, and ran gdb on the same system (so no crossing binaries or cores between systems)
I can reproduce this with a simple toy program (test.c) designed just to crash immediately:
int main()
{
int *i=0;
*i=0;
return 0;
}
I compile it and split it into a stripped executable and a symbols file, and run the executable:
gcc -g test.c -o test
objcopy --only-keep-debug test test.dbg
objcopy --strip-debug test
ulimit -c unlimited
./test
I then open the core dump in gdb. When I do this on an older system (32-bit, gdb 7.0.1-debian), I see the backtrace without any symbols, but once I run symbol-file test.dbg I then see the source file and line information in the backtrace (test.c:4) (I've not included some early gdb output that clutters the screen and I don't think is relevant, I can put it in if its needed)
gdb -c core test
Core was generated by `./test'.
Program terminated with signal 11, Segmentation fault.
#0 0x080483a4 in main ()
(gdb) symbol-file test.dbg
Reading symbols from /home/user/test.dbg...done.
(gdb) bt
#0 0x080483a4 in main () at test.c:4
(gdb) quit
Running the exact same sequence on a newer machine (64-bit, gdb 8.2.1), I get the following
Core was generated by `./test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055e5dda71135 in main ()
(gdb) symbol-file test.dbg
Load new symbol table from "test.dbg"? (y or n) y
Reading symbols from test.dbg...done.
(gdb) bt
#0 0x000055e5dda71135 in ?? ()
#1 0x000055e5dda71150 in ?? ()
#2 0x00007eff7035f09b in __libc_start_main (main=0x55e5dda71125, argc=1, argv=0x7fff46187ec8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff46187eb8)
at ../csu/libc-start.c:308
#3 0x000055e5dda7106a in ?? ()
#4 0x00007fff46187eb8 in ?? ()
#5 0x000000000000001c in ?? ()
#6 0x0000000000000001 in ?? ()
#7 0x00007fff46188e8f in ?? ()
#8 0x0000000000000000 in ?? ()
Loading the symbol file not only doesn't add the sources and lines, but seems to lose the main() in the first frame. I've also tried using add-symbol-file instead of symbol-file and including the symbol file on the command line with the -s option but with no better results. I've also tried putting -s before -c as I found recommended online but that didn't help either.
Edit: Transcript that was requested below:
$ gcc -g test.c -o test
$ objcopy --only-keep-debug test test.dbg
$ ./test
Segmentation fault (core dumped)
$ gdb test.dbg core
GNU gdb (Debian 8.2.1-2+b1) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from test.dbg...done.
warning: core file may not match specified executable file.
[New LWP 26602]
Core was generated by `./test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000056477c36d135 in ?? ()
(gdb) bt
#0 0x000056477c36d135 in ?? ()
#1 0x000056477c36d150 in ?? ()
#2 0x00007fa3a18a509b in __libc_start_main (main=0x56477c36d125, argc=1, argv=0x7ffd0b6aed38, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffd0b6aed28)
at ../csu/libc-start.c:308
#3 0x000056477c36d06a in ?? ()
#4 0x00007ffd0b6aed28 in ?? ()
#5 0x000000000000001c in ?? ()
#6 0x0000000000000001 in ?? ()
#7 0x00007ffd0b6afe8d in ?? ()
#8 0x0000000000000000 in ?? ()
(gdb)

Answer 1

Running the exact same sequence on a newer machine (64-bit, gdb 8.2.1), I get the following
Try building your test binary with -fno-pie -no-pie.
Your working example has a non-PIE address (0x0804xxxx). Your non-working example has a PIE address (0x000055....). Debian decided to make PIE binaries the default, which adds a modicum of security to the system.
What is likely happening is that GDB throws away the relocation info when it reloads the symbol-file.
P.S. You can avoid this whole problem by using:
gdb test.dbg core
which would start GDB on the right foot from the get-go.
P.P.S. It's generally a really bad idea to name any binary test, because that may interfere with shell evaluation of conditionals (if the shell finds ./test instead of /bin/test, and doesn't have test as built-in).