Re: [PATCH v2] Unify linking of libasm, libelf, libdw, backends
On Fri, Feb 17, 2017 at 04:11:28PM +0100, Ulf Hermann wrote: > Link them all with -z,defs,-z,relro,--no-undefined, provide complete > dependencies for the link steps, and add libeu.a to each one. libeu.a > contains useful library functionality that each of them might use. The > linker will strip unneeded symbols, so linking it in won't hurt even if > none of the functions are used. This is a nice cleanup. Sorry it took so long to review. Applied to master. Thanks, Mark
Re: [PATCH] Write to /dev/null rather than /dev/zero
On Thu, May 04, 2017 at 05:27:47PM +0200, Ulf Hermann wrote: > /dev/zero is meant for reading zeroes. /dev/null is for writing into > nirvana. Thanks, applied to master.
Re: [PATCH] backends: Don't depend on linux/bpf.h to compile bpf disassembler.
On Tue, Jul 18, 2017 at 02:19:58PM +0200, Mark Wielaard wrote: > We only need a few constants and one structure definition from linux/bpf. > Just define those in a local lib/bpf.h file. This makes sure the bpf > disassembler is always build and included even when elfutils is build > on older GNU/Linux systems (and even on other platforms). I pushed this to master.
Re: [PATCH] strip: Deal with ARM data marker symbols pointing to debug sections.
On Fri, Jul 21, 2017 at 12:17:40PM +0200, Mark Wielaard wrote: > ARM data marker symbols "$d" indicate the start of a sequence of data > items in a section. For data only sections no data marker symbol is > necessary, but may be put pointing to the start of the section. > binutils however has a bug which places a data marker symbol somewhere > inside the section (at least for .debug_frame). > https://sourceware.org/bugzilla/show_bug.cgi?id=21809 > > When strip finds a symbol pointing to a debug section that would be > put into the .debug file then it will copy over the whole symbol table. > This isn't necessary because the symbol is redundant. > > Add an ebl hook to recognize data marker symbols with implementations > for arm and aarch64. Use it in strip to strip such symbols from the > symbol table if they point to a debug section. Tested in Fedora rawhide where it fixed an rpm testsuite issue on arm. Pushed to master.
Re: [PATCH] ppc64: Add HTM SPRs support to readelf
Hi Mark, On 21-07-2017 16:55, Mark Wielaard wrote: > On Thu, 2017-07-20 at 17:49 -0400, Gustavo Romero wrote: >> Since POWER8, PowerPC 64 supports Hardware Transactional Memory, which has >> three special purpose registers associated to it: tfhar, tfiar, and texasr. >> This commit add HTM SPRs set as known note type so it's possible to use >> 'readelf --notes' to inspect the HTM SPRs in a coredump file generated in >> such a machines. > > This patch looks perfect, thanks. Thanks for reviewing it! > > We normally keep elf.h in sync with glibc. > Could you submit this elf.h change to libc-al...@sourceware.org? > Then we resync elf.h from glibc to pull in the new constants. It looks like glibc community won't review / push that change as it is in freeze for glibc 2.26 cut right now accordingly to [1]. If my understanding is correct, it's a blocker or my change can be pushed to elfutils and once glibc is open again (in about a week) I can submit this elf.h change to libc-al...@sourceware.org? Thank you and best regards, Gustavo [1] https://sourceware.org/ml/libc-alpha/2017-07/msg00018.htm
Re: [PATCH] ppc64: Add HTM SPRs support to readelf
On Mon, Jul 24, 2017 at 11:54:34AM -0300, Gustavo Romero wrote: > On 21-07-2017 16:55, Mark Wielaard wrote: > > This patch looks perfect, thanks. > > Thanks for reviewing it! > > > We normally keep elf.h in sync with glibc. > > Could you submit this elf.h change to libc-al...@sourceware.org? > > Then we resync elf.h from glibc to pull in the new constants. > > It looks like glibc community won't review / push that change as it is in > freeze for glibc 2.26 cut right now accordingly to [1]. > > If my understanding is correct, it's a blocker or my change can be pushed > to elfutils and once glibc is open again (in about a week) I can submit > this elf.h change to libc-al...@sourceware.org? Lets call it a soft-block :) It is just that I hate the files getting out of sync. We risk using slightly differently named constants. It looks like the 2.26 release will be next week, so hopefully the freeze will be over end of this week. Could you post the fix to libc-alpha already and then ping it next week once the tree open up again? Then I'll push your patch to elfutils. Thanks, Mark
Re: [PATCH] ppc64: Add HTM SPRs support to readelf
Hi Mark, On 24-07-2017 16:17, Mark Wielaard wrote: >>> We normally keep elf.h in sync with glibc. >>> Could you submit this elf.h change to libc-al...@sourceware.org? >>> Then we resync elf.h from glibc to pull in the new constants. >> >> It looks like glibc community won't review / push that change as it is in >> freeze for glibc 2.26 cut right now accordingly to [1]. >> >> If my understanding is correct, it's a blocker or my change can be pushed >> to elfutils and once glibc is open again (in about a week) I can submit >> this elf.h change to libc-al...@sourceware.org? > > Lets call it a soft-block :) It is just that I hate the files getting > out of sync. We risk using slightly differently named constants. It > looks like the 2.26 release will be next week, so hopefully the freeze > will be over end of this week. > > Could you post the fix to libc-alpha already and then ping it next > week once the tree open up again? Then I'll push your patch to > elfutils. Posted: https://sourceware.org/ml/libc-alpha/2017-07/msg00827.html Thank you and best regards, Gustavo
Re: [PATCH] ppc64: Add HTM SPRs support to readelf
I'll ping it next week and follow-up. Thanks! Regards, Gustavo On 24-07-2017 17:47, Gustavo Romero wrote: > Hi Mark, > > On 24-07-2017 16:17, Mark Wielaard wrote: We normally keep elf.h in sync with glibc. Could you submit this elf.h change to libc-al...@sourceware.org? Then we resync elf.h from glibc to pull in the new constants. >>> >>> It looks like glibc community won't review / push that change as it is in >>> freeze for glibc 2.26 cut right now accordingly to [1]. >>> >>> If my understanding is correct, it's a blocker or my change can be pushed >>> to elfutils and once glibc is open again (in about a week) I can submit >>> this elf.h change to libc-al...@sourceware.org? >> >> Lets call it a soft-block :) It is just that I hate the files getting >> out of sync. We risk using slightly differently named constants. It >> looks like the 2.26 release will be next week, so hopefully the freeze >> will be over end of this week. >> >> Could you post the fix to libc-alpha already and then ping it next >> week once the tree open up again? Then I'll push your patch to >> elfutils. > > Posted: https://sourceware.org/ml/libc-alpha/2017-07/msg00827.html > > Thank you and best regards, > Gustavo >
