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 _______________________________________________ Bug-gdb mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gdb
