[Bug tools/21792] Decode DWARF5 in eu-readelf
https://sourceware.org/bugzilla/show_bug.cgi?id=21792 Mark Wielaard changed: What|Removed |Added Status|NEW |RESOLVED CC||mark at klomp dot org Resolution|--- |FIXED --- Comment #1 from Mark Wielaard --- Although it isn't full DWARF5 support all DWARF5 tags and attributes are recognized in 0.170. From the NEWS file: Version 0.170 libdw: Added new DWARF5 attribute, tag, character encoding, language code, calling convention, defaulted member function and macro constants to dwarf.h. New functions dwarf_default_lower_bound and dwarf_line_file. dwarf_peel_type now handles DWARF5 immutable, packed and shared tags. dwarf_getmacros now handles DWARF5 .debug_macro sections. And the above example now shows: [ 7e1] namespace name (strp) "__cxx11" decl_file(data1) 1 decl_line(data2) 2214 export_symbols (flag_present) yes -- You are receiving this mail because: You are on the CC list for the bug.
Re: [PATCH] ar: Check whether ar header values fit.
On Fri, 2017-09-15 at 13:14 +0200, Mark Wielaard wrote: > When compiling with -O3 gcc finds an interesting error: > > src/ar.c: In function ‘do_oper_insert’: > src/ar.c:1077:56: error: ‘%-*ld’ directive output may be truncated > writing between 6 and 10 bytes into a region of size 7 [- > Werror=format-truncation=] > snprintf (tmpbuf, sizeof (tmpbuf), ofmt ? "%-*lo" : "%-*ld", > bufsize, val); > ^ > The problem is that the ar header values have to fit in a limited > (not zero terminated) string. We should check the snprintf return > value to see if the values are representable. > > Also make ar valgrind and ubsan clean and add a minimal sanity test. I pushed this to master.
Re: [PATCH v2] Make sure packed structs follow the gcc memory layout
Hi, Looks like you sent this as HTML-only email, which are rejected by the mailinglist. On Mon, 2017-08-21 at 12:57 +0200, Ulf Hermann wrote: > > Wouldn't this be a general problem for > > any struct that might be layed out differently but that we might > > map to some on-disk data structure? > > We should generally not rely on the layout of non-packed structs. The > compiler can insert padding in various places. I didn't find any > places where we do, though. I don't think the compiler can do that without breaking ABI. I believe we are very careful about the in-memory/on-disk struct layout matching. I am online now and found the documentation: https://gcc.gnu.org/onlinedocs/gcc/x86-Type-Attributes.html https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mms-bitfields > If packed is used on a structure, or if bit-fields are used, it may > be that the Microsoft ABI lays out the structure differently than the > way GCC normally does. Particularly when moving packed data between > functions compiled with GCC and the native Microsoft compiler (either > via function call or as data in a file), it may be necessary to > access either format. > > This option is enabled by default for Microsoft Windows targets. OK, so it is x86-only and it only affects packed structs or if the struct contains bitfields. Otherwise the layout should be the same. So I do think your patch is correct. I don't think we ever use structs that contain bit-fields to map from disk to memory. Applied to master now. Thanks, Mark
