handling .gdb_index
by Tom Tromey
As part of a Fedora 14 feature, I'm adding a new section to debug files.
The feature is here:
https://fedoraproject.org/wiki/Features/GdbIndex#Scope
... but the new section has mostly been discussed on the archer list and
on irc.
This patch lets the elfutils 'strip' utility put the new section into
the .debug file. It also corrects an existing bug I happened to notice
at the same time, which is that .debug_pubtypes was not considered a
debugging section.
It also still does not consider .debug_types to be a debugging section.
I am not certain that this is a bug, as my understanding is that
.debug_types is not handled by elfutils in general yet.
Tom
diff --git a/libebl/ChangeLog b/libebl/ChangeLog
index ba3dc7d..cdcc3a0 100644
--- a/libebl/ChangeLog
+++ b/libebl/ChangeLog
@@ -1,3 +1,8 @@
+2010-07-07 Tom Tromey <tromey(a)redhat.com>
+
+ * eblopenbackend.c (default_debugscn_p): Add .gdb_index,
+ .debug_pubtypes.
+
2009-09-02 Petr Machata <pmachata(a)redhat.com>
* libebl/eblstrtab.c (morememory): Allocate memory in multiples of
diff --git a/libebl/eblopenbackend.c b/libebl/eblopenbackend.c
index cb17f03..b157c36 100644
--- a/libebl/eblopenbackend.c
+++ b/libebl/eblopenbackend.c
@@ -1,5 +1,5 @@
/* Generate ELF backend handle.
- Copyright (C) 2000-2009 Red Hat, Inc.
+ Copyright (C) 2000-2010 Red Hat, Inc.
This file is part of Red Hat elfutils.
Red Hat elfutils is free software; you can redistribute it and/or modify
@@ -646,9 +646,12 @@ default_debugscn_p (const char *name)
/* GNU DWARF 1 extensions */
".debug_srcinfo",
".debug_sfnames",
+ /* GNU DWARF 4 extension */
+ ".gdb_index",
/* DWARF 1.1 and DWARF 2 */
".debug_aranges",
".debug_pubnames",
+ ".debug_pubtypes",
/* DWARF 2 */
".debug_info",
".debug_abbrev",
13 years, 10 months
dwarflint todo item
by Roland McGrath
cf https://bugzilla.redhat.com/show_bug.cgi?id=546017#c4
and http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2009-Dec...
These two things merit lint warnings in the high-level stratum.
1. DW_AT_const_value with a constant form that is actually meant to be an
address constant. This is a problem for consumers, because they expect
that only DW_FORM_addr operands need to be adjusted for PIC addresses,
while constant forms are exact integer constants. Only if the value of
DW_AT_const_value is DW_FORM_addr do we know that we might need to apply
an address adjustment at runtime.
You can detect this in a few ways:
In an ET_REL file, DW_FORM_data[48] with an operand that has a reloc
record. This is an entirely reliable test when you can do it. For
non-ET_REL files, you have to do some less perfect heuristics:
We think it only comes up with the data[48] forms, so you don't need to
try these heuristics with any other forms AFAICT.
If the value lies within some ELF symbol's st_value+st_size range (or
matches st_value exactly, in case of st_size=0), it was probably an
address.
If the DIE with DW_AT_const_value has a DW_AT_type (but use
dwarf_attr_integrate or equivalent for indirections), then if
that refers to a pointer type then it was probably an address.
(You may need to follow levels of typedef and qualifier DIEs to
find the DW_TAG_pointer_type or DW_TAG_reference_type and be sure.)
If either or both of those is true, then it probably was an address that
should have used DW_FORM_addr. OTOH, if it was a pointer type and the
value was 0, then that is probably a constant 0 whether or not any
symbol has st_value=0.
2. In a DWARF expression, DW_OP_addr used with DW_OP_GNU_push_tls_address
or DW_OP_form_tls_address. This is a related problem, with the same
issue for consumers, but the inverse false indication in what old
compilers generate.
The value on the stack before DW_OP_GNU_push_tls_address or
DW_OP_form_tls_address is an offset into the TLS block, not an address.
It doesn't get adjusted for any runtime bias like real addresses do.
So using DW_OP_addr is wrong and should get a warning.
For extra credit, you can test the constant value (either in wrong
DW_OP_addr or right DW_OP_const*/lit*) for sanity. This is really a
separate item and not at all necessary, but extra sanity checks are
always nice wishlist items. In an ET_REL file, the value should always
be one with a reloc record that uses a TLS *OFF reloc type (correct set
of types is machine-dependent and would need a new ebl hook). In other
files, the value should always be inside the p_memsz of the PT_TLS phdr.
Both of these trip up consumers and so should get a suspicious/wrong
warning. However, they both need to be in the quirks table for all extant
GCC versions. We hope to have 4.6 (and 4.[45]-RH) changed to do these two
differently so that DW_{FORM,OP}_addr exactly matches the set of address
constants that require runtime adjustment. But so far all GCC versions
emit the "wrong" patterns described above.
In all cases of DW_{FORM,OP}_addr, an extra check is for matching (having a
reloc pointing to, in ET_REL) an ELF symbol that is actually SHN_ABS. That
is not really the compiler's fault, since it didn't know what strangeness
with linker scripts or hand assembly was going to produce that. But it
will probably cause consumers to apply an adjustment when they shouldn't,
so a warning about it might be nice.
Thanks,
Roland
13 years, 10 months
vos fichiers email a tout petit prix
by easy-fichiers
Vous avez besoin de trouver de nouveaux clients rapidement et sans un gros investissement ?
Nous sommes spécialisés dans l'email marketing de prospection qui est un média idéal pour cibler des publics qualifiés et toucher vos prospects en bénéficiant d'un très rapide retour sur investissement.
EASY-FICHIERS vous offre la possibilité d'acheter des listes et fichiers d'adresses email professionnelles à tout petit prix !
MAIRIES
59,00 Euros ASSURANCES
79,00 Euros COIFFEURS
39,00 Euros RESTAURANTS
59,00 Euros
EASY-FICHIERS
13 years, 10 months