elfutils-devel April 2011

elfutils-devel@lists.fedorahosted.org

9 participants
20 discussions

STB_GNU_UNIQUE vs ELFOSABI_LINUX
by Mark Wielaard 11 Apr '11

11 Apr '11

Hi, Does anybody know the story behind STB_GNU_UNIQUE showing up in ELFOSABI_NONE files? Since in eblsymbolbindingname we check the EI_OSABI for ELFOSABI_LINUX these show up as LOOS+0 instead of UNIQUE. My impression is that the check for ELFOSABI_LINUX is correct, but doesn't correspond to current practice for some reason. Anybody know the reason? Thanks, Mark

2 3

dwarflint versus linkage_name attributes
by Mark Wielaard 08 Apr '11

08 Apr '11

Hi, I was cleaning up the expected-at.cc table for dwarflint, in particular for DW_AT_linkage_name, which is the dwarf4 variant of DW_AT_MIPS_linkage_name. I removed some XXXs that I think are not valid anymore (in particlar DW_TAG_member shouldn't have a linkage_name attached, which was fixed in gcc some time ago). And I added a new check to see if there are DIEs which have a linkage_name, but aren't marked external. Patch attached and now on dwarf branch. But I am seeing lots of warnings with this. So either gcc is not following the dwarf spec, has some bugs, or I am misinterpreting things. The warnings are of two variants: - DW_TAG_variables, which do have a linkage_name, can be found in symtab (not checked by the code, just my manual spot checking), but don't have DW_AT_external set. I think this is just a gcc bug. - DW_TAG_union_type and DW_TAG_structure_type with DW_AT_linkage_name set (but not DW_AT_external, which on itself makes sense). These are unexpected because the dwarf spec doesn't explain why or how these would be necessary. The linkage_names strings can be pretty large, so it would be nice if we could get rid of them when not necessary. But I might have misinterpreted how they are actually used. So, does any of the above make sense? Cheers, Mark

5 19

readelf: display syms from .dynamic
by Marek Polacek 04 Apr '11

04 Apr '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I'm trying to add the '-D' option to readelf. This would fulfil this old request (binutils readelf already has it): https://bugzilla.redhat.com/show_bug.cgi?id=444621 It is quite clear that we have to first search for the PT_DYNAMIC segment and here find relevant DT_ symbols. Well, this is so far not a problem. But now I don't know how to continue. Let's say we're at DT_HASH symbol--this means, we can obtain the virtual address of .hash section from d_ptr value. Ok, we could probably extract buckets and chains and somehow derive the symbol name, but this doesn't sound like The Right Thing to do. The point is to get the GElf_Sym structure filled--preferably with the gelf_getsymshndx function, then just print the values (we don't need to care about version infromation). But it beats me how to use it. I don't see how to determine from the content of e.g. .hash which symbols from symtab appear here. If you think this effort is not worth it and we actually don't want this feature, or this would be too dramatic change, just tell me. Thanks, Marek And here's roughly where I am at: static void handle_syms_dyn (Ebl *ebl) { /* Do this exactly once. */ static bool dyn_syms_done; if (dyn_syms_done) return; dyn_syms_done = true; for (size_t i = 0; i < phnum; ++i) { GElf_Phdr phdr_mem; GElf_Phdr *phdr = gelf_getphdr (ebl->elf, i, &phdr_mem); /* Find the dynamic segment. */ if (phdr != NULL && phdr->p_type == PT_DYNAMIC) { Elf_Data *data = elf_getdata_rawchunk (ebl->elf, phdr->p_offset, phdr->p_filesz, ELF_T_DYN); if (data == NULL) return; const size_t n = data->d_size / gelf_fsize (ebl->elf, ELF_T_DYN, 1, EV_CURRENT); for (size_t j = 0; j < n; ++j) { GElf_Dyn dyn_mem; GElf_Dyn *dyn = gelf_getdyn (data, j, &dyn_mem); if (dyn != NULL) switch (dyn->d_tag) { case DT_HASH: printf ("DT_HASH: %#lx\n", dyn->d_un.d_ptr); continue; case DT_SYMTAB: printf ("DT_SYMTAB: %#lx\n", dyn->d_un.d_ptr); continue; case DT_GNU_HASH: printf ("DT_GNU_HASH: %#lx\n", dyn->d_un.d_ptr); continue; case DT_STRTAB: printf ("DT_STRTAB: %#lx\n", dyn->d_un.d_ptr); continue; default: continue; case DT_NULL: break; } break; } } } } -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iF4EAREIAAYFAk2aH18ACgkQt3gKtVPE8IIe3gD/X7EuRyaYaT5YProIjrDcv4Wr YtGHvPbgIVihpfI59ZkBAIQEC7CJRS/TGCf4hvh2dvb4xldPvCETnWMDEBO+0hPr =YJaK -----END PGP SIGNATURE-----

3 2

FYI: Update dwarf-knowledge.cc and expected-at.cc with DWARF4 tags and attributes.
by Mark Wielaard 04 Apr '11

04 Apr '11

Hi, I updated dwarf-knowledge.cc and expected-at.cc on the dwarf branch with the missing tags and attributes from the DWARF4 spec. Cheers, Mark

1 0

dwarflint allow strange combinations of attribute/form in gnu mode
by Mark Wielaard 04 Apr '11

04 Apr '11

Hi, I came across a strange combination of new attribute with old form for gcc. When gcc isn't using -gstrict-dwarf, it allows attributes from newer versions, but doesn't use new forms, even if such an attribute would need that. So this patch allows that (in particular for DW_AT_ranges for dwarf2), but only in gnu mode. Does this look like a sane solution? Thanks, Mark

2 2

[2/3, ppc64, elfutils patch] eu-strip vs. func addresses for GDB inferior calls
by Jan Kratochvil 04 Apr '11

04 Apr '11

Hi, the elfutils part. before the fix: binary: [11] .text PROGBITS 00000000100003e0 0003e0 000410 00 AX 0 0 16 [22] .opd PROGBITS 0000000010010ad8 000ad8 0000b8 00 WA 0 0 8 [28] .gnu_debuglink PROGBITS 0000000000000000 000c2c 00001c 00 0 0 4 .debug: [11] .text NOBITS 00000000100003e0 000250 000410 00 AX 0 0 16 [22] .opd NOBITS 0000000010010ad8 000250 0000b8 00 WA 0 0 8 ^^^^^^^^ [30] .debug_info PROGBITS 0000000000000000 0002b1 0000b1 00 0 0 1 after the fix: binary: [11] .text PROGBITS 00000000100003e0 0003e0 000410 00 AX 0 0 16 [22] .opd PROGBITS 0000000010010ad8 000ad8 0000b8 00 WA 0 0 8 [28] .gnu_debuglink PROGBITS 0000000000000000 000c2c 00001c 00 0 0 4 .debug: [11] .text NOBITS 00000000100003e0 000250 000410 00 AX 0 0 16 [22] .opd PROGBITS 0000000010010ad8 000250 0000b8 00 WA 0 0 8 ^^^^^^^^ [30] .debug_info PROGBITS 0000000000000000 000369 0000b1 00 0 0 1 The patch has been regression tested on x86_64-fedora14-linux-gnu, ppc64-rhel61-linux-gnu. Thanks, Jan src/ 2011-03-23 Jan Kratochvil <jan.kratochvil(a)redhat.com> * strip.c (handle_elf): Provide `.opd' copy for the .debug file. --- a/src/strip.c +++ b/src/strip.c @@ -883,7 +883,8 @@ handle_elf (int fd, Elf *elf, const char *prefix, const char *fname, bool discard_section = (shdr_info[cnt].idx > 0 && shdr_info[cnt].debug_data == NULL && shdr_info[cnt].shdr.sh_type != SHT_NOTE - && cnt != ehdr->e_shstrndx); + && cnt != ehdr->e_shstrndx + && strcmp (shdr_info[cnt].name, ".opd") != 0); /* Set the section header in the new file. */ GElf_Shdr debugshdr = shdr_info[cnt].shdr;

4 6

Added minimal support for DW_TAG_GNU_template
by Mark Wielaard 03 Apr '11

03 Apr '11

Hi, I added minimal support to the dwarf branch for DW_TAG_GNU_template. This is just enough to make sure that the various dwarf binaries don't barf when they encounter the unknown attribute. And to make sure there is a reference in the archive to the actual description: http://gcc.gnu.org/wiki/TemplateParmsDwarf Cheers, Mark

1 0

Cleanup unknown line opcode printing and add set_discriminator check
by Mark Wielaard 03 Apr '11

03 Apr '11

Hi, Richard Henderson noticed that unknown (extended) line opcodes were printed strangely. This patch fixes that by explicitly converting to numbers and printing as hex. It also adds a DW_LNE_set_discriminator check. I don't know if there is much to check here, I don't fully understand why they are needed in the first place. Commit pushed to the dwarf branch. But DW_LNE_set_discriminator should already have been recognized. I assume Richard had an old checkout but didn't configure with --enable-maintainer-mode which would have regenerated known-dwarf.h. I have also forgot that in the past. Is there a reason for not just generating known-dwarf.h always? It only needs awk, and I assume that is available on all systems by default we care about, isn't it? Cheers, Mark

1 1

dwarf branch now builds and runs against gcc 4.6
by Mark Wielaard 01 Apr '11

01 Apr '11

Hi, Since gcc 4.6 was just released (and fedora rawhide already packages it as system compiler) Petr and I (well mostly Petr) hacked the dwarf branch into submission to get the dwarf branch to compile and run against it. One patch was for a strange compile issue, we don't fully understand, since the new code should be exactly the same as the old one. But the fix was simple once found. The other was a bug in that we relied on a particular initialization order of the option global, which is now made explicit. Both in the attached patch and committed to the dwarf branch. Cheers, Mark

1 0

dwarlint: check_range_out_of_scope only check location of pc_contained_dies
by Mark Wielaard 01 Apr '11

01 Apr '11

Hi, I was seeing lots of warnings from dwarflint saying a location attribute was outside containing scope. This was for things like the DW_AT_location of a DW_TAG_formal_parameter. I think these shouldn't be checked. In fact the first check in recursively_validate () already only looked at code describing dies. So I made the second check for the location address ranges use the same logic. Does this look OK, or is it more subtle than that? diff -w attached, full patch on mjw/location-range branch (since it is mostly whitespace). Thanks, Mark

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

elfutils-devel April 2011