Re: Compilation Unit name
On 03/16/2017 03:03 PM, SASHA NICOLAS DA ROCHA PINHEIRO wrote:
> /* Iterate over the compilation-unit headers. */
> size_t cu_header_size;
> for(Dwarf_Off cu_off = 0, next_cu_off;
> dwarf_nextcu(dbg, cu_off, &next_cu_off, &cu_header_size,
> NULL, NULL, NULL) == 0;
> cu_off = next_cu_off)
> {
> cerr << "Error message:" << dwarf_errmsg(-1) << endl;
> Dwarf_Die cu_die, *cu_die_p;
> cu_die_p = dwarf_offdie(dbg, next_cu_off /*cu_die_off*/, &cu_die);
I don't understand why you're using next_cu_off here.
The die offset is cu_off + cu_header_size.
Also, when you get around to it, note there's a different
dwarf_offdie_types when you're parsing .debug_types.
Re: Compilation Unit name
Stick to plain text, not HTML, if you want to reach the list. On 03/16/2017 03:44 PM, SASHA NICOLAS DA ROCHA PINHEIRO wrote: > I had that before, and it didn't work, then I empirically changed to > next_cu_off because it contained the same offset I was supposed to get > when I compared to the libdwarf execution. What you have called cu_die_off is *not* a die offset! In libdwarf.h that argument is called next_cu_header_offset, which is why it has the same value as the next_cu_off you're getting from libdw. > We already discarded the option of using dwarf_offdie_types since > previously, with libdwarf, it was passed true to: That's fine and correct. You shouldn't use dwarf_offdie_types now, I was trying to preempt a future problem. Sorry for adding confusion.
Re: Compilation Unit name
On 03/17/2017 10:18 AM, SASHA NICOLAS DA ROCHA PINHEIRO wrote: > I did not find the reference about the argument named > next_cu_header_offset (below I pasted the respective functions > signatures). Anyway, name orthography apart, what is being used in > Dyninst with libdwarf is exactly the value of what we called > next_cu_off, which corresponds to the third parameter of > dwarf_nextcu(), named in libdw as next_off. We must have different versions of libdwarf.h, but either way the point is that this value is not a die offset, just the offset of the next cu. In your libdwarf code, it looks like you only use "cu_die_off" in the call to dwarf_next_cu_header_c and for updating the "dies_seen" set. The latter is suspect, but probably fine in practice. You don't need the true die offset because dwarf_siblingof_b uses a NULL die input to specify that you want the first die of the current cu. It might help to call dwarf_dieoffset to see what it actually is. But libdw doesn't have a notion of a "current" cu, so you do need the correct offset for dwarf_offdie. I'm 99% sure cu_off + cu_header_size is the right value. > Do you have any other thoughts why the sequence of function calls is > not working, instead it is giving invalid dwarf? If the offset I suggest doesn't work, then I'm not sure what's going on. Maybe you could share the full code on a branch somewhere, with a test program to reproduce the problem?
Re: Group section
On 03/21/2017 12:38 PM, SASHA NICOLAS DA ROCHA PINHEIRO wrote:
>
> Hi Josh
> I am getting error on the following code, and it looks like to be related to
> group sections.
What is the error?
> As you can see I changed the dwarf_elf_init to dwarf_begin_elf, but passed
> NULL on the third parameter.
> Do you know how should I actually deal with it?
>
> 91 bool DwarfHandle::init_dbg()
>
> 92 {
>
> 93 //int status;
>
> 94 //Dwarf_Error err;
>
> 95 if (init_dwarf_status == dwarf_status_ok) {
>
> 96 return true;
>
> 97 }
>
> 98
>
> 99 if (init_dwarf_status == dwarf_status_error) {
>
> 100 return false;
>
> 101 }
>
> 102
>
> 103 //status = dwarf_elf_init(file->e_elfp(), DW_DLC_READ,
>
> 104 // err_func, &file_data, &file_data, &err);
>
> 105
>
> 106 file_data = dwarf_begin_elf(file->e_elfp(), DWARF_C_READ, NULL);
>
> 107 cerr << "Error message:" << dwarf_errmsg(-1) << endl;
>
> 108 if (!file_data) {
>
> 109 init_dwarf_status = dwarf_status_error;
>
> 110 return false;
>
> 111 }
>
Re: dwarf_line_srcfileno
On 03/30/2017 04:09 PM, SASHA NICOLAS DA ROCHA PINHEIRO wrote: > Hey all, what is the equivalent function to dwarf_line_srcfileno in lbdw?? I don't think libdw has an equivalent. Can you explain what you need it for?
Re: [PATCH] Avoid signed/unsigned comparison
On 04/27/2017 11:24 AM, Mark Wielaard wrote: > On Thu, Apr 20, 2017 at 04:40:30PM +0200, Ulf Hermann wrote: >> Some compilers implicitly cast the result of uint_fast16_t * >> uint_fast16_t to something signed and then complain about the >> comparison to (unsigned) size_t. > > Really? That is allowed? Using a signed type for uint_fast16_t? I think integer promotion (which happens before the operation) may use a signed int. It has to preserve the sign of the value itself, but I think not necessarily the signedness of the resulting type. Glibc uses "unsigned int"/"unsigned long int" for uint_fast16_t on 32/64-bit platforms, which means you won't get integer promotion.
Re: [PATCH] strip: Add --keep-section=SECTION and --remove-section=SECTION.
On 07/14/2017 08:28 AM, Mark Wielaard wrote: > Adds two new output options: > > --keep-section=SECTION Keep the named section. SECTION is an extended > wildcard pattern. May be given more than once. I tried this with rust libraries (eu-strip --keep-section=.rustc), and it seems to work as desired. Thanks!
failed reading "Smallest x86 ELF Hello World"
>From http://timelessname.com/elfbin/ Elfutils completely fails to read the file: $ eu-readelf --version eu-readelf (elfutils) 0.169 Copyright [...] $ eu-readelf -a hello eu-readelf: failed reading 'hello': invalid file descriptor It's not clear that we should care, since that page even says it's "a completely corrupted x86 ELF Binary that still runs." But since it's good enough for the kernel to run it, I'd hope for *something* from tools. It also seems weird to get the message "invalid file descriptor", from ELF_E_INVALID_FILE, which makes it sound like more like EBADF. The file descriptor itself is fine - it just doesn't like the ELF within. (DWARF_E_INVALID_FILE's message is just "invalid file".) FWIW, binutils readelf does better: $ readelf --version GNU readelf version 2.27-24.fc26 Copyright [...] $ readelf -a hello ELF Header: Magic: 7f 45 4c 46 01 01 01 48 69 20 57 6f 72 6c 64 0a Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: ABI Version: 105 Type: EXEC (Executable file) Machine: Intel 80386 Version: 0x1 Entry point address: 0x8048080 Start of program headers: 52 (bytes into file) Start of section headers: 309248 (bytes into file) Flags: 0x80cd Size of this header: 22763 (bytes) Size of program headers: 32 (bytes) Number of program headers: 2 Size of section headers: 40 (bytes) Number of section headers: 5 Section header string table index: 4 readelf: hello: Error: Reading 0xc8 bytes extends past end of file for section headers readelf: hello: Error: Section headers are not available! Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x00 0x08048000 0x08048000 0x000a2 0x000a2 R E 0x1000 LOAD 0xa4 0x080490a4 0x080490a4 0x9 0x9 W 0x9007b900 There is no dynamic section in this file.
Re: Difference between dwarf_getscopes and dwarf_getscopes_die
On 6/13/20 10:34 AM, Milian Wolff wrote: > Hey all, > > can someone explain me the difference between dwarf_getscopes and > dwarf_getscopes_die? Ideally, this should then be added to the documentation > too. dwarf_getscopes_die just follows the DWARF structure of direct DIE parents, whereas dwarf_getscopes is kind of a semantic view, most notably following DW_TAG_inlined_subroutine+DW_AT_abstract_origin to a different part of the DIE tree.
Re: Can dwarf_getscopes{,_die} performance be improved?
On 6/13/20 10:40 AM, Milian Wolff wrote: > Has anyone an idea on how to to post-process the DWARF data to optimize the > lookup of inlined frames? SystemTap implements its own cache for repeated lookups -- see dwflpp::get_die_parents().
