Re: [RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules
Hi Omar, On Mon, 2019-07-08 at 14:02 -0700, Omar Sandoval wrote: > I imagine that little by little, most of the libebl functionality could > be converted in this way, and that's how we could chip away at the size > increase of the elfutils binaries. > > Do you have any objections to patches 1-4 of my submission [2]? > > Thanks for the timely response! > > 1: https://sourceware.org/ml/elfutils-devel/2019-q3/msg00022.html > 2: https://sourceware.org/ml/elfutils-devel/2019-q3/msg00020.html I am still pondering this a little. But I do think (patches 1-4) is the (first) step forward. But I think I would like to do a 0.177 release with the last 4 months of fixes first. We normally do a release every 3-4 months, so it is about time, and it means your feature wouldn't have to wait that long. Although it would be a couple of months before it sees a release. But I think it would be good to have some time to make sure the idea works out in practice. So I would propose a release end of this week/start of next week. But without the libebl build rewrite. For the release there are then still 3 things pending: - The eu-elfclassify tool https://sourceware.org/ml/elfutils-devel/2019-q2/msg00018.html I had hoped on some feedback from the rpm hackers, since they are one if the intended users. And there are some (small) missing features and tests. Lets see where we are end if the week to see whether we can include that, or also postpone it to the next release. - The C-SKY backend: https://sourceware.org/ml/elfutils-devel/2019-q2/msg7.html This is really just blocked on me not making enough time for a final review. It looks good, but I am confused about one aspect of the DWARF register numbering issue. - The dwelf_elf_e_machine_string patch: https://sourceware.org/ml/elfutils-devel/2019-q2/msg00130.html I didn't see any objections, so I think this is good to go. Then after the release, somewhere next week, we'll apply your patches first and can then deal with any fallout and followups. I am thinking of moving some of the functionality into libdw proper (as cleaned up, exported api) to reduce the size increase a little. And add a mechanism for only building some of the backends (or maybe just drop some old ones that nobody uses anyway). Cheers, Mark
Re: [RFC PATCH 0/2] elfutils: don't use dlopen() for libebl modules
On Tue, Jul 09, 2019 at 09:14:03PM +0200, Mark Wielaard wrote: > Hi Omar, > > On Mon, 2019-07-08 at 14:02 -0700, Omar Sandoval wrote: > > I imagine that little by little, most of the libebl functionality could > > be converted in this way, and that's how we could chip away at the size > > increase of the elfutils binaries. > > > > Do you have any objections to patches 1-4 of my submission [2]? > > > > Thanks for the timely response! > > > > 1: https://sourceware.org/ml/elfutils-devel/2019-q3/msg00022.html > > 2: https://sourceware.org/ml/elfutils-devel/2019-q3/msg00020.html > > I am still pondering this a little. But I do think (patches 1-4) is the > (first) step forward. But I think I would like to do a 0.177 release > with the last 4 months of fixes first. We normally do a release every > 3-4 months, so it is about time, and it means your feature wouldn't > have to wait that long. Although it would be a couple of months before > it sees a release. But I think it would be good to have some time to > make sure the idea works out in practice. > > So I would propose a release end of this week/start of next week. But > without the libebl build rewrite. > > For the release there are then still 3 things pending: > > - The eu-elfclassify tool > https://sourceware.org/ml/elfutils-devel/2019-q2/msg00018.html > I had hoped on some feedback from the rpm hackers, since they are > one if the intended users. And there are some (small) missing > features and tests. Lets see where we are end if the week to see > whether we can include that, or also postpone it to the next release. > - The C-SKY backend: > https://sourceware.org/ml/elfutils-devel/2019-q2/msg7.html > This is really just blocked on me not making enough time for a > final review. It looks good, but I am confused about one aspect > of the DWARF register numbering issue. > - The dwelf_elf_e_machine_string patch: > https://sourceware.org/ml/elfutils-devel/2019-q2/msg00130.html > I didn't see any objections, so I think this is good to go. > > Then after the release, somewhere next week, we'll apply your patches > first and can then deal with any fallout and followups. I am thinking > of moving some of the functionality into libdw proper (as cleaned up, > exported api) to reduce the size increase a little. And add a mechanism > for only building some of the backends (or maybe just drop some old > ones that nobody uses anyway). This works for me, thanks! I'll keep an eye out for any followups, and I'm happy to help clean things up on the ebl side.
[Bug tools/24795] New: eu-unstrip doesn't recognize MIPS_DWARF as debug section
https://sourceware.org/bugzilla/show_bug.cgi?id=24795 Bug ID: 24795 Summary: eu-unstrip doesn't recognize MIPS_DWARF as debug section Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: tools Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org CC: elfutils-devel at sourceware dot org Target Milestone: --- Consider the section header table of a hello world exec on debian 7 MIPS: ... $ readelf -S hello There are 42 section headers, starting at offset 0xcf4: Section Headers: [Nr] Name TypeAddr OffSize ES Flg Lk Inf Al [ 0] NULL 00 00 00 0 0 0 [ 1] .interp PROGBITS00400154 000154 0d 00 A 0 0 1 [ 2] .note.ABI-tag NOTE00400164 000164 20 00 A 0 0 4 [ 3] .reginfo MIPS_REGINFO00400184 000184 18 18 A 0 0 4 [ 4] .note.gnu.build-i NOTE0040019c 00019c 24 00 A 0 0 4 [ 5] .dynamic DYNAMIC 004001c0 0001c0 f8 08 A 8 0 4 [ 6] .hash HASH004002b8 0002b8 40 04 A 7 0 4 [ 7] .dynsym DYNSYM 004002f8 0002f8 b0 10 A 8 1 4 [ 8] .dynstr STRTAB 004003a8 0003a8 85 00 A 0 0 1 [ 9] .gnu.version VERSYM 0040042e 00042e 16 02 A 7 0 2 [10] .gnu.version_rVERNEED 00400444 000444 20 00 A 8 1 4 [11] .rel.plt REL 00400464 000464 08 08 A 7 13 4 [12] .init PROGBITS0040046c 00046c 68 00 AX 0 0 4 [13] .plt PROGBITS004004e0 0004e0 30 00 AX 0 0 32 [14] .text PROGBITS00400510 000510 000290 00 AX 0 0 16 [15] .MIPS.stubs PROGBITS004007a0 0007a0 20 00 AX 0 0 4 [16] .fini PROGBITS004007c0 0007c0 38 00 AX 0 0 4 [17] .rodata PROGBITS00400800 000800 20 00 A 0 0 16 [18] .eh_frame PROGBITS00400820 000820 04 00 A 0 0 4 [19] .ctorsPROGBITS00410824 000824 08 00 WA 0 0 4 [20] .dtorsPROGBITS0041082c 00082c 08 00 WA 0 0 4 [21] .jcr PROGBITS00410834 000834 04 00 WA 0 0 4 [22] .data PROGBITS00410840 000840 10 00 WA 0 0 16 [23] .rld_map PROGBITS00410850 000850 04 00 WA 0 0 4 [24] .got.plt PROGBITS00410854 000854 0c 00 WA 0 0 4 [25] .got PROGBITS00410860 000860 28 04 WAp 0 0 16 [26] .sdataPROGBITS00410888 000888 04 00 WAp 0 0 4 [27] .bss NOBITS 00410890 00088c 10 00 WA 0 0 16 [28] .comment PROGBITS 00088c 39 01 MS 0 0 1 [29] .pdr PROGBITS 0008c8 60 00 0 0 4 [30] .debug_arangesMIPS_DWARF 000928 20 00 0 0 1 [31] .debug_info MIPS_DWARF 000948 88 00 0 0 1 [32] .debug_abbrev MIPS_DWARF 0009d0 3f 00 0 0 1 [33] .debug_line MIPS_DWARF 000a0f 64 00 0 0 1 [34] .debug_frame MIPS_DWARF 000a74 2c 00 0 0 4 [35] .debug_strMIPS_DWARF 000aa0 95 01 MS 0 0 1 [36] .debug_locMIPS_DWARF 000b35 2c 00 0 0 1 [37] .gnu.attributes LOOS+ff5 000b61 10 00 0 0 1 [38] .mdebug.abi32 PROGBITS 000b71 00 00 0 0 1 [39] .shstrtab STRTAB 000b71 000181 00 0 0 1 [40] .symtab SYMTAB 001384 000550 10 41 58 4 [41] .strtab STRTAB 0018d4 000273 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) ... After doing: ... eu-strip hello -o hello.stripped -f hello.debug ... we have: ... $ readelf -S hello.debug | grep NOBITS [ 1] .interp NOBITS 00400154 000154 0d 00 A 0 0 1 [ 3] .reginfo NOBITS 00400184 000174 18 18 A 0 0 4 [ 5] .dynamic NOBITS 004001c0 000198 f8 08 A 8 0 4 [ 6] .hash NOBITS 004002b8 000198 40 04 A 7 0 4 [ 7] .dynsym NOBITS 004002f8 000198 b0 10 A 8 1 4 [ 8] .dynstr NOBITS 004003a8 000198 85 00 A
[Bug tools/24795] eu-unstrip doesn't recognize MIPS_DWARF as debug section
https://sourceware.org/bugzilla/show_bug.cgi?id=24795 Mark Wielaard changed: What|Removed |Added CC||mark at klomp dot org --- Comment #1 from Mark Wielaard --- (In reply to Tom de Vries from comment #0) > Consider the section header table of a hello world exec on debian 7 MIPS: BTW. Isn't Debian 7 really old? > This is with an old eu-strip (0.152), but I don't manage building from git > for now, See the README: To build a git checkout do: autoreconf -i -f && \ ./configure --enable-maintainer-mode && \ make && make check Please let us know what issues you are seeing. > so atm I cannot say whether this is fixed on trunk or not. It isn't. elfutils doesn't have a MIPS backend and so knows nothing about special MIPS ELF constructs. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug tools/24795] eu-unstrip doesn't recognize MIPS_DWARF as debug section
https://sourceware.org/bugzilla/show_bug.cgi?id=24795 --- Comment #2 from Tom de Vries --- (In reply to Mark Wielaard from comment #1) > (In reply to Tom de Vries from comment #0) > > Consider the section header table of a hello world exec on debian 7 MIPS: > > BTW. Isn't Debian 7 really old? > Yep, initial release 2013. > > This is with an old eu-strip (0.152), but I don't manage building from git > > for now, > > See the README: > > To build a git checkout do: >autoreconf -i -f && \ >./configure --enable-maintainer-mode && \ >make && make check > Ah, ok. > Please let us know what issues you are seeing. > I tried elfutils-latest.tar.bz2 instead, and ran into the use of aligned_alloc, which is supported starting glibc v2.16, while debian 7 has glibc v2.13. > > so atm I cannot say whether this is fixed on trunk or not. > > It isn't. elfutils doesn't have a MIPS backend and so knows nothing about > special MIPS ELF constructs. Ah, I see indeed at https://sourceware.org/elfutils/ that mips is missing: ... Included backends for machine specific ELF handling: aarch64 alpha arm bpf i386 ia64 m68k ppc ppc64 s390 s390x sh sparc sparc64 tilegx x32 x86_64 ... -- You are receiving this mail because: You are on the CC list for the bug.
