"gdb vmlinux" gives wrong symbol addresses

"gdb vmlinux" gives wrong symbol addresses

[Vivek Goyal]

Hi,

I am trying to run gdb with kernel vmlinux to find out symbol addresses.

#> gdb vmlinux
(gdb) p &linux_banner

If I link my vmlinux with linker option --emit-relocs then gdb seems
to be giving wrong values for the symbols.

Following are two outputs.

vmlinux linked without option --emit-relocs

(gdb) p &linux_banner
$1 = (char (*)[162]) 0xc0344000

vmlinux linked with option --emit-relocs

(gdb) p &linux_banner
$1 =  (char (*)[162]) 0x8068a000

Above address is not a kernel address at all.

I have compiled my kernel with -g for i386 machine. I am using gdb
version 6.3

Any suggestions regarding where the anomaly is will help.

Thanks
Vivek

Re: "gdb vmlinux" gives wrong symbol addresses

[Daniel Jacobowitz]

On Fri, Aug 18, 2006 at 02:38:07PM -0400, Vivek Goyal wrote:
> Following are two outputs.
> 
> vmlinux linked without option --emit-relocs
> 
> (gdb) p &linux_banner
> $1 = (char (*)[162]) 0xc0344000
> 
> vmlinux linked with option --emit-relocs
> 
> (gdb) p &linux_banner
> $1 =  (char (*)[162]) 0x8068a000

Stick a 1 in front of that and it should be obvious what the problem
is.  The address has been doubled.

The debug section has been fully resolved, but relocations are also
applied to it, moving all addresses up even further.  I don't have
any good idea on how to detect this case.  We originally handled
relocations for shared libraries with unrelocated debug sections;
but this is a fully relocated section which still has relocation
information.

Did we change all binutils targets to resolve relocations in debug
sections?  I don't really remember.  If so, maybe we should drop
support for shared libraries with this problem, and only apply
relocations to debug info for ET_REL objects.

Any ideas from the binutils list?

-- 
Daniel Jacobowitz
CodeSourcery

Re: "gdb vmlinux" gives wrong symbol addresses

[Vivek Goyal]

On Fri, Aug 18, 2006 at 02:48:37PM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 18, 2006 at 02:38:07PM -0400, Vivek Goyal wrote:
> > Following are two outputs.
> > 
> > vmlinux linked without option --emit-relocs
> > 
> > (gdb) p &linux_banner
> > $1 = (char (*)[162]) 0xc0344000
> > 
> > vmlinux linked with option --emit-relocs
> > 
> > (gdb) p &linux_banner
> > $1 =  (char (*)[162]) 0x8068a000
> 
> Stick a 1 in front of that and it should be obvious what the problem
> is.  The address has been doubled.
> 

Oh. Thanks.

> The debug section has been fully resolved, but relocations are also
> applied to it, moving all addresses up even further.  I don't have
> any good idea on how to detect this case.  We originally handled
> relocations for shared libraries with unrelocated debug sections;
> but this is a fully relocated section which still has relocation
> information.
> 
> Did we change all binutils targets to resolve relocations in debug
> sections?  I don't really remember.  If so, maybe we should drop
> support for shared libraries with this problem, and only apply
> relocations to debug info for ET_REL objects.
> 

In this case file type is ET_EXEC and not even ET_DYN or ET_REL. 
Probably we should not be applying relocations at least for file
types ET_EXEC as relocations have already been processed.

We are looking at making i386 kernel relocatable by retaining
relocation information in fully linked executable and later using
that info to relocate the kernel at run time. Eric already has
posted working patches. In this context I can not debung kernel core
using gdb if this problem persists.

Thanks
Vivek

Re: "gdb vmlinux" gives wrong symbol addresses

[Alan Modra]

On Fri, Aug 18, 2006 at 02:48:37PM -0400, Daniel Jacobowitz wrote:
> The debug section has been fully resolved, but relocations are also
> applied to it, moving all addresses up even further.  I don't have
> any good idea on how to detect this case.  We originally handled
> relocations for shared libraries with unrelocated debug sections;
> but this is a fully relocated section which still has relocation
> information.
> 
> Did we change all binutils targets to resolve relocations in debug
> sections?  I don't really remember.  If so, maybe we should drop
> support for shared libraries with this problem, and only apply
> relocations to debug info for ET_REL objects.

I think that for ET_EXEC and ET_DYN gdb should ignore relocs that use
the normal symbol table.  Sane ELF targets will have dynamic reloc
section(s) with sh_link pointing at a symtab section with sh_type of
SHT_DYNSYM.  --emit-relocs creates reloc sections with sh_link pointing
at a symtab section with sh_type of SHT_SYMTAB.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: "gdb vmlinux" gives wrong symbol addresses

[Daniel Jacobowitz]

On Mon, Aug 21, 2006 at 11:08:29AM +0930, Alan Modra wrote:
> I think that for ET_EXEC and ET_DYN gdb should ignore relocs that use
> the normal symbol table.  Sane ELF targets will have dynamic reloc
> section(s) with sh_link pointing at a symtab section with sh_type of
> SHT_DYNSYM.  --emit-relocs creates reloc sections with sh_link pointing
> at a symtab section with sh_type of SHT_SYMTAB.

This amounts to always ignoring relocations; GDB only uses relocations
for debug sections, which will never point at SHT_DYNSYM (I don't
think?).

-- 
Daniel Jacobowitz
CodeSourcery

Re: "gdb vmlinux" gives wrong symbol addresses

[Alan Modra]

On Sun, Aug 20, 2006 at 09:54:30PM -0400, Daniel Jacobowitz wrote:
> On Mon, Aug 21, 2006 at 11:08:29AM +0930, Alan Modra wrote:
> > I think that for ET_EXEC and ET_DYN gdb should ignore relocs that use
> > the normal symbol table.  Sane ELF targets will have dynamic reloc
> > section(s) with sh_link pointing at a symtab section with sh_type of
> > SHT_DYNSYM.  --emit-relocs creates reloc sections with sh_link pointing
> > at a symtab section with sh_type of SHT_SYMTAB.
> 
> This amounts to always ignoring relocations; GDB only uses relocations
> for debug sections, which will never point at SHT_DYNSYM (I don't
> think?).

When we emitted relocs for debug sections on some targets (eg. ppc32
prior to 2005-04-19), they were against SHT_DYNSYM symbols.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: "gdb vmlinux" gives wrong symbol addresses

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

On Mon, 21 Aug 2006 05:24:19 +0200, Alan Modra wrote:
> On Sun, Aug 20, 2006 at 09:54:30PM -0400, Daniel Jacobowitz wrote:
> > On Mon, Aug 21, 2006 at 11:08:29AM +0930, Alan Modra wrote:
> > > I think that for ET_EXEC and ET_DYN gdb should ignore relocs that use
> > > the normal symbol table.  Sane ELF targets will have dynamic reloc
> > > section(s) with sh_link pointing at a symtab section with sh_type of
> > > SHT_DYNSYM.  --emit-relocs creates reloc sections with sh_link pointing
> > > at a symtab section with sh_type of SHT_SYMTAB.
> > 
> > This amounts to always ignoring relocations; GDB only uses relocations
> > for debug sections, which will never point at SHT_DYNSYM (I don't
> > think?).
> 
> When we emitted relocs for debug sections on some targets (eg. ppc32
> prior to 2005-04-19), they were against SHT_DYNSYM symbols.

Do you have such (ppc32?) shared library(?) binary handy?
It would be find to include it to the gdb testsuite.

The restricted patch targetting relocatable Linux kernel but not targetting the
libraries attached, IMO safe.  It is gdb-only patch, not binutils-wide.


Regards,
Jan

[-- Attachment #2: gdb-6.5-bz203661-emit-relocs.patch --]
[-- Type: text/plain, Size: 613 bytes --]

--- sources-clean/gdb/symfile.c	2006-08-23 09:22:21.000000000 +0200
+++ sources-custom/gdb/symfile.c	2006-08-23 09:54:24.000000000 +0200
@@ -3713,6 +3713,12 @@
 bfd_byte *
 symfile_relocate_debug_section (bfd *abfd, asection *sectp, bfd_byte *buf)
 {
+  /* Executable files have all the relocations already resolved.
+   * Handle files linked with --emit-relocs.
+   * http://sources.redhat.com/ml/gdb/2006-08/msg00137.html  */
+  if ((abfd->flags & EXEC_P) != 0)
+    return NULL;
+
   /* We're only interested in debugging sections with relocation
      information.  */
   if ((sectp->flags & SEC_RELOC) == 0)

Re: "gdb vmlinux" gives wrong symbol addresses

[Mark Kettenis]

> Date: Wed, 23 Aug 2006 19:31:00 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> 
> On Mon, 21 Aug 2006 05:24:19 +0200, Alan Modra wrote:
> > On Sun, Aug 20, 2006 at 09:54:30PM -0400, Daniel Jacobowitz wrote:
> > > On Mon, Aug 21, 2006 at 11:08:29AM +0930, Alan Modra wrote:
> > > > I think that for ET_EXEC and ET_DYN gdb should ignore relocs that use
> > > > the normal symbol table.  Sane ELF targets will have dynamic reloc
> > > > section(s) with sh_link pointing at a symtab section with sh_type of
> > > > SHT_DYNSYM.  --emit-relocs creates reloc sections with sh_link pointing
> > > > at a symtab section with sh_type of SHT_SYMTAB.
> > > 
> > > This amounts to always ignoring relocations; GDB only uses relocations
> > > for debug sections, which will never point at SHT_DYNSYM (I don't
> > > think?).
> > 
> > When we emitted relocs for debug sections on some targets (eg. ppc32
> > prior to 2005-04-19), they were against SHT_DYNSYM symbols.
> 
> Do you have such (ppc32?) shared library(?) binary handy?
> It would be find to include it to the gdb testsuite.
> 
> The restricted patch targetting relocatable Linux kernel but not
> targetting the libraries attached, IMO safe.  It is gdb-only patch,
> not binutils-wide.

Are we sure this is safe?  Is it really impossible for debug sections
to refer to symbols in shared libs which will have relocations that
still need to be processed?

Mark

Re: "gdb vmlinux" gives wrong symbol addresses

[Daniel Jacobowitz]

On Wed, Aug 23, 2006 at 08:30:57PM +0200, Mark Kettenis wrote:
> Are we sure this is safe?  Is it really impossible for debug sections
> to refer to symbols in shared libs which will have relocations that
> still need to be processed?

That patch won't affect shared libs.  But anyway, I'm against it; I
think we should do it the way Alan suggested.

-- 
Daniel Jacobowitz
CodeSourcery

Re: "gdb vmlinux" gives wrong symbol addresses

[Vivek Goyal]

On Sun, Aug 20, 2006 at 09:54:30PM -0400, Daniel Jacobowitz wrote:
> On Mon, Aug 21, 2006 at 11:08:29AM +0930, Alan Modra wrote:
> > I think that for ET_EXEC and ET_DYN gdb should ignore relocs that use
> > the normal symbol table.  Sane ELF targets will have dynamic reloc
> > section(s) with sh_link pointing at a symtab section with sh_type of
> > SHT_DYNSYM.  --emit-relocs creates reloc sections with sh_link pointing
> > at a symtab section with sh_type of SHT_SYMTAB.
> 
> This amounts to always ignoring relocations; GDB only uses relocations
> for debug sections, which will never point at SHT_DYNSYM (I don't
> think?).
>

This brings me to a stupid question. Why do I have to apply relocations
for file type ET_EXEC. By definition, doesn't it mean that all the
relocations have already been processed?

Thanks
Vivek
 

Re: "gdb vmlinux" gives wrong symbol addresses

[Daniel Jacobowitz]

On Mon, Aug 21, 2006 at 11:14:39AM -0400, Vivek Goyal wrote:
> On Sun, Aug 20, 2006 at 09:54:30PM -0400, Daniel Jacobowitz wrote:
> > On Mon, Aug 21, 2006 at 11:08:29AM +0930, Alan Modra wrote:
> > > I think that for ET_EXEC and ET_DYN gdb should ignore relocs that use
> > > the normal symbol table.  Sane ELF targets will have dynamic reloc
> > > section(s) with sh_link pointing at a symtab section with sh_type of
> > > SHT_DYNSYM.  --emit-relocs creates reloc sections with sh_link pointing
> > > at a symtab section with sh_type of SHT_SYMTAB.
> > 
> > This amounts to always ignoring relocations; GDB only uses relocations
> > for debug sections, which will never point at SHT_DYNSYM (I don't
> > think?).
> >
> 
> This brings me to a stupid question. Why do I have to apply relocations
> for file type ET_EXEC. By definition, doesn't it mean that all the
> relocations have already been processed?

For ET_EXEC, you don't especially.  However, for some ET_DYN you do and
some ET_DYN you don't.  If we're going to change the behavior... let's
get it right.

I just need to figure out how to do the check Alan suggested without
breaking non-ELF GDB.  Shouldn't be too hard.

-- 
Daniel Jacobowitz
CodeSourcery