Bug 32313 - GDB uses wrong function address when debugging Emacs (gcc -g -O2)
Summary: GDB uses wrong function address when debugging Emacs (gcc -g -O2)
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 15.1
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-10-27 23:54 UTC by eggert
Modified: 2024-10-28 15:08 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
compressed eval.o illustrating the bug (741.67 KB, application/gzip)
2024-10-27 23:54 UTC, eggert
Details
xz-compressed temacs illustrating the bug (8.64 MB, application/x-xz)
2024-10-27 23:58 UTC, eggert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description eggert 2024-10-27 23:54:28 UTC
Created attachment 15765 [details]
compressed eval.o illustrating the bug

We ran into this problem when debugging Emacs with GNU gdb (Fedora Linux) 15.2-1.fc40 on x86-64.

To reproduce the problem on a Fedora 40 developer host:

  git clone https://git.savannah.gnu.org/git/emacs.git
  cd emacs
  git checkout 9e40d3f2a1c2b5388a4eab72dbe506a21816f69b
  ./autogen.sh
  ./configure --enable-checking
  cd src
  make temacs

On Fedora 40, which uses gcc (GCC) 14.2.1 20240912 (Red Hat 14.2.1-3), this generates files eval.o and temacs that GDB mishandles as illustrated by the sample shell session:

  $ nm eval.o | grep -E 'backtrace_(next|function)'
  0000000000000c30 T backtrace_function
  00000000000002ce t backtrace_function.cold
  00000000000001c5 t backtrace_function.part.0
  0000000000000cd0 T backtrace_next
  $ gdb -ex 'print backtrace_next' -ex 'print backtrace_function' eval.o
  ...
  $1 = {union specbinding *(union specbinding *)} 0xcd0 <backtrace_next>
  $2 = {Lisp_Object (union specbinding *)} 0xa26f <backtrace_function>
  $ nm temacs | grep -E 'backtrace_(next|function)'
  000000000064a9b0 T backtrace_function
  000000000043a756 t backtrace_function.cold
  000000000043a64d t backtrace_function.part.0
  000000000064aa50 T backtrace_next
  $ gdb -ex 'print backtrace_next' -ex 'print backtrace_function' temacs
  ...
  $1 = {union specbinding *(union specbinding *)} 0x64aa50 <backtrace_next>
  $2 = {Lisp_Object (union specbinding *)} 0x43a64d <backtrace_function>

Because GDB uses the wrong address for backtrace_function, we can't run GDB commands  that use that address; this is an important part of debugging Emacs. The address for backtrace_next is fine. Apparently GDB is confusing backtrace_function with backtrace_function.part.0.

I filed a GCC bug report <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117320> but the conclusion there was that the bug is not in GCC, so I'm filing a GDB bug report here. 

I will attempt to attach compressed versions of eval.o and temacs.
Comment 1 eggert 2024-10-27 23:58:10 UTC
Created attachment 15766 [details]
xz-compressed temacs illustrating the bug

For the temacs attachment I used xz rather than gzip; that got it under sourceware.org's 10 MB limit.