[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb-bugs
Subject:    section limit causes "step" to break
From:       jeremy condit <jcondit () bantha ! org>
Date:       2001-03-30 0:51:56
Message-ID: 20010329195156.A99515 () bantha ! org
[Download RAW message or body]

version: gdb-5.0
configuration: i386-pc-solaris2.6

when debugging a shared object that contains lots of sections, the "step"
command doesn't work.  when stepping into a function, you first enter the
shared object trampoline code, and in order to detect this condition, gdb
calls in_plt_section(), which determines whether the pc is in the dynamic
linker's procedure linkage table.

however, it is possible that the addr and endaddr information for the .plt
section is incorrect because they have not been adjusted to compensate for
relocation (e.g. they're 0x40000 and 0x50000 instead of 0xdfc4000 and
0xdfc5000).  this can occur if the .plt section is beyond the 40th section
in that object file, since the relocation code in syms_from_objfile() only
operates on the first 40 (MAX_SECTIONS) sections.

the end result is that gdb can't figure out what code you're stepping into
and thus decides to step over the function call entirely.

the reason my object files have so many sections is that they're cluttered
with sections such as .rel.gnu.linkonce.d.foo and .gnu.linkonce.t.foo (the
worst offender has 1044 sections).  fwiw, i'm compiling with gcc version
2.95.2 19991024 (release).

i have a temporary fix that stores plt_addr directly in the
section_addr_info structure so that the .plt section info is always
relocated properly.  i'd be happy to send along the patch if it'd be
helpful, but it seems like a more appropriate solution would be to
eliminate the MAX_SECTIONS restriction entirely.

j


[prev in list] [next in list] [prev in thread] [next in thread]