public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
* Compilation Unit name
@ 2017-03-16 22:04 SASHA NICOLAS DA ROCHA PINHEIRO
  2017-03-16 22:06 ` Josh Stone
  0 siblings, 1 reply; 6+ messages in thread
From: SASHA NICOLAS DA ROCHA PINHEIRO @ 2017-03-16 22:04 UTC (permalink / raw)
  To: elfutils-devel


Hello guys,
I work for Dyninst, and I am moving from libdwarf to libdw. I am trying  to get the compilation unit name calling dwarf_nextcu, dwarf_offdie and  dwarf_diename, but it won't work as it works with libdwarf. I got NULL  as return from dwarf_diename. When I print the error messages after each  of these three function calls, I get no errors for the first two and an  "invalid dwarf" for the third one. Can you help me with it?
Below I present the snippet where I am doing the calls, both with libdwarf and libdw.

Sasha Nicolas



//Using libdwarf
bool Object::fix_global_symbol_modules_static_dwarf()
{
    /* Initialize libdwarf. */
    ::Dwarf **dbg_ptr = dwarf->type_dbg();
    if (!dbg_ptr)
        return false;
    ::Dwarf *dbg = *dbg_ptr;
    std::set<Dwarf_Off> dies_seen;
    dwarf_parse_aranges(dbg, dies_seen);

    /* 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);
        cerr << "Error message:" << dwarf_errmsg(-1) << endl;

        if(cu_die_p == NULL) continue;
        if(dies_seen.find(next_cu_off/* cu_die_off*/) != dies_seen.end()) continue;

        std::string modname;
        auto diename = dwarf_diename(&cu_die);
        cerr << "Error message:" << dwarf_errmsg(-1) << endl;
        if(diename == NULL)
        {
            modname = associated_symtab->file(); // default module
        }
        else
        {
            modname = diename;
        }

...


//Using libdwarf

bool Object::fix_global_symbol_modules_static_dwarf()
{
    /* Initialize libdwarf. */
    Dwarf_Debug *dbg_ptr = dwarf->type_dbg();
    if (!dbg_ptr)
        return false;
    Dwarf_Debug dbg = *dbg_ptr;
    std::set<Dwarf_Off> dies_seen;
    Dwarf_Off cu_die_off;
    Dwarf_Die cu_die;
    dwarf_parse_aranges(dbg, dies_seen);
    /* Iterate over the compilation-unit headers. */
    while (dwarf_next_cu_header_c(dbg, Dwarf_Bool(true),
                                  NULL,NULL,NULL,NULL,NULL,NULL,NULL,
                                  &cu_die_off, NULL) == DW_DLV_OK )
    {
        int status = dwarf_siblingof_b(dbg, NULL, Dwarf_Bool(true), &cu_die, NULL);
        assert(status == DW_DLV_OK);
        if(dies_seen.find(cu_die_off) != dies_seen.end()) continue;
        std::string modname;
        if(!DwarfWalker::findDieName(dbg, cu_die, modname))
        {
            modname = associated_symtab->file(); // default module
        }

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Compilation Unit name
  2017-03-16 22:04 Compilation Unit name SASHA NICOLAS DA ROCHA PINHEIRO
@ 2017-03-16 22:06 ` Josh Stone
       [not found]   ` <BN3PR0601MB13452A525FF7EB29DC862A90A6260@BN3PR0601MB1345.namprd06.prod.outlook.com>
  2017-03-17 16:07   ` SASHA NICOLAS DA ROCHA PINHEIRO
  0 siblings, 2 replies; 6+ messages in thread
From: Josh Stone @ 2017-03-16 22:06 UTC (permalink / raw)
  To: SASHA NICOLAS DA ROCHA PINHEIRO, elfutils-devel

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Compilation Unit name
       [not found]   ` <BN3PR0601MB13452A525FF7EB29DC862A90A6260@BN3PR0601MB1345.namprd06.prod.outlook.com>
@ 2017-03-17  0:29     ` Josh Stone
  2017-03-17 17:18       ` SASHA NICOLAS DA ROCHA PINHEIRO
  0 siblings, 1 reply; 6+ messages in thread
From: Josh Stone @ 2017-03-17  0:29 UTC (permalink / raw)
  To: SASHA NICOLAS DA ROCHA PINHEIRO, elfutils-devel

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Compilation Unit name
  2017-03-16 22:06 ` Josh Stone
       [not found]   ` <BN3PR0601MB13452A525FF7EB29DC862A90A6260@BN3PR0601MB1345.namprd06.prod.outlook.com>
@ 2017-03-17 16:07   ` SASHA NICOLAS DA ROCHA PINHEIRO
  1 sibling, 0 replies; 6+ messages in thread
From: SASHA NICOLAS DA ROCHA PINHEIRO @ 2017-03-17 16:07 UTC (permalink / raw)
  To: Josh Stone, elfutils-devel

[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 <jistone@redhat.com>
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.

    

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Compilation Unit name
  2017-03-17  0:29     ` Josh Stone
@ 2017-03-17 17:18       ` SASHA NICOLAS DA ROCHA PINHEIRO
  2017-03-17 17:37         ` Josh Stone
  0 siblings, 1 reply; 6+ messages in thread
From: SASHA NICOLAS DA ROCHA PINHEIRO @ 2017-03-17 17:18 UTC (permalink / raw)
  To: Josh Stone, elfutils-devel

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 <jistone@redhat.com>
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.

    

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Compilation Unit name
  2017-03-17 17:18       ` SASHA NICOLAS DA ROCHA PINHEIRO
@ 2017-03-17 17:37         ` Josh Stone
  0 siblings, 0 replies; 6+ messages in thread
From: Josh Stone @ 2017-03-17 17:37 UTC (permalink / raw)
  To: SASHA NICOLAS DA ROCHA PINHEIRO, elfutils-devel

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?

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-03-17 17:37 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-16 22:04 Compilation Unit name SASHA NICOLAS DA ROCHA PINHEIRO
2017-03-16 22:06 ` Josh Stone
     [not found]   ` <BN3PR0601MB13452A525FF7EB29DC862A90A6260@BN3PR0601MB1345.namprd06.prod.outlook.com>
2017-03-17  0:29     ` Josh Stone
2017-03-17 17:18       ` SASHA NICOLAS DA ROCHA PINHEIRO
2017-03-17 17:37         ` Josh Stone
2017-03-17 16:07   ` SASHA NICOLAS DA ROCHA PINHEIRO

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).