Bogus objdump output from kernel object files?

Bogus objdump output from kernel object files?

[Chuck Ebbert]

On Sun, 12 Feb 2006 at 01:40:46 -0800, Andrew Morton wrote:

> btw, is something up with `make foo.lst'?  It hasn't worked for me for
some
> time.
> 
> bix:/usr/src/25> make mm/vmscan.lst
>   MKLST   mm/vmscan.lst

Just doing 'objdump -d -r -l -j .text mm/vmscan.o' gives:

mm/vmscan.o:     file format elf32-i386

Disassembly of section .text:

00000000 <shrink_slab>:
kswapd_init():
^^^^^^^^^^^^^^
This is actually at offset 0 in .init.text

mm/vmscan.c:176
       0:       55                      push   %ebp
shrink_slab():
^^^^^^^^^^^^^^
OK, back to the right location.

       1:       89 e5                   mov    %esp,%ebp
       3:       57                      push   %edi
kswapd_init():
mm/vmscan.c:1801
^^^^^^^^^^^^^^^^
Now back to kswapd_init() again?!?!

       4:       56                      push   %esi
       5:       89 c6                   mov    %eax,%esi
include/asm/processor.h:710
       7:       53                      push   %ebx
       8:       83 ec 24                sub    $0x24,%esp
mm/vmscan.c:180
^^^^^^^^^^^^^^^

       b:       85 c0                   test   %eax,%eax
include/asm/processor.h:710
       d:       b8 20 00 00 00          mov    $0x20,%eax
mm/vmscan.c:176
      12:       89 55 e4                mov    %edx,0xffffffe4(%ebp)
mm/vmscan.c:180
      15:       0f 44 f0                cmove  %eax,%esi
include/asm/rwsem.h:126
      18:       a1 0c 00 00 00          mov    0xc,%eax
                        19: R_386_32    .data
      1d:       89 c2                   mov    %eax,%edx
      1f:       83 c2 01                add    $0x1,%edx
mm/vmscan.c:1803
^^^^^^^^^^^^^^^^

      22:       7e 09                   jle    2d <shrink_slab+0x2d>
      24:       0f b1 15 0c 00 00 00    cmpxchg %edx,0xc
                        27: R_386_32    .data
      2b:       75 f0                   jne    1d <shrink_slab+0x1d>
mm/vmscan.c:183
      2d:       85 c0                   test   %eax,%eax
      2f:       c7 45 e8 01 00 00 00    movl   $0x1,0xffffffe8(%ebp)
      36:       0f 88 2c 01 00 00       js     168 <shrink_slab+0x168>


So it is confused somehow.  This is with debug info generated by gcc 4.0.2
from
Fedora Core 4 (Red Hat 4.0.2-8) and locally-compiled objdump 2.16.1 (there
seems to be no binutils update for FC4 available.)
-- 
Chuck
"Equations are the Devil's sentences."  --Stephen Colbert

Re: Bogus objdump output from kernel object files?

[Andrew Morton]

Chuck Ebbert <76306.1226@compuserve.com> wrote:
>
> On Sun, 12 Feb 2006 at 01:40:46 -0800, Andrew Morton wrote:
> 
>  > btw, is something up with `make foo.lst'?  It hasn't worked for me for
>  some
>  > time.
>  > 
>  > bix:/usr/src/25> make mm/vmscan.lst
>  >   MKLST   mm/vmscan.lst
> 
>  Just doing 'objdump -d -r -l -j .text mm/vmscan.o' gives:
> 
>  mm/vmscan.o:     file format elf32-i386
> 
>  Disassembly of section .text:
> 
>  00000000 <shrink_slab>:
>  kswapd_init():
>  ^^^^^^^^^^^^^^
>  This is actually at offset 0 in .init.text
> 
>  mm/vmscan.c:176
>         0:       55                      push   %ebp
>  shrink_slab():
>  ^^^^^^^^^^^^^^
>  OK, back to the right location.

Looks like it's a binutils problem.

	http://sources.redhat.com/bugzilla/show_bug.cgi?id=2338

HJ said he'd try to get this fixed for the next binutils release.

Re: Bogus objdump output from kernel object files?

[Sam Ravnborg]

On Tue, Feb 14, 2006 at 12:53:44PM -0800, Andrew Morton wrote:
> Chuck Ebbert <76306.1226@compuserve.com> wrote:
> >
> > On Sun, 12 Feb 2006 at 01:40:46 -0800, Andrew Morton wrote:
> > 
> >  > btw, is something up with `make foo.lst'?  It hasn't worked for me for
> >  some
> >  > time.
> >  > 
> >  > bix:/usr/src/25> make mm/vmscan.lst
> >  >   MKLST   mm/vmscan.lst
> > 
> >  Just doing 'objdump -d -r -l -j .text mm/vmscan.o' gives:
> > 
> >  mm/vmscan.o:     file format elf32-i386
> > 
> >  Disassembly of section .text:
> > 
> >  00000000 <shrink_slab>:
> >  kswapd_init():
> >  ^^^^^^^^^^^^^^
> >  This is actually at offset 0 in .init.text
> > 
> >  mm/vmscan.c:176
> >         0:       55                      push   %ebp
> >  shrink_slab():
> >  ^^^^^^^^^^^^^^
> >  OK, back to the right location.
> 
> Looks like it's a binutils problem.
> 
> 	http://sources.redhat.com/bugzilla/show_bug.cgi?id=2338
> 
> HJ said he'd try to get this fixed for the next binutils release.

I've played a little with make dir/foo.lst and it sort of seems to work
for me. But I dunno how to really check the output.
objdump spits out a warning on my amd64 due to the --adjust-vma=xxx
but that I suppose is again a binutils issue. The value calculated
generate the correct adjust factor.

The --fverbose-asm cannot omprove output of make dir/foo.lst since
the .lst file is created based on the .o file, whereas --fverbose-asm
only have impact on the file generated by gcc.

Let me know if anyone thinks something is bad with the kbuild
make dir/foo.lst functionality and I will ahve a look.

	Sam

Re: Bogus objdump output from kernel object files?

[Chuck Ebbert]

In-Reply-To: <20060225190324.GA9326@mars.ravnborg.org>

On Sat, 25 Feb 2006 at 20:03:24 +0100, Sam Ravnborg wrote:
> Let me know if anyone thinks something is bad with the kbuild
> make dir/foo.lst functionality and I will ahve a look.

Try it with Arjan's new "reorder functions" patch and you should
see some real breakage.  makelst assumes the entire .o file
gets placed in-order into vmlinux and a single --adjust-vma will
work for the entire file when it really needs to be done for each
section.  It was probably already broken because of .init.text
vs. .text sections but I never did check that.  And the "grep .text"
in line 1 is broken too; it needs to be "grep -F".

-- 
Chuck
"Equations are the Devil's sentences."  --Stephen Colbert