elfutils-devel April 2010

elfutils-devel@lists.fedorahosted.org

44 participants
47 discussions

library name patch for 0.146
by P J P 03 May '10

03 May '10

Hi, This small patch to readelf.c displays the library name from which a dynamic symbol of specific version should be resolved. ===== diff --git a/src/readelf.c b/src/readelf.c index 5255860..c8c37f0 100644 --- a/src/readelf.c +++ b/src/readelf.c @@ -2068,9 +2068,11 @@ handle_symtab (Ebl *ebl, Elf_Scn *scn, GElf_Shdr *shdr) if (vernaux != NULL && vernaux->vna_other == *versym) { - printf ("@%s (%u)", + printf ("@%s %s (%u)", elf_strptr (ebl->elf, verneed_stridx, vernaux->vna_name), + elf_strptr (ebl->elf, verneed_stridx, + verneed->vn_file), (unsigned int) vernaux->vna_other); check_def = 0; } ===== Sample output: (edited to fit in space) looks like ===== $ ./readelf -s ar 0: ... DEFAULT UNDEF 1: ... DEFAULT UNDEF __errno_location(a)GLIBC_2.0 libc.so.6 (2) 2: ... DEFAULT UNDEF gelf_getsym(a)ELFUTILS_1.0 libelf.so.1 (3) 3: ... DEFAULT UNDEF basename(a)GLIBC_2.0 libc.so.6 (2) 4: ... DEFAULT UNDEF elf_strptr(a)ELFUTILS_1.0 libelf.so.1 (3) 5: ... DEFAULT UNDEF sysconf(a)GLIBC_2.0 libc.so.6 (2) 6: ... DEFAULT UNDEF memcmp(a)GLIBC_2.0 libc.so.6 (2) 7: ... DEFAULT UNDEF open64(a)GLIBC_2.1 libc.so.6 (4) 8: ... DEFAULT UNDEF elf_getdata(a)ELFUTILS_1.0 libelf.so.1 (3) 9: ... DEFAULT UNDEF __fsetlocking(a)GLIBC_2.2 libc.so.6 (5) ... ===== I would really appreciate it if it gets accepted for the main branch, as that'll be a lot of help to me. Thank you. -- Regards - Prasad

4 18

NLS support
by Kurt Roeckx 26 Apr '10

26 Apr '10

Hi, 0.146 now installs the translation files. But it doesn't seem to be doing anything with them, I can't get any translated output, strace suggests it doesn't do anything with the locale. config.log has: configure:4701: checking whether NLS is requested configure:4710: result: yes configure:4751: checking for msgfmt configure: trying /usr/bin/msgfmt... 0 translated messages. configure:4783: result: /usr/bin/msgfmt configure:4792: checking for gmsgfmt configure:4823: result: /usr/bin/msgfmt configure:4874: checking for xgettext configure: trying /usr/bin/xgettext... /usr/bin/xgettext: warning: file `/dev/null' extension `' is unknown; will try Cconfigure:4906: result: /usr/bin/xgettext configure:4952: checking for msgmerge configure: trying /usr/bin/msgmerge... configure:4983: result: /usr/bin/msgmerge configure:5214: creating ./config.status In the Makefile I see: USE_NLS = yes Is there something I should do to enable it? Kurt

2 2

dwarf_cfi_addrframe regression in elfutils 0.145 and 0.146
by Josh Stone 22 Apr '10

22 Apr '10

Hi, I'm getting a glibc double-free crash on Fedora i686, and I think it may be an elfutils regression. With 0.145 and 0.146 I get a crash, but 0.144 seems fine. I see this on i686 F12, F13, and F14. x86_64 is fine. I'm about to try a git-bisect on elfutils, but here's the crash info in the mean time: $ rpm -qa systemtap\* elfutils\* | sort elfutils-0.146-1.fc12.i686 elfutils-debuginfo-0.146-1.fc12.i686 elfutils-devel-0.146-1.fc12.i686 elfutils-libelf-0.146-1.fc12.i686 elfutils-libelf-devel-0.146-1.fc12.i686 elfutils-libs-0.146-1.fc12.i686 systemtap-1.2-1.fc12.i686 systemtap-debuginfo-1.2-1.fc12.i686 systemtap-runtime-1.2-1.fc12.i686 systemtap-sdt-devel-1.2-1.fc12.i686 systemtap-testsuite-1.2-1.fc12.i686 $ stap -p2 /usr/share/systemtap/testsuite/semok/thirtysix.stp *** glibc detected *** stap: double free or corruption (!prev): 0x05e97560 *** ======= Backtrace: ========= /lib/libc.so.6(-0xff53280f)[0xa6d7f1] /usr/lib/libdw.so.1(+0x11d9e)[0x7f7d9e] /usr/lib/libdw.so.1(dwarf_cfi_addrframe+0x68)[0x7f8428] stap(+0x1142a5)[0xd4e2a5] [...] With valgrind: [...] ==5136== Invalid free() / delete / delete[] ==5136== at 0x48057F6: free (vg_replace_malloc.c:325) ==5136== by 0x4890D9D: __libdw_frame_at_address (cfi.c:495) ==5136== by 0x4891427: dwarf_cfi_addrframe (dwarf_cfi_addrframe.c:70) ==5136== by 0x21C2A4: dwflpp::get_cfa_ops(unsigned long long) (dwflpp.cxx:2816) [...] ==5136== Address 0x82fbf10 is 0 bytes inside a block of size 432 free'd ==5136== at 0x48057F6: free (vg_replace_malloc.c:325) ==5136== by 0x488F41D: execute_cfi (cfi.c:395) ==5136== by 0x4890C0B: __libdw_frame_at_address (cfi.c:491) ==5136== by 0x4891427: dwarf_cfi_addrframe (dwarf_cfi_addrframe.c:70) ==5136== by 0x21C2A4: dwflpp::get_cfa_ops(unsigned long long) (dwflpp.cxx:2816) [...]

2 3

dwarf branch
by Roland McGrath 22 Apr '10

22 Apr '10

The status of my dwarf branch work is that it has sat untouched for some time now while I was otherwise occupied (mostly by vacation and being sick). All the work I'd committed anywhere was on the dwarf branch as of f7b29ae. I've now merged in the 0.146 trunk and verified it still builds. It's been far too long and I've lost most of my mental state about the work. Here's things as I recall them. I should get back to working on this by Monday or so and will probably spend quite a while just recovering everything I knew before about what I wrote. The current state of 'make check' is that the dwarfcmp tests will take forever. The tests on the all-C binaries complete. The tests on the binaries that use C++ all come last, and those may take forever. I don't think has anything magically to do with C++, it's just that the reference graphs are massively more complex than anything our C code produces. (As described below, I'm not sure if "forever" just means "way, way too long", but it might well really mean forever.) I recommend configuring with 'CXXFLAGS=-D_GLIBCXX_DEBUG -g'. That enables libstdc++ magic that gives clean errors for various buggy uses of containers and iterators and such that otherwise just lead to strange clobberation (and maybe still do anyway). Before commit f7b29ae I was observing some memory leaks that I could never make sense of. Possibly some dangling pointer crashes too (opposite of leaks). I don't recall any more which cases exhibited those problems, but I think it will come up somewhere in the dwarfcmp-self or dwarfcmp-test runs on the C++ binaries. (Of course, the binaries we have today are not the same binaries I tested before, but I bet we will find variants of the same problems. Once you find one, it's good to copy that binary off and preserve it as test data, rather than testing against the src/dwarf* binaries that change with every hack to the C++ stuff.) That commit disables using subr::sharing_stack from libdw/c++/subr.hh, which apparently has some kind of reference counting braino, but I just kept not understanding it. The purpose of sharing_stack was to reduce the massive memory bloat we get from the vanilla copying flavor of std::stack. In our uses, we always have common tails among many copied stack objects, so it saves a lot of memory. Also, they're proper stacks and so there are never any cycles, so reference-counting is viable. I imagine there is some canonical and far better C++ thingabob to use for this rather than whipping it up as I did. A reference-counted linked list should not be so hard at my age, but apparently I can't get it right. The memory bloat and bugs associated with trying to reduce it was all a side show to make the test runs less ridiculously slow and memory-intensive. In commit 4ce456a was supposed to be a "correct but slower" fix. That disabled a flavor of caching I had added to speed things up. But that caching turned out to have false-positives and so wound up causing a later assertion failure cascading from that false match. As I recall understanding it at the time, disabling the caching should have been the conservative and correct change to fix the semantic bug, just real slow. But on the complex cases, it takes so long now that I'm not sure whether it is actually in an infinite loop (albeit one without leaks or infinite recursion) or just unbelievably, monumentally slow (i.e. going to take weeks to complete). The caching involved is of an equivalence between two DIEs. In plain dwarfcmp, this is all part of plain comparison. In the dwarfcmp-test cases, i.e. writer bits, it is comparison done as part of the intrinsic duplication elimination of instantiating a CU in dwarf_output. In nontrivial examples, there are long and circular chains of references between DIEs. The comparison has a main walk that goes along the DIE tree structure, and then separate jump-started walks it takes when following a pair of reference attributes to see if they point to equivalent things. In practice, you have already walked most of the subtrees in the latter part of the main walk, as part of a subtree walk taken following a reference. Usually there are many references to the same DIEs, so you would visit each subtree many times this way. Hence, it makes sense during the walk to cache the match results found during side trips, and short-circuit repeating the same side trip again. This caching sped things up a lot. All the trouble comes from circular references. The reference-chasing code has logic to handle circularities. When a walk becomes circular, it short-circuits. But it's part of the comparison of attributes, so it still has to yield true or false as to whether these two refereneces are "equal". The logic is that if both sides of the comparison are congruent circularities, then they are "equal". By "congruent" I mean that if the left-hand side refers to A and the right-hand side refers to B, then the outer subwalk we are part of that has A as its left-hand side also has B as its right-hand side. If that is true, and the whole rest of the outer comparison subwalk rooted at A vs B also comes up matching, then A and B really do match and so these two references really do match and so their containing DIEs really do match and on up to A and B really do match and ... Never quote me for graph theory, but this seems to work right for the main comparison. However, at the time of the short-circuit, you don't actually know that A and B match, only that these two reference attributes do match if A and B do otherwise match. But, the caching code works by remembering the true/false result of the comparison between the DIEs containing these two reference attributes. When a DIE had one or more reference attributes that were deemed to match because of circularity, then you don't really know that this DIE matches (or that it doesn't). You only know that the result of that reference attribute comparison, and all the results that flow back up the walk from it, match the eventual result of completing the comparison subwalk for the DIE that's the root of that circularity. In some of the hairiest C++ cases, this bit me. There will be a large subtree like a class_type of the same name from two CUs we're comparing. The two sides will have many large matching subtrees, including circular references such as to each other or the containing class_type DIE. Then, far on down the line, there will be some subtrees that don't match or are missing on one side. That makes the whole class_type not match. Because of the circular references, that makes all those pairs of "matching" subtrees actually not match. But along the way, we'd thought they did match and cached that as true. I think this was fine enough for plain dwarfcmp, since those subtrees with the false cached results are only considered again for later references, and before that matters you will have failed the main comparison anyway. But the dwarf_output code uses those subtree matches along the way to decide what is and isn't a duplicate with some other subtree already collected, so this later causes things to blow up. IIRC the actual examples were of what should have been the same class_type (was the same in the source) in two different CUs, but the compiler omitted some method decls from one and not the other, or something like that. This seemed like it might well have been a compiler bug just on the semantics, and even if not definitely wrong per se is certainly an impediment to ideal deduplication. But before we worry about the compiler, we should make our code semantically correct for all kinds of input. Once it works, then these cases will show up when we instrument a little to look for similar-looking DIEs like a type with the same name (and path, i.e. qualified name) that do not wind up matching as duplicates. I think when last I was really hacking on this, I was trying to determine if the current code (with the caching disabled) really has infinite loops or actually just repeats walks so much that it can take literally days. I don't think I ever quite managed an answer to that. If it's really infinite, then something I don't understand is going on with the whole comparison algorithm. Assuming that would come out in the wash, my next game plan then (and now) is to revamp the caching. AFAICT this will entail reworking the whole result-propagation part of the main comparison control flow so that what propagates back up walks as they unwind is not just "true" but "match contingent on ..." where ... are the "pending" circularities. Then those results can be cached. When you reach one of those nodes that is the root of a detected circularity, then you can remove that contingency from all the cache entries. I haven't yet come to exactly how all that would be done. It's either that or punt my whole ad hoc algorithm in favor of some fancy proper method of comparing directed cyclic graphs for equivalence. But I don't know enough about that sort of thing to find one. Thanks, Roland

1 0

To it; and Stevens the carpenter, with his assist
by Randle Cosley 22 Apr '10

22 Apr '10

Were comfortable; and no one found any fault at the absence of the splendors with which they had been surrounded in the palace of the Guicowar, or even those of Bombay. A good breakfast was obtained, and the forenoon was given up to rest; but after a couple of hours in their chambers the company were assembled in the coffee-room. "Delhi is a city which figures largely in the history of India," said Lord Tremlyn, seated very informally in an arm-chair. "It existed fifteen or twenty centuries before the time of Christ, and was the capital of the great Aryan empire. It was founded by the invaders of India. The chronology of India is not reliable, but it is claimed that this event dates back to 3101 B.C. Its name was Indrapechta, which it holds to the present time among the learned Hindus, so that the city appears to have existed while Egypt was still in its infancy. "It became the great Mussulman capital; but one and another of its princes changed its location, till its ancient sites extend for thirty miles along the river, and its ruins, more extensive than even those of Rome, cover this range of territory. But I shall not go into the details of those migratory periods, but speak only of the city as we find it. "Delhi is on the Jumna River, which you saw in the early morning. This stream has its entire course in Hindustan, and is the principal tributary of the Ganges. Both of these rivers are sacred with the natives. The Jumna rises in the Himalayas, at a height of nearly eleven thousand feet, and of course it is a mountain torrent at its upper waters. After a run of eight hundred and sixty miles, it falls into the Ganges about three miles below Allahabad. On each side of it is an importa

1 0

elfutils 0.146
by Roland McGrath 21 Apr '10

21 Apr '10

How about cutting the release now? If you have any changes after 7c04e7a, let me sync and repeat test builds before you tag. Thanks, Roland

2 2

o him this
by Evanson Levin 20 Apr '10

20 Apr '10

The favor of the ministry, I was satisfied with myself for the resolution I had taken to retire in the midst of my triumphs, and at my return to crush those by whom I was envied. One thing in the publication of the work alarmed me, less on account of my safety than for the unburdening of my mind. At the Hermitage and at Montmorency I had seen with indignation the vexations which the jealous care of the pleasures of princes causes to be exercised on wretched peasants, forced to suffer the havoc made by game in their fields, without daring to take any oth

1 0

(no subject)
by Traci Abrams 19 Apr '10

19 Apr '10

Get the great discounts on popular software today at World SoftwareAll sofware is instantly available to download - No Need Wait!ALL OUR SOFTWARES ON ALL EUROPEAN LANGUAGES - USA, English, France, Italy, Spanish, German and more!!! Windows 7 Ultimate 32 bit Sale 70% Windows 7 Ultimate 64 bit Sale 70% Windows XP Professional with Service Pack 3 Sale 70% Office Professional 2007 Sale 70% Office Home and Student 2007 Sale 70% Office Enterprise 2007 Sale 70% Office Ultimate 2007 Sale 70% Office 2003 Professional (including Publisher 2003) Sale 70% Visio Professional 2007 Sale 70% Adobe Creative Suite 4 Master Collection Sale 70% Adobe Creative Suite 4 Design Premium Sale 70% Adobe Acrobat 9 Pro Extended Sale 70% Adobe Photoshop CS4 Extended Sale 70% CyberLink PowerDVD 9 Ultra Sale 70% WinZIP Pro 14 Sale 70% QuarkXPress 8 Sale 70% CorelDRAW Graphics Suite X4 Sale 70% AutoCAD 2010 32 and 64 bit Sale 70% FileMaker Pro 10 Advanced Sale 70% Nero 9 Reload Sale 70% ACDSee Pro 3 Sale 70% Kaspersky Internet Security 2010 Sale 70% Norton 360 Version 3.0 Premier Edition Sale 70% Also we have so much soft for MACINTOSH!!! Adobe Creative Suite 4 Master Collection for MAC Sale 70% Adobe Creative Suite 4 Design Premium for MAC Sale 70% Adobe Photoshop CS4 Extended for MAC Sale 70% Adobe Acrobat 9 Pro for MAC Sale 70% Adobe Creative Suite 3 Master Collection for MAC Sale 70% Adobe Creative Suite 3 Design Premium for MAC Sale 70% Microsoft Office 2008 Standart Edition for Mac Sale 70% StuffIt Deluxe 2009 for MAC Sale 70% Roxio Toast 10 Titanium Pro for MAC Sale 70% Mac OS X 10.6 Snow Leopard Sale 70% Aperture 3 for MAC Sale 70% Quark XPress 8 for MAC Sale 70% Parallels Desktop 5 Sale 70% FileMaker Pro 10 Advanced for MAC Sale 70% Mac OS X v10.5.6 Leopard Sale 70%6 Final Cut Studio 3 Full Pack with Content Sale 70% Logic Studio 8 Full Pack with Content Sale 70%To review full list of the offers, visit World Software .....www.doresofteas.net

1 0

(no subject)
by Virgil Daniel 19 Apr '10

19 Apr '10

Get the great discounts on popular software today at World SoftwareAll sofware is instantly available to download - No Need Wait!ALL OUR SOFTWARES ON ALL EUROPEAN LANGUAGES - USA, English, France, Italy, Spanish, German and more!!! Also we have so much soft for MACINTOSH!!!To review full list of the offers, visit World Software .....www.amerosofaas.net

1 0

thanks!
by Lynn Montes 18 Apr '10

18 Apr '10

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

elfutils-devel April 2010