Re: Compilation Unit name
[no HTML]
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.
We already discarded the option of using dwarf_offdie_types since previously,
with libdwarf, it was passed true to:
dwarf_next_cu_header_c(dbg, Dwarf_Bool(true),
NULL,NULL,NULL,NULL,NULL,NULL,NULL,
&cu_die_off, NULL) == DW_DLV_OK )
and to:
int status = dwarf_siblingof_b(dbg, NULL, Dwarf_Bool(true), &cu_die, NULL);
De: Josh Stone
Enviado: quinta-feira, 16 de março de 2017 17:06
Para: SASHA NICOLAS DA ROCHA PINHEIRO; elfutils-devel@sourceware.org
Assunto: 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
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. Do you have any other thoughts why the sequence of function calls is not working, instead it is giving invalid dwarf? // libdw /* Read the header for the DWARF CU. */ extern int dwarf_nextcu (Dwarf *dwarf, Dwarf_Off off, Dwarf_Off *next_off, size_t *header_sizep, Dwarf_Off *abbrev_offsetp, uint8_t *address_sizep, uint8_t *offset_sizep) __nonnull_attribute__ (3); // libdwarf int dwarf_next_cu_header_c(Dwarf_Debug dbg, Dwarf_Bool is_info, Dwarf_Unsigned *cu_length, Dwarf_Half *cu_version, Dwarf_Off *cu_abbrev_offset, Dwarf_Half *cu_pointer_size, Dwarf_Half *cu_offset_size, Dwarf_Half *cu_extension_size, Dwarf_Sig8 *type_signature, Dwarf_Unsigned *type_offset, Dwarf_Unsigned *cu_next_offset, Dwarf_Error *err); De: Josh Stone Enviado: quinta-feira, 16 de março de 2017 19:29:12 Para: SASHA NICOLAS DA ROCHA PINHEIRO; elfutils-devel@sourceware.org Assunto: 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?
[Bug tools/21247] addr2line doesn't properly resolve filename/lineno
https://sourceware.org/bugzilla/show_bug.cgi?id=21247 --- Comment #2 from Marat Radchenko --- gimli was fixed ( https://github.com/gimli-rs/addr2line/pull/36 ) and now is consistent with binutils (and llvm-symbolizer). I also sent a patch to elftoolchain so it also resolves filename/lineno properly (though not function name yet): https://sourceforge.net/p/elftoolchain/tickets/545/#6d97 gimpi problem was that they didn't handle DW_AT_MIPS_linkage_name and DW_AT_specification. elftoolchain problem was that they din't handle DW_AT_ranges for compile units (and only looked at lo/hi addresses). I suspect that you do not resolve filename/lineno properly for the same reason. -- You are receiving this mail because: You are on the CC list for the bug.
