2009-09-29 Status
by Petr Machata
Last week + today
-----------------
Time spent on elfutils: ~50%
writer:
* Emit .debug_ranges
* Emit .debug_loc
* dwarfcmp ./a.out ./a.out.out now works
It's on pmachata/dwarf-writer.
Next in plan
------------
* Merge in dwarf branch.
* Make dwarfcmp work for bigger files.
* We can't optimize certain references right away. For these we now
pick the biggest form available. We could shrink these fields
afterwards. But the codebase is not ready for this, e.g. gaps have to
be able to move, size of ElfData has to be patched, etc. So work on
preparing these bits, they will be useful later.
PM
13 years, 9 months
[PATCH] Allow configure to pass with non-bash shells
by Harald van Dijk
Hi all,
The attached patch (by Ryan Hill) fixes two minor issues that cause
problems when using a non-bash shell as /bin/sh (or when forcing
configure through such a shell). It replaces them with more portable
equivalents. This is unchanged between 0.143 and master.
The errors dash reported were:
./configure: 5467: Bad substitution
and after fixing that:
./configure: 5498: Syntax error: "(" unexpected
both of which cause the script to abort.
Is this something you can include in the next release?
13 years, 10 months
Recent changes in dwarf_getlocation
by Asier Aguirre
I'm getting some trouble with libdw since changeset:
https://fedorahosted.org/elfutils/changeset/cfdd86ed929c137eaca5dd49cd266...
with function dwarf_getlocation, trying to extract position of a data
member.
Given the following code:
/////////////
if(dwarf_hasattr(die, DW_AT_data_member_location))
{
Dwarf_Attribute attr;
Dwarf_Op *expr;
unsigned int exprlen;
if(dwarf_attr(die, DW_AT_data_member_location, &attr) &&
dwarf_getlocation(&attr, &expr, &exprlen)!=-1)
{
// dwarf_getlocation is returning -1, so
// this is not executed
}
}
/////////////
The new function check_constant_offset (attr, llbuf, listlen); is returning
-1 in this case. The attribute that is failing is:
(gdb) p *attr
$26 = {code = 56, form = 10, valp = 0xb7ad1e8b "\002#", cu = 0x80737cc}
DW_AT_data_member_location = 0x38 = 56
DW_FORM_block1 = 0x0a = 10
Am I doing something wrong? Is there another way to extract data member
location info?
Thanks!
13 years, 10 months
Segfault when reading a debug-only file.
by Kurt Roeckx
Hi,
It seems that there is a problem with reading files that only
have debug information. The file with debug info is split in
a file without debug info and one with only debug info. Such
a file still contains the section headers but not the actual
data the belongs to that section. The type has been changed
from PROGBITS to NOBITS.
Because it's set to NOBITS, nothing gets read from the file
(in __libelf_set_rawdata_wrlock()). In relocate_section()
it seems to assume that the section was loaded in memory, but
it isn't. tdata->d_buf is NULL. This later results in
a segfault.
This can be reproduced with "eu-readelf -a tst.debug".
I've attached a small test case which source was:
int main(){return 0;}
I then used:
gcc tst.c -o tst -g
objcopy --only-keep-debug tst tst.debug
elflint produces a whole bunch of warnings on that file,
mostly saying "wrong type: expected PROGBITS, is NOBITS"
There is also a little more information and an other testcase
at http://bugs.debian.org/556133
Kurt
13 years, 10 months
Re: Segfault when reading a debug-only file.
by Jay Vaughan
Ulrich Drepper wrote:
> Then fix file. It is wrong.
I'd rather adhere to standard and proper, correct, practices, and fix the problem where it
exists: in eu-readelf. I am grateful that there are other good programmers, such as
Roland McGrath, out there, who also believe in proper software development practices.
Real experts like Roland are, truly, rare.
--
;
--
Jay Vaughan
jay.vaughan(a)thalesgroup.com
13 years, 10 months
find_debuginfo_in_path()/validate() does not check that the file has debug info
by Kurt Roeckx
Hi,
It seems that find_debuginfo_in_path() in find-debuginfo.c
can return a file that does not contain debug information.
It calls validate() to see if the build id is the same,
but does not check that the file actually has debug info or
not.
We're seeing this problem on Debian systems using systemtap
because:
- systemtap sets the search path to "+:.debug:/usr/lib/debug:build"
- The name of the files with debug info is the same as original
file itself. On redhat systems it seems ".debug" is appeneded.
So the first file it looks at is actually the same file as
the one we're trying to find the debug info for. It has
the same build id, so it thinks it found it.
For more info about this, see:
http://bugs.debian.org/555549
Kurt
13 years, 10 months
eu-unstrip -n fails to process a coredump
by Denys Vlasenko
Hi,
I have a coredump which cannot be processed by eu-unstrip.
It is from crashed firefox's nspluginwrapper. Crashed binary is
/usr/lib/nspluginwrapper/npviewer.bin and
"ldd /usr/lib/nspluginwrapper/npviewer.bin" shows that
it is apparently a normal dynamically linked program.
Other people which are working with me on abrt
also say that some firefox crashes can't be processes.
It's likely they refer to this (or similar) problem.
[CC-ing abrt ml]
Coredump is about 200 MB big (bzipped 20 MB), I can send it
on request.
eu-unstrip just says this and exits with exitcode 1:
# eu-unstrip -n --core=coredump.big
eu-unstrip: coredump.big: Callback returned failure
I built unstrip from current git and it does the same.
With some instrumentation, I see that execution deviates from
"normal" flow (one which I see with good coredumps) in
libdwfl/link_map.c, report_r_debug(), here:
...
GElf_Addr next = addrs[0];
Dwfl_Module **lastmodp = &dwfl->modulelist;
int result = 0;
while (next != 0)
{
...
if (name != NULL && name[0] == '\0')
name = NULL;
/* If content-sniffing already reported a module covering
the same area, find that existing module to adjust.
The l_ld address is the only one we know for sure
to be within the module's own segments (its .dynamic). */
Dwfl_Module *mod;
int segndx = INTUSE(dwfl_addrsegment) (dwfl, l_ld, &mod);
if (unlikely (segndx < 0))
{fprintf(stderr, "%s.%d: %s() we return -1 (segndx:%d < 0)\n", __FILE__, __LINE__, "report_r_debug", segndx);
return release_buffer (-1);
}
...
The fprintf shown above triggers.
Full instrumented output is:
core-file.c.459: dwfl_core_file_report() dwfl_link_map_report ...
link_map.c.873: dwfl_link_map_report() report_r_debug(integrated_memory_callback) ...
link_map.c.210: integrated_memory_callback() dwfl_addrsegment(vaddr:7fa09549c276) returns mod->name:'ld-linux-x86-64.so.2' mod->main.name:'(null)'
link_map.c.216: integrated_memory_callback() dwfl_module_address_section ...
derelocate.c.391: dwfl_module_address_section() check_module ...
derelocate.c.291: check_module() dwfl_module_getsymtab ...
dwfl_module_getdwarf.c.752: dwfl_module_getsymtab() find_symtab ...
dwfl_module_getdwarf.c.507: find_symtab() __libdwfl_getelf ...
dwfl_module_getdwarf.c.134: __libdwfl_getelf() find_elf ...
dwfl_module_getdwarf.c.138: __libdwfl_getelf() open_elf ...
dwfl_module_getdwarf.c.66: open_elf() file->name:'(null)'
dwfl_module_getdwarf.c.71: open_elf() returns CBFAIL: fd < 0
dwfl_module_getdwarf.c.140: __libdwfl_getelf() open_elf returned
dwfl_module_getdwarf.c.760: dwfl_module_getsymtab() we return -1
derelocate.c.298: check_module() dwfl_module_getsymtab returned error 16, we return true
derelocate.c.393: dwfl_module_address_section() we return NULL (check_module != 0)
link_map.c.228: integrated_memory_callback() we got scn == NULL and return false
link_map.c.210: integrated_memory_callback() dwfl_addrsegment(vaddr:7fa09549c276) returns mod->name:'ld-linux-x86-64.so.2' mod->main.name:'(null)'
link_map.c.216: integrated_memory_callback() dwfl_module_address_section ...
derelocate.c.391: dwfl_module_address_section() check_module ...
derelocate.c.291: check_module() dwfl_module_getsymtab ...
dwfl_module_getdwarf.c.752: dwfl_module_getsymtab() find_symtab ...
dwfl_module_getdwarf.c.760: dwfl_module_getsymtab() we return -1
derelocate.c.298: check_module() dwfl_module_getsymtab returned error 16, we return true
derelocate.c.393: dwfl_module_address_section() we return NULL (check_module != 0)
link_map.c.228: integrated_memory_callback() we got scn == NULL and return false
link_map.c.389: report_r_debug() we return -1 (segndx:-1 < 0)
unstrip: coredump.big: Callback returned failure
and it is different from unstrip runs or "good" coredump only in two last lines,
those continue like this:
derelocate.c.393: dwfl_module_address_section() we return NULL (check_module != 0)
link_map.c.228: integrated_memory_callback() we got scn == NULL and return false
link_map.c.453: report_r_debug() we return result:6
dwfl_module_getelf.c.58: dwfl_module_getelf() __libdwfl_getelf ...
dwfl_module_getdwarf.c.134: __libdwfl_getelf() find_elf ...
dwfl_module_getdwarf.c.138: __libdwfl_getelf() open_elf ...
dwfl_module_getdwarf.c.66: open_elf() file->name:'(null)'
dwfl_module_getdwarf.c.71: open_elf() returns CBFAIL: fd < 0
dwfl_module_getdwarf.c.140: __libdwfl_getelf() open_elf returned
dwfl_module_getdwarf.c.675: find_dw() __libdwfl_getelf ...
...and here we are getting 1st line of the output:
0x400000+0x209000 23c77451cf6adff77fc1f5ee2a01d75de6511dda@0x40024c - - [exe]
...
Instrumentation is attached.
So, is it a bug?
--
vda
13 years, 10 months
How Would you Like To Say Goodbye To Your Power Bill...?
by boss@iammyownboss.co.uk
Hello,
Have you found yourself frustrated due to the ever-rising power
bills?
I have found myself struggling with the same problem as well,
But now, there is a solution. Did you know that you can generate your
own
electric energy, using a magnetic energy generator.
It works by itself, and it produces absolutely free energy.
It's called Magniwork, visit the following link to find out more :
>>> Click Here!
<http://2814679amcrtfr3ln2pa4asb2j.hop.clickbank.net/?tid=FEP>
It is getting widely popular and people are starting to massively
implement
these generators, and completely eliminate their power bills.
Proceed to:
>>> Click Here!
<http://2814679amcrtfr3ln2pa4asb2j.hop.clickbank.net/?tid=FEP>
Also, They're currently running a special discount, and I have never
seen
Magniwork being priced so low. However, I have some 'inside'
information
that this offer is only going to last for
a few days only, so you better take advantage of it, before the
price goes back up
>>> Click Here!
<http://2814679amcrtfr3ln2pa4asb2j.hop.clickbank.net/?tid=FEP>
p.s They're so sure that this will slash your power bill, that
they're
even offering an unconditonal 60 day money back guarantee!!
--
If you do not want to receive any more newsletters,
http://www.solduk.com/design/mailer/?p=unsubscribe&uid=3dfe93460f65bac524...
To update your preferences and to unsubscribe visit
http://www.solduk.com/design/mailer/?p=preferences&uid=3dfe93460f65bac524...
Forward a Message to Someone
http://www.solduk.com/design/mailer/?p=forward&uid=3dfe93460f65bac524bf6b...
--
Powered by PHPlist, www.phplist.com --
13 years, 10 months
elf_rawdata failing when using ELF_C_READ
by Martin Storsjö
Hi,
When using libelf from elfutils 0.143, the elf_rawdata function fails (and
elf_errmsg says "out of memory") when trying to get raw data using these
function calls:
int fd = open(elfinput, O_RDONLY);
Elf* elf = elf_begin(fd, ELF_C_READ, NULL);
size_t filesize = 0;
const char* rawdata = elf_rawfile(elf, &filesize);
(The full uncut example reproducing this bug is attached.)
As far as I can tell, this is due to elf->maximum_size being ~0 when this
call is made. If I change the flags given to elf_begin to ELF_C_READ_MMAP,
this works fine.
The same example above works just fine when using libelf by Michael
Riepe.
Is this a bug, or are there any prerequisites for calling elf_rawfile?
Kind regards,
// Martin Storsjö
13 years, 10 months