objdump vs. elfdump for powerpc64 ( via devel/powerpc64-xtoolchain-gcc and base/binutils ) and amd64: some odd differences

[Mark Millard]

For looking into a bugzilla issue I used both
elfdump and objdump for /boot/kernel/kernel
(for example) in a amd64 context and in a
powerpc64 context. I ran into more odd
differences in the powerpc64 context but
noticed one also seen on amd64.

objdump for powerpc64:
(just some examples)

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .kboot        000000a4  0000000000100000  0000000000100000  00010000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .text         00a41ee0  0000000000100100  0000000000100100  00010100  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .interpX      0000000d  0000000000b41fe0  0000000000b41fe0  00a51fe0  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
. . .
 14 .data.read_frequently 0000003e  0000000000ec7000  0000000000ec7000  00dd7000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
. . .

elfdump on powerpc64 (note the initial entry with an empty sh_name
that is not mentioned above, leading to differing numbering, and
note that the sh_flags are all empty below):

section header:

entry: 0
        sh_name: 
        sh_type: SHT_NULL
        sh_flags: 
        sh_addr: 0
        sh_offset: 0
        sh_size: 0
        sh_link: 0
        sh_info: 0
        sh_addralign: 0
        sh_entsize: 0

entry: 1
        sh_name: .kboot
        sh_type: SHT_PROGBITS
        sh_flags: 
        sh_addr: 0x100000
        sh_offset: 65536
        sh_size: 164
        sh_link: 0
        sh_info: 0
        sh_addralign: 1
        sh_entsize: 0

entry: 2
        sh_name: .text
        sh_type: SHT_PROGBITS
        sh_flags: 
        sh_addr: 0x100100
        sh_offset: 65792
        sh_size: 10755808
        sh_link: 0
        sh_info: 0
        sh_addralign: 16
        sh_entsize: 0

entry: 3
        sh_name: .interpX
        sh_type: SHT_PROGBITS
        sh_flags: 
        sh_addr: 0xb41fe0
        sh_offset: 10821600
        sh_size: 13
        sh_link: 0
        sh_info: 0
        sh_addralign: 1
        sh_entsize: 0
. . .
entry: 15
        sh_name: .data.read_frequently
        sh_type: SHT_PROGBITS
        sh_flags: 
        sh_addr: 0xec7000
        sh_offset: 14512128
        sh_size: 62
        sh_link: 0
        sh_info: 0
        sh_addralign: 4
        sh_entsize: 0
. . .


I will note that on amd64's elfdump does
produce sh_flags lists filled in for its
kernel, for example:

entry: 50
        sh_name: set_vnet
        sh_type: SHT_PROGBITS
        sh_flags: SHF_WRITE|SHF_ALLOC
        sh_addr: 0xffffffff824dc200
        sh_offset: 36553216
        sh_size: 220872
        sh_link: 0
        sh_info: 0
        sh_addralign: 16
        sh_entsize: 0

(Note the SHF_WRITE: so not readonly. And
SHF_ALLOC is there.) amd64 objdump for this
shows:

 49 set_vnet      00035ec8  ffffffff824dc200  00000000024dc200  022dc200  2**4
                  CONTENTS, ALLOC, LOAD, DATA

But amd64 does still have the empty sh_name entry
(only in elfdump output, not objdump output):

section header:

entry: 0
        sh_name: 
        sh_type: SHT_NULL
        sh_flags: 
        sh_addr: 0
        sh_offset: 0
        sh_size: 0
        sh_link: 0
        sh_info: 0
        sh_addralign: 0
        sh_entsize: 0

entry: 1
        sh_name: .interp
        sh_type: SHT_PROGBITS
        sh_flags: SHF_ALLOC
        sh_addr: 0xffffffff80200200
        sh_offset: 512
        sh_size: 13
        sh_link: 0
        sh_info: 0
        sh_addralign: 1
        sh_entsize: 0

objdump:

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .interp       0000000d  ffffffff80200200  0000000000200200  00000200  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

So this oddity and numbering difference is beyond
being powerpc64-specific.

It appears that the numbering in the st_shndx fields
in the elfdump output do match the section (when it
is not some special value). For example for the earlier
"entry: 50" there is a reference that matches:

entry: 16765
        st_name: __start_set_vnet
        st_value: 0xffffffff824dc200
        st_size: 0
        st_info: STT_NOTYPE STB_GLOBAL
        st_shndx: 50

in objdump output I need to match against
st_shndx-1 instead in order to find the
section information.


Context: head -r339076 based builds for both
powerpc64 and amd64. But powerpc64 was built
via devel/powerpc64-xtoolchain-gcc and the
powerpc64 system binutils are from base/binutils .


How much of this is expected?

I would guess that the empty sh_flags for powerpc64
are just wrong/inappropriate.

It is less clear for the first section header where
the two tools disagree (the same way in both
environments).


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)