elfutils-devel November 2009

elfutils-devel@lists.fedorahosted.org

14 participants
12 discussions

2009-09-29 Status
by Petr Machata 14 Dec '09

14 Dec '09

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

2 6

[PATCH] Allow configure to pass with non-bash shells
by Harald van Dĳk 23 Nov '09

23 Nov '09

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?

2 3

Recent changes in dwarf_getlocation
by Asier Aguirre 22 Nov '09

22 Nov '09

I'm getting some trouble with libdw since changeset: https://fedorahosted.org/elfutils/changeset/cfdd86ed929c137eaca5dd49cd266bb… 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!

3 4

Segfault when reading a debug-only file.
by Kurt Roeckx 17 Nov '09

17 Nov '09

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

4 7

Re: Segfault when reading a debug-only file.
by Jay Vaughan 16 Nov '09

16 Nov '09

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

1 0

Cute Kid of the Year - enter to win $25,000
by TheCuteKid＠iammyownboss.co.uk 14 Nov '09

14 Nov '09

Welcome to The CuteKid, the internet’s largest online child photo contest! Judged by professional talent and casting agents. Do you have a Cute Kid? If so, we invite you to join our growing community of loving parents just like you by submitting a photo of YOUR cute kid for a chance to win a $25,000 College Tuition Fund! Submit your photo today! <http://promo.iammyownboss.co.uk> Enter today and receive instant rewards like a 1 year subscription to Parenting Magazine and a 8X10 Canvas portrait of your photo. If you have a cute kid that is just waiting to be discovered, don’t delay. Membership is free and easy – Sign Up Today! <http://promo.iammyownboss.co.uk> For more information about the 2008 CuteKid™ of the Year Contest, please visit our How it Works page. If you seek more information including our address, Click here. <http://promo.iammyownboss.co.uk> -- If you do not want to receive any more newsletters, http://www.solduk.com/design/mailer/?p=unsubscribe&uid=3dfe93460f65bac524bf… To update your preferences and to unsubscribe visit http://www.solduk.com/design/mailer/?p=preferences&uid=3dfe93460f65bac524bf… Forward a Message to Someone http://www.solduk.com/design/mailer/?p=forward&uid=3dfe93460f65bac524bf6b0c… -- Powered by PHPlist, www.phplist.com --

1 0

find_debuginfo_in_path()/validate() does not check that the file has debug info
by Kurt Roeckx 13 Nov '09

13 Nov '09

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

1 0

eu-unstrip -n fails to process a coredump
by Denys Vlasenko 13 Nov '09

13 Nov '09

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

3 10

How Would you Like To Say Goodbye To Your Power Bill...?
by boss＠iammyownboss.co.uk 12 Nov '09

12 Nov '09

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=3dfe93460f65bac524bf… To update your preferences and to unsubscribe visit http://www.solduk.com/design/mailer/?p=preferences&uid=3dfe93460f65bac524bf… Forward a Message to Someone http://www.solduk.com/design/mailer/?p=forward&uid=3dfe93460f65bac524bf6b0c… -- Powered by PHPlist, www.phplist.com --

1 0

elf_rawdata failing when using ELF_C_READ
by Martin Storsjö 11 Nov '09

11 Nov '09

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ö

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

elfutils-devel November 2009