GNU bug report logs - #40271
26.3; gdb-mode fails to initialize if the target executable is built without symbols

Previous Next

Full log

Message #26 received at 40271 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vladimir Nikishkin <lockywolf <at> gmail.com>
Cc: 40271 <at> debbugs.gnu.org
Subject: Re: bug#40271: 26.3; gdb-mode fails to initialize if the target
 executable is built without symbols
Date: Sat, 28 Mar 2020 16:53:20 +0300

> From: Vladimir Nikishkin <lockywolf <at> gmail.com>
> Date: Sat, 28 Mar 2020 21:26:12 +0800
> Cc: 40271 <at> debbugs.gnu.org
> 
> (gdb)
> -file-list-exec-source-file
> ^done,line="1",file="../sysdeps/x86_64/start.S",fullname="/root/glibc-2a0c65c5167af50893952729ba38cc68/glibc-2.30/csu/../sysdeps/x86_64/start.S",macro-info="0"
> (gdb)
> 
> I am confused, because libc is also expected to be stripped. Is this a gdb bug?

I don't think so.  start.S is probably the startup module that gets
linked into every program; it is provided by glibc.  I don't know
enough about linking on GNU/Linux, but I think if you strip the
binary, this file name will also be stripped, and everything will work
again (except that you will be unable to step through the source).

> Frankly speaking, I just found this by mistake. I forgot to issue
> -ggdb when compiling my code. I'm not a reverse engineer.

Right, that figures.  So I'm unsure we should do anything about this
in Emacs.  Though maybe we could have a special test for a source file
called "start.S".

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.