STB_GNU_UNIQUE vs ELFOSABI_LINUX
by Mark Wielaard
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
13 years
dwarflint versus linkage_name attributes
by Mark Wielaard
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
13 years
readelf: display syms from .dynamic
by Marek Polacek
-----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-----
13 years
dwarflint allow strange combinations of attribute/form in gnu mode
by Mark Wielaard
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
13 years
[2/3, ppc64, elfutils patch] eu-strip vs. func addresses for GDB inferior calls
by Jan Kratochvil
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;
13 years
Cleanup unknown line opcode printing and add set_discriminator check
by Mark Wielaard
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
13 years
dwarf branch now builds and runs against gcc 4.6
by Mark Wielaard
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
13 years
dwarlint: check_range_out_of_scope only check location of pc_contained_dies
by Mark Wielaard
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
13 years