This is the mail archive of the
mailing list for the GDB project.
Antwort: Re: relocations when doing file command at gdb prompt
- From: Roland Puntaier <Roland dot Puntaier at br-automation dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Thu, 8 Mar 2007 18:54:16 +0100
- Subject: Antwort: Re: relocations when doing file command at gdb prompt
> Actually, ET_DYN is not quite either. It's more like a linked program
> for the purpose of my question.
Yes. Actually only the .plt .text and .data section find their way to the
> So, it's relocated already, but the relocations are still present.
> No wonder GDB is doubling them.
> I don't see how we can sensibly distinguish the two cases. What
> toolchain produced this file?
GCC, but with -Wl,-q,-shared,-T,"YYY.x", i.e shared and with modified
linker script, and the relocation info is kept because of a
post-processing using it.
This means there is no way to avoid the doubling and still keep the .rel
sections without changing GDB code, doesn't it?
Interesting that even
(gdb)add-symbol-file NewProgram.out 0 -s data 0
(gdb)info line 29
yields a wrong address.
In objfiles.c/objfile_relocate/(line 552) l->item[i].pc based on 0 would
be very fine, because ANOFFSET (objfile->section_offsets, i) (line 529)
turns out to be 0.
Strange that these two don't fit together.