From owner-freebsd-toolchain@freebsd.org Tue Oct 30 05:22:24 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03EA310D4AA2 for ; Tue, 30 Oct 2018 05:22:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic301-2.consmr.mail.bf2.yahoo.com (sonic301-2.consmr.mail.bf2.yahoo.com [74.6.129.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0E5073120 for ; Tue, 30 Oct 2018 05:22:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: FHEDemwVM1l.D5E2MX8iqFE8ViUCuwh5ThafUDudqFBFhaN3dQTNn7A9jYcjLpP CwYRWf6mVQL5KWndongPcUV6uLcMensS6JyatkY2_n7QGTc0YCyS8R1a1CZ0WB97aXt6jUHD2xHk p7gN8FdDdzPt45EPKJO.MPAEp5r56Fs7dUx6tWKYhFgBulpavD1nBldjBaDbWiPC47AOBvZauPK3 kV5wtH7g2QQSKHRs8z_7hvUiCOLolXG97HpWT4KgZgzzUVw16E_G9BqL2.RL2NzK355t1UYNcKcK liXjqvpCQdigBEWp6uAoSq768QETZHxoj_.bLl073RcWNLnT6MUl5jaiKaG1IGpIjaUs1ZM80_FG hySD5gkjvWpMQblBu0gkBUZuC1ErhreeUcob0m99hJx4w6j00ZHi7_PghRPCh78HGZ4TMHFyQ52f N4FWMe..d81Y_2CITOvXI2L4QvU1PD0MiwpYH45tGgO7clX382lA3ASVp5xyjV1x2imoKjz2UcJx 1qRntH0nRrXWH6AFRdDV6ZyMBB8BBsmPEa4fMLHExdGNgPaiZZcBX6aKtfd0Mgx_vPeVZAJbDKAn yQDjF830RsnyDQI2.HlMX_Aqp0H13GMwdwX6W3ClvU7MGbijhHo5UVJ0pniXBUEw8RVRRaOVg2Fh XFFVTNzAFiJm7OLSQWIiJSq9Vo455MgfaLARev_wxCidySrlODjTwVIqIC_AJT.OnOUp6ioaf6k7 R7k2SEfm3vuEMtzD7xMW8Z7UHpWusyd9DWXZN_srJK3K1K767c9RZ7.RhlVp0SbncX91ts7XjBxN SuRiK9thNvsei8lZCxEGrVH_BgX2Znh97Dp6.ciwaasvdwQzut0wJDL9rfarxfx1_LzaLvc4gXSi JH_DOnDq0380Ykruq9GEZ5DGz2gbE0zH.EPGMv33CLcE2NNDKbdQB33CIIFK33_LQFFjdf6SDbWq Yg6X5ald9TxP_o21Z8eCN4JvqxTlapghh240Gtkz5N5G3gEG6mdRIwAfFJ_LF.cadXFj7YDtRIzu 94VYfSZGEOmEV5wCBOuDs9wg7BUfjZq9u Received: from sonic.gate.mail.ne1.yahoo.com by sonic301.consmr.mail.bf2.yahoo.com with HTTP; Tue, 30 Oct 2018 05:22:17 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp420.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID a89d621bb30336f05689e7017f60c349 for ; Tue, 30 Oct 2018 05:22:13 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: objdump vs. elfdump for powerpc64 ( via devel/powerpc64-xtoolchain-gcc and base/binutils ) and amd64: some odd differences Message-Id: Date: Mon, 29 Oct 2018 22:22:11 -0700 To: FreeBSD Toolchain X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2018 05:22:24 -0000 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)