Spam on the list
by Kurt Roeckx
Hi,
I've been seeing alot of spam on this list the past week or
something. Could someone please check the filters? Mine
would have catched most of this if I didn't trust the
mailinglist.
Kurt
13 years, 4 months
0.148 status
by Roland McGrath
Since last week I've mostly worked on other branches that won't be on the
trunk very soon. But there was a little bit of change on the trunk.
I've tested the new DWARF4 support some, at least the readelf parts. The
.debug_line and .debug_frame v4 formats are not generated by anything, but
I don't think there are any regressions there anyway. For .debug_types and
v4 CUs, I did a trunk gcc bootstrap with -gdwarf-4 and shoved it all
through readelf. I fixed some nits along the way, but it all looks OK.
Mark and I talked about dwarf_cfi_validate_fde some more. There is no
imminent plan for anything to actually use it. Since it's somewhat
questionable that it's really a useful interface to have, I decided to just
back it out for now.
Mark reported testing the current code with systemtap and did not see any
problems. I've just done test rpm builds and not seen any problems.
(Actually, I'm still waiting for ppc and s390 builds to get scheduled.
If I commit some more build nits tonight, that'll be why.)
So things look well set for 0.148. I'm expecting Ulrich to cut the release
over this weekend, or Monday at the latest. I'll push it to Fedora 12 and
13 updates-testing immediately thereafter.
Ulrich, if you have any actual changes at all to merge, please give me a
chance to test them after pushing them and before cutting the release,
preferably before Monday.
Thanks,
Roland
13 years, 9 months
cfi branch
by Roland McGrath
In working on the relocate branch I thought about relocation-aware
interfaces for CFI, since that is one of the remaining holes there.
The only interface for actual decoding we have is dwarf_addrframe.
That doesn't make much sense with unresolved relocatable addresses.
Actually it could make sense to search for a Dwarf_Relocatable, in
the same sense that dwarf_haspc_relocatable does. So we might add
that at some point.
But it got me thinking that the only thing you'd really want to do
that makes sense is to iterate through all the frame states, where
the PC bounds of each state can be described in relocatable form.
I'd just mentioned this kind of iterator in the other thread with
Mark. But I had been thinking it would be significant work to add an
interface for that. It turns out it's not really.
So I made the roland/cfi branch forked from the trunk. This adds a
dwarf_cfi_frames call that iterates through the frame states. I
haven't tested it at all, but I think it's more or less sound, and it
was easy to do. I did this separate from the relocate branch because
I was thinking it could be merged in independently. It can, but I'm
doubtful there will be any use of this interface soon enough to want
to bake it before we want to merge relocate anyway.
I did merge the cfi branch into the relocate branch. So if I follow
through with CFI relocatability, dwarf_cfi_frames will work with that.
With that iterator, we can add the relocatability support under the
covers of Dwarf_Frame (as for Dwarf_Line). Then it just needs a
dwarf_frame_relocatable call that parallels dwarf_frame_info.
And we can consider adding dwarf_cfi_addrframe_relocatable for lookup.
All of that is probably only really useful when we have something for
it to feed. We could give readelf a decoded-frame printer, perhaps.
On the pipe-dream list remains the smart disassembler, which would
generate a stream of DWARF locations and expressions that a CFI
checker would match up with Dwarf_Frame register locations. Another
nice thought is a CFI generator from whole cloth, so we could
"compress" and consolidate by feeding it streams from .eh_frame and
.debug_frame input and generate our own smallest-encoded CFI with that
meaning. But those are not things that will happen soon. So it is
hard to justify any new APIs about this going onto the trunk in the
foreseeable.
Thanks,
Roland
13 years, 9 months
Credit court terme, ligne "DAILLY", Affacturage etc... consultez nous.
by SIT Group
Si ce message ne s'affiche pas correctement, visualisez la version en ligne.
Ce message vous est envoyé par : contact(a)srv1-sitgroup.com
Pour ne plus recevoir d'informations de notre part : Cliquez-ici pour vous désabonner.
«Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles.
Si vous n'êtes pas le destinataire escompte, merci d'en informer l'expéditeur immédiatement et de détruire ce courriel ainsi que tous les documents attaches de votre système informatique. Toute divulgation, copie du présent courriel et des documents attaches sans autorisation préalable de son émetteur est interdite.
This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorized disclosure, or copying hereof is prohibited.
Ce courriel commercial est conforme à la législation en vigueur et aux délibérations de la CNIL des 22 et 30 mars 2005 sur la prospection par courrier électronique dans le cadre professionnel. Conformément à l'article 34 de la loi 78-17 du 6 janvier mille neuf cent soixante dix huit, relative à l'informatique, aux fichiers et aux libertés, vous disposez d'un droit d'accès, de rectification des données nominatives vous concernant.
Le présent message est en parfait respect avec la déontologie et les bonnes pratiques de la communication par marketing direct électronique. Conformément à la législation en vigueur et des différents rectificatifs légaux, vous disposez d'un plein droit d'accès, de modifications ou de suppression des données personnelles vous concernant. Vous pouvez à tout moment exercer se droit sur demande écrite ou via notre espace prévu à cet effet. Conformément à la loi Informatique et libertés, vous pouvez vous désabonner à tout moment. Pour toute autre demande n'hésitez pas à nous écrire (Afin de faciliter le traitement de votre envoi, précisez votre demande dans l'objet et le corps du message).
Loi nº 78-17 du 6 Janvier mille neuf cent soixante dix huit, relative à l'informatique, aux fichiers et aux libertés : Toute personne physique a le droit de s'opposer, pour des motifs légitimes, à ce que des données à caractère personnel la concernant fassent l'objet d'un traitement. Elle a le droit de s'opposer, sans frais, à ce que les données la concernant soient utilisées à des fins de prospection, notamment commerciale, par le responsable actuel du traitement ou celui d'un traitement ultérieur. Les dispositions du premier alinéa ne s'appliquent pas lorsque le traitement répond à une nécessité légale ou lorsque l'application de ces dispositions a été écartée par une disposition expresse de l'acte autorisant le traitement de la publicité par voie électronique.
Art 38 : Toute personne physique a le droit de s'opposer, pour des motifs légitimes, à ce que des données à caractère personnel la concernant fassent l'objet d'un traitement. Elle a le droit de s'opposer, sans frais, à ce que les données la concernant soient utilisées à des fins de prospection, notamment commerciale, par le responsable actuel du traitement ou celui d'un traitement ultérieur. Les dispositions du premier alinéa ne s''appliquent pas lorsque le traitement répond à une obligation légale ou lorsque l'application de ces dispositions a été écartée par une disposition expresse de l'acte autorisant le traitement.
Pour ne plus recevoir d'informations de notre part : Cliquez-ici pour vous désabonner.
Si vous souhaitez vous désabonner, recopiez cette adresse dans la barre d'adresse de votre navigateur :
http://www.srv1-sitgroup.com/u-1.1.php?param=3Rbi_1IvEkRQjb1KxEsDQWYvAORt...
13 years, 9 months
relocate branch
by Roland McGrath
Over the last several days I've implemented most of the libdw lazy
relocation handling. This is the rest of the plan for which Petr
implemented all the low-level reader hooks a while ago.
This work is on the roland/relocate branch. I don't expect to merge this
branch in very quickly, probably not until we are ready to start using it
in the dwarf branch C++ stuff.
The core of it is that libdw itself groks the relocation sections in ET_REL
files. It only handles the basic 4 and 8 byte absolute relocation types,
the same ones that libdwfl understands today. These are all that ever
ought to appear in DWARF sections (or any other unallocated section).
This probably covers all the relocs in .eh_frame for non-PIC code too
(i.e. kernel modules, should those one day get .eh_frame again).
The internal workings are pretty lazy on multiple levels. (We hope this
means that things like just loading up 2000 kernel modules into a Dwfl
before you have looked at them will get much faster. We'll see.) At
dwarf_begin_elf time, all we do is notice that there are relocation
sections applying to our DWARF sections, and cache those Elf_Scn pointers.
The first time we need to look for a relocation in a particular DWARF
section, we digest the corresponding relocation section into internal form;
this just reads all the relocation records and looks at their types, so it
should be pretty quick. Thereafter, the digested relocations exist as two
parallel sorted arrays of pointers into the DWARF section data, one for
4-byte relocs and one for 8-byte relocs. Whenever we need to look up a
value that can be relocatable (__libdw_read_{address,offset}*), we do a
binary search (with a hint that should short-cut for sequential access
patterns) on that array.
For the internal uses (__libdw_formptr), relocations are always to defined
symbols (usually just section relative) in a .debug_* section, so we can
always resolve those. For files using REL instead of RELA (default on
i386), section-relative relocs (the normal case) usually don't actually
require any relocation work, because the symbol adds nothing (implicit
sh_addr is 0, st_value is 0 in a section symbol) and the reloc addend is
already in place in the data--so it's as if there were no reloc there at
all, and we don't even record it when we digest those relocs.
The interesting relocs are the ones for actual addresses rather than just
DWARF offsets, i.e. whose target symbols are in SHF_ALLOC sections. The
ways these get used are twofold.
Everything done via the existing interfaces has to resolve to a final
address value while reading. Those all go through __libdw_read_address.
If those have relocs, they might be to nonvariant symbols like a SHN_ABS.
If not, they need to be resolved. In the default case using plain libdw,
this just fails with a new error "value requires relocation". When using
libdwfl, this will (eventually) use the libdwfl symbol resolution code,
that looks up in module symbol tables, and uses the Dwfl section_address
callback. So to the existing libdwfl user, it will look the same, except
that section_address callbacks will be made on demand during dwarf_* calls
rather than all at once at dwfl_module_getdwarf time. I have not started
on updating libdwfl to tie into this yet.
The more interesting case is reloc-aware libdw users. This is what really
motivates this work now. The DWARF reader for ET_REL files has to be
reloc-aware and feed that knowledge into the DWARF writer to produce its
own relocs in the DWARF output. We'll need that for DWARF compression to
apply to Linux kernel modules.
The C interface for reloc-aware libdw revolves around Dwarf_Relocatable.
This is a new "opaque" but user-allocated struct. It is much like
Dwarf_Attribute: it just points to the data that needs to be decoded (and
possibly relocated). Various new calls return these (i.e. fill in a
user-supplied Dwarf_Relocatable) to stand in for Dwarf_Addr.
dwarf_form_relocatable corresponds to dwarf_formaddr. It just converts a
Dwarf_Attribute into a Dwarf_Relocatable that you can use later.
dwarf_line_relocatable corresponds to dwarf_lineaddr. It fetches the PC
from a Dwarf_Line as a Dwarf_Relocatable.
dwarf_ranges_relocatable corresponds to dwarf_ranges. It iterates over PC
ranges where each bound is a Dwarf_Relocatable.
dwarf_haspc_relocatable corresponds to dwarf_haspc, and is a convenience
function built on dwarf_ranges_relocatable as dwarf_haspc is built on
dwarf_ranges. It takes the PC to match as an opaque Dwarf_Relocatable, and
there is not yet any other way to directly compare those to each other. It
matches a relocatable address in a relocatable range if they are relocated
relative to the same section, and their offsets overlap within the section.
e.g., you might pass a Dwarf_Relocatable from dwarf_line_relocatable to
dwarf_haspc_relocatable if doing a "which scope is this source location
in?" check.
dwarf_getlocation_relocatable corresponds roughly to dwarf_getlocation or
dwarf_getlocation_addr. But since a "lookup" doesn't necessarily make
sense for unrelocated addresses, the interface is more like dwarf_ranges.
It is an iterator over the location list, yielding the range (as a pair of
Dwarf_Relocatable) and the location expression for that range.
We could have a lookup version that works akin to dwarf_haspc_relocatable.
But we'll see what comes up as needed for that. The iterators are what we
need to feed the writer side for compression. (dwarf_haspc_relocatable is
not needed for that, but was easy and obvious.)
So what is a Dwarf_Relocatable? It's very similar to a Dwarf_Attribute:
it's just a pointer to undecoded DWAR data. All these calls yielding a
Dwarf_Relocatable do not actually consider relocation at all. They even
work just the same on non-ET_REL objects that will never require relocation
handling. The actual search for a relocation record is not done until you
call dwarf_relocatable_info. (dwarf_haspc_relocatable does this inside.)
What the Dwarf_Relocatable represents is the information that a relocation
record has: a symbol table entry and an "addend" (i.e. offset from the
address indicated by the symbol). In RELA relocs, this is the r_addend
field in the reloc. In REL relocs, the addend is implicitly stored in the
section data itself. When there is no relocation at all, it has the same
effect as a REL reloc with no symbol: i.e., the whole address is just the
"addend" stored in the data.
An actual reloc can in some cases really have "no symbol"--the
GELF_R_SYM(r_info) is zero (aka STN_UNDEF) rather than a proper symtab
index. eu-strip produces relocs like this from useless section-relative
relocs for nonallocated sections. How do treat these is what I really
meant by "no symbol": as if it were a symtab entry with st_shndx of SHN_ABS
and st_value of 0. (You might also have a real symtab entry like that,
though they are useless.)
The "addend" inside a Dwarf_Relocatable is not always just the r_addend
from an actual ELF reloc record (or equivalent in-place value for REL).
In some of the DWARF formats addresses are encoded as relative to other
addresses in the DWARF. In .debug_line data, only the
DW_LNE_set_address operations set a relocatable address, and other
operations adjust the PC relative to that. So, a Dwarf_Relocatable from
dwarf_line_relocatable will indicate the symbol from an ELF reloc, with
the addend from the reloc plus the additional addend from DW_LN*
adjustments. Similarly, in .debug_ranges and .debug_loc, addresses are
added to a base address coming from an earlier record or from a CU's
DW_AT_low_pc attribute. In those cases, we only permit one of the two
addresses being added together to be relocatable. (The only reason for
these relative-address format details is so that many DWARF items can be
encoded as relative to one DWARF datum encoded with an ELF reloc.) So
in the Dwarf_Relocatable for these, the addend is (e.g.) that of the
reloc for the relocatable base address, plus the value of the individual
range list entry.
The dwarf_relocatable_info call extracts the symbol table entry in handy
form, and tells you the addend. It gives you the GElf_Sym, but it
doesn't actually tell you the symtab index if you wanted to construct an
ELF reloc record exactly matching or something like that. I imagine
that in the C++ interface this will be exposed as a pair of addend and
iterator into an STL-style container for the ELF symbol table
(std::vector work-alike).
Note that for the libdwfl world, you need to know which file that symbol
table resides in to make sense of its section indices. I haven't worked
out how best to gloss that yet.
So, what's not yet done?
Firstly, the libdwfl integration is not done at all. This is the
presumed reason for the one 'make check' regression the branch has now.
I haven't investigated that yet. The first task will be just to
rejigger the libdwfl innards so that they don't do the existing
__libdwfl_relocate work beforehand. Instead, libdwfl will poke pointers
into the libdw internals so that __libdw_read_address hooks call the
libdwfl symbol resolver.
In libdw proper, there are still some __libdw_read_address cases that
don't have relocation-aware parallel interfaces.
The .debug_aranges support (dwarf_getaranges) et al has no reloc-aware
variant. I'm not sure if we should bother with one. I'll have to
figure out if libdwfl can make dwarf_addrdie work without one. The
libdwfl uses are the only ones where .debug_aranges in an ET_REL really
means anything. The writer will always produce .debug_aranges from
whole cloth and not even want to read the incoming .debug_aranges.
CFI support needs to be reloc-aware at some point.
I'll talk more about CFI-related work separately.
I've been doing some hacking that's related.
The other thing missing support is in DWARF expressions. We have
dwarf_getlocation_relocatable for handling relocatability in the
location lists, but that just means the list address ranges. There is
also DW_OP_addr inside an expression block, which can use an address
with a relocation record. (Possibly we should let DW_OP_const[48][su]
have a reloc too. We don't use __libdw_read_address for those as yet.)
For that, we probably need a look-aside interface along the lines of
dwarf_getlocation_implicit_value. I may leave that until the C++ side
grows the code that would look inside expressions on the reader, which
will be needed for compression not to break relocatable DW_OP_addr's.
(It's also needed for DW_OP_call* that refer to the DIE tree, but those
don't seem to appear in nature.)
And, of course, it's all only barely tested at best.
The new interfaces are not tested at all.
I'll probably work next a bit more on CFI since I've started hacking on
it. (I'll post separately about that. But CFI handling is not a target
for compression in the near to medium term.) Then I'll try to tackle
libdwfl so that the branch doesn't regress for existing libdwfl users.
That will let me test the branch with stap, and maybe even find out if
it actually helped with speed/VM-load.
Thanks,
Roland
13 years, 9 months
DWARF 4 support, 0.148 plans
by Roland McGrath
In the absence of any feedback, I've merged my debug_types branch into the
trunk, and added dwarf_offdie_types for use in iteration schemes. I've
finished the various DWARF 4 support bits in readelf, including using that
for .debug_types iteration.
It all remains untested. The .debug_types support at least should be
testable with GCC. The .debug_line/.debug_frame new formats are not
produced by anything extant, so those changes won't likely get tested.
I've asked Ulrich to be ready to cut the 0.148 release next weekend or so.
So we have the coming week to get in some good testing.
Thanks,
Roland
13 years, 9 months
dwarf_getsrclines.c comparison between signed and unsigned integer expressions
by Mark Wielaard
Hi,
My (i686, f13) build gives:
gcc -D_GNU_SOURCE -DHAVE_CONFIG_H
-DLOCALEDIR='"/usr/local/install/systemtap/share/locale"' -DIS_LIBDW -I.
-I/home/mark/src/elfutils/libdw -I.. -I. -I/home/mark/src/elfutils/libdw
-I/home/mark/src/elfutils/lib -I..
-I/home/mark/src/elfutils/libdw/../libelf -std=gnu99 -Wall -Wshadow
-Werror -Wunused -Wextra -Wformat=2 -g -O2 -fstack-protector-all
-D_FORTIFY_SOURCE=2 -fgnu89-inline -MT dwarf_getsrclines.o -MD -MP
-MF .deps/dwarf_getsrclines.Tpo -c -o
dwarf_getsrclines.o /home/mark/src/elfutils/libdw/dwarf_getsrclines.c
cc1: warnings being treated as errors
/home/mark/src/elfutils/libdw/dwarf_getsrclines.c: In function
‘dwarf_getsrclines’:
/home/mark/src/elfutils/libdw/dwarf_getsrclines.c:438: error: comparison
between signed and unsigned integer expressions
/home/mark/src/elfutils/libdw/dwarf_getsrclines.c:533: error: comparison
between signed and unsigned integer expressions
make[4]: *** [dwarf_getsrclines.o] Error 1
The following fixes it:
diff --git a/libdw/dwarf_getsrclines.c b/libdw/dwarf_getsrclines.c
index afdf9db..75adc9c 100644
--- a/libdw/dwarf_getsrclines.c
+++ b/libdw/dwarf_getsrclines.c
@@ -433,7 +433,7 @@ dwarf_getsrclines (Dwarf_Die *cudie, Dwarf_Lines **lines, size_t *nlines)
goto invalid_data;
/* The length. */
- unsigned int len = *linep++;
+ int len = *linep++;
if (unlikely (lineendp - linep < len))
goto invalid_data;
13 years, 9 months
readelf.c: ‘u128’ may be used uninitialized in this function
by Mark Wielaard
Got another build failure (rhel6 beta x86_64 this time):
gcc -D_GNU_SOURCE -DHAVE_CONFIG_H
-DLOCALEDIR='"/usr/local/install/elfutils/share/locale"' -DDEBUGPRED=0
-DSRCDIR=\"/home/mark/src/elfutils/src\" -DOBJDIR=
\"/usr/local/build/elfutils-obj/src\" -I. -I/home/mark/src/elfutils/src
-I.. -I. -I/home/mark/src/elfutils/src -I/home/mark/src/elfutils/lib
-I.. -I/home/mark/src/elfutils/src/../libelf
-I/home/mark/src/elfutils/src/../libebl
-I/home/mark/src/elfutils/src/../libdw
-I/home/mark/src/elfutils/src/../libdwfl
-I/home/mark/src/elfutils/src/../libasm -std=gnu99 -Wall -Wshadow
-Werror -Wunused -Wextra -Wformat=2 -g -O2 -MT readelf.o -MD -MP
-MF .deps/readelf.Tpo -c -o
readelf.o /home/mark/src/elfutils/src/readelf.c
cc1: warnings being treated as errors
/home/mark/src/elfutils/src/readelf.c: In function
‘print_debug_line_section’:
/home/mark/src/elfutils/src/readelf.c:5800: error: ‘u128’ may be used
uninitialized in this function
I think the compiler is right and this should be fixed by:
diff --git a/src/readelf.c b/src/readelf.c
index 08b85ab..dbc8499 100644
--- a/src/readelf.c
+++ b/src/readelf.c
@@ -6029,6 +6029,7 @@ advance address by fixed value %u to %s\n"),
if (unlikely (standard_opcode_lengths[opcode] != 1))
goto invalid_unit;
+ get_uleb128 (u128, linep);
printf (gettext (" set isa to %u\n"), u128);
break;
}
13 years, 9 months
Proposition Commerciale
by Groupe Media Contact
Ce courriel commercial est conforme à la législation en vigueur et aux délibérations de la CNIL des 22 et 30 mars 2005 sur la prospection par courrier électronique dans le cadre professionnel. Conformément à l'article 34 de la loi 78-17 du 6 janvier mille neuf cent soixante dix huit, relative à l'informatique, aux fichiers et aux libertés, vous disposez d'un droit d'accès, de rectification des données nominatives vous concernant.
Le présent message est en parfait respect avec la déontologie et les bonnes pratiques de la communication par marketing direct électronique. Conformément à la législation en vigueur et des différents rectificatifs légaux, vous disposez d'un plein droit d'accès, de modifications ou de suppression des données personnelles vous concernant. Vous pouvez à tout moment exercer se droit sur demande écrite ou via notre espace prévu à cet effet. Conformément à la loi Informatique et libertés, vous pouvez vous désabonner à tout moment. Pour toute autre demande n'hésitez pas à nous écrire (Afin de faciliter le traitement de votre envoi, précisez votre demande dans l'objet et le corps du message).
Loi nº 78-17 du 6 Janvier mille neuf cent soixante dix huit, relative à l'informatique, aux fichiers et aux libertés : Toute personne physique a le droit de s'opposer, pour des motifs légitimes, à ce que des données à caractère personnel la concernant fassent l'objet d'un traitement. Elle a le droit de s'opposer, sans frais, à ce que les données la concernant soient utilisées à des fins de prospection, notamment commerciale, par le responsable actuel du traitement ou celui d'un traitement ultérieur. Les dispositions du premier alinéa ne s'appliquent pas lorsque le traitement répond à une nécessité légale ou lorsque l'application de ces dispositions a été écartée par une disposition expresse de l'acte autorisant le traitement de la publicité par voie électronique.
Art 38 : Toute personne physique a le droit de s'opposer, pour des motifs légitimes, à ce que des données à caractère personnel la concernant fassent l'objet d'un traitement. Elle a le droit de s'opposer, sans frais, à ce que les données la concernant soient utilisées à des fins de prospection, notamment commerciale, par le responsable actuel du traitement ou celui d'un traitement ultérieur. Les dispositions du premier alinéa ne s''appliquent pas lorsque le traitement répond à une obligation légale ou lorsque l'application de ces dispositions a été écartée par une disposition expresse de l'acte autorisant le traitement.
Pour ne plus figurer sur notre liste de diffusion : Cliquez-ici .
Si vous souhaitez vous désabonner, recopiez cette adresse dans la barre d'adresse de votre navigateur :
http://www.reply-etoileservice.com/u-1.1.php?param=3Rbi_1IvEkRQjb1KxEatT3...
13 years, 9 months