library name patch for 0.146
by P J P
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
13 years, 4 months
NLS support
by Kurt Roeckx
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
13 years, 5 months
dwarf_cfi_addrframe regression in elfutils 0.145 and 0.146
by Josh Stone
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)
[...]
13 years, 5 months
dwarf branch
by Roland McGrath
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
13 years, 5 months
To it; and Stevens the carpenter, with his assist
by Randle Cosley
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
13 years, 5 months
elfutils 0.146
by Roland McGrath
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
13 years, 5 months
o him this
by Evanson Levin
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
13 years, 5 months
(no subject)
by Traci Abrams
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
13 years, 5 months
(no subject)
by Virgil Daniel
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
13 years, 5 months
thanks!
by Lynn Montes
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
13 years, 5 months