Date: Mon, 29 Oct 2018 22:22:11 -0700 From: Mark Millard <marklmi@yahoo.com> To: FreeBSD Toolchain <freebsd-toolchain@freebsd.org> Subject: objdump vs. elfdump for powerpc64 ( via devel/powerpc64-xtoolchain-gcc and base/binutils ) and amd64: some odd differences Message-ID: <F6E5B9FD-87A4-422A-A37D-00AC2C6FD84F@yahoo.com>
next in thread | raw e-mail | index | archive | help
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:=20
sh_type: SHT_NULL
sh_flags:=20
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:=20
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:=20
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:=20
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:=20
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:=20
sh_type: SHT_NULL
sh_flags:=20
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).
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F6E5B9FD-87A4-422A-A37D-00AC2C6FD84F>