public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
* Dwarf_FDE (libdw)
@ 2017-07-15  1:01 Sasha Da Rocha Pinheiro
  2017-07-15 21:30 ` Mark Wielaard
  0 siblings, 1 reply; 8+ messages in thread
From: Sasha Da Rocha Pinheiro @ 2017-07-15  1:01 UTC (permalink / raw)
  To: elfutils-devel

Hi,
I did not understand how to get the augmentation_data of a FDE. Could anyone explain me?
Also, is the start and end of Dwarf_FDE to be used as [initial_location, initial_location+address_range)??

Regards,
Sasha

typedef struct
{
  /* Section offset of CIE this FDE refers to.  This will never be
     DW_CIE_ID_64 in an FDE.  If this value is DW_CIE_ID_64, this is
     actually a Dwarf_CIE structure.  */
  Dwarf_Off CIE_pointer;

  /* We can't really decode anything further without looking up the CIE
     and checking its augmentation string.  Here follows the encoded
     initial_location and address_range, then any augmentation data,
     then the instruction stream.  This FDE describes PC locations in
     the byte range [initial_location, initial_location+address_range).
     When the CIE augmentation string uses 'z', the augmentation data is
     a DW_FORM_block (self-sized).  Otherwise, when we understand the
     augmentation string completely, fde_augmentation_data_size gives
     the number of bytes of augmentation data before the instructions.  */
  const uint8_t *start;
  const uint8_t *end;
} Dwarf_FDE;

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

* Re: Dwarf_FDE (libdw)
  2017-07-15  1:01 Dwarf_FDE (libdw) Sasha Da Rocha Pinheiro
@ 2017-07-15 21:30 ` Mark Wielaard
  2017-07-17  4:13   ` Sasha Da Rocha Pinheiro
  0 siblings, 1 reply; 8+ messages in thread
From: Mark Wielaard @ 2017-07-15 21:30 UTC (permalink / raw)
  To: Sasha Da Rocha Pinheiro; +Cc: elfutils-devel

On Sat, Jul 15, 2017 at 01:00:04AM +0000, Sasha Da Rocha Pinheiro wrote:
> I did not understand how to get the augmentation_data of a FDE.
> Could anyone explain me?

Dwarf_FDE is really low level. It might be easier to use a Dwarf_CFI to
get a Dwarf_Frame to extract the information.

You get a Dwarf_CFI_Entry from dwarf_next_cfi. This is a union.
Use dwarf_cfi_cie_p (entry) to see if it is an CIE, if so you can access
the augmentation data from the Dwarf_CIE cie. If not it is an FDE and you
can only access to Dwarf_FDE fde values. The Dwarf_Off CIE_pointer can
be used with dwarf_next_cfi () as offset to find the corresponding

> Also, is the start and end of Dwarf_FDE to be used as
> [initial_location, initial_location+address_range)??

No, it is the FDE instructions (encoded). How they are encoded is given
by the CIE augmentation data, so you would have to decode that first.

That is why you really should use Dwarf_CFI and Dwarf_Frame functions.
Those use this low level data structures to decode all the information.

Cheers,

Mark

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

* Re: Dwarf_FDE (libdw)
  2017-07-15 21:30 ` Mark Wielaard
@ 2017-07-17  4:13   ` Sasha Da Rocha Pinheiro
  2017-07-17 13:29     ` Mark Wielaard
  0 siblings, 1 reply; 8+ messages in thread
From: Sasha Da Rocha Pinheiro @ 2017-07-17  4:13 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: elfutils-devel

[Resending cause it seems it didn't go]

So how do you get the augmentation data out of a Dwarf_Frame? Or how do you "simulate" the two next functions as libdwarf do?

dwarf_get_cie_augmentation_data
dwarf_get_fde_augmentation_data




From: Mark Wielaard <mark@klomp.org>
Sent: Saturday, July 15, 2017 4:30 PM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: Dwarf_FDE (libdw)
    
On Sat, Jul 15, 2017 at 01:00:04AM +0000, Sasha Da Rocha Pinheiro wrote:
> I did not understand how to get the augmentation_data of a FDE.
> Could anyone explain me?

Dwarf_FDE is really low level. It might be easier to use a Dwarf_CFI to
get a Dwarf_Frame to extract the information.

You get a Dwarf_CFI_Entry from dwarf_next_cfi. This is a union.
Use dwarf_cfi_cie_p (entry) to see if it is an CIE, if so you can access
the augmentation data from the Dwarf_CIE cie. If not it is an FDE and you
can only access to Dwarf_FDE fde values. The Dwarf_Off CIE_pointer can
be used with dwarf_next_cfi () as offset to find the corresponding

> Also, is the start and end of Dwarf_FDE to be used as
> [initial_location, initial_location+address_range)??

No, it is the FDE instructions (encoded). How they are encoded is given
by the CIE augmentation data, so you would have to decode that first.

That is why you really should use Dwarf_CFI and Dwarf_Frame functions.
Those use this low level data structures to decode all the information.

Cheers,

Mark
    

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

* Re: Dwarf_FDE (libdw)
  2017-07-17  4:13   ` Sasha Da Rocha Pinheiro
@ 2017-07-17 13:29     ` Mark Wielaard
  2017-07-17 17:16       ` Sasha Da Rocha Pinheiro
  0 siblings, 1 reply; 8+ messages in thread
From: Mark Wielaard @ 2017-07-17 13:29 UTC (permalink / raw)
  To: Sasha Da Rocha Pinheiro; +Cc: elfutils-devel

On Mon, 2017-07-17 at 04:12 +0000, Sasha Da Rocha Pinheiro wrote:
> So how do you get the augmentation data out of a Dwarf_Frame?

You don't. You can only get the actual information relevant for the
frame through the augmentation data from the Dwarf_Frame. Is there
information missing you need?

> Or how do you "simulate" the two next functions as libdwarf do?
> 
> dwarf_get_cie_augmentation_data
> dwarf_get_fde_augmentation_data

I don't know what those functions do precisely. But if you really want
to do something low level like get the CIE augmentation data you could
do it through dwarf_next_cfi and DWarf_CFI_entry:

Dwarf_CFI_Entry entry;
dwarf_next_cfi (e_ident, d, true|false, off, &next, &entry);

if (dwarf_cfi_cie_p (&entry))
  {
     cie_aug = entry.cie.augmentation_data;
     cie_aug_size = entry.cie.augmentation_data_size;
  }
else
  {
    Dwarf_Off off = entry.fde.CIE_pointer;
    dwarf_next_cfi (e_ident, d, true|false, off, &next, &entry);
    assert (dwarf_cfi_cie_p (&entry));
    cie_aug = entry.cie.augmentation_data;
    cie_aug_size = entry.cie.augmentation_data_size;
  }

Plus some error handling. If you then also want to get the FDE
augmentation data it is a bit more work since you'll have to decode the
FDE data yourself (based on the CIE augmentation data you now got).

But instead of trying to extract the exact encoding of the low level
data it is probably better to see how we can make all the information
you need available through Dwarf_Frames.

Cheers,

Mark

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

* Re: Dwarf_FDE (libdw)
  2017-07-17 13:29     ` Mark Wielaard
@ 2017-07-17 17:16       ` Sasha Da Rocha Pinheiro
  2017-07-17 17:48         ` Mark Wielaard
  0 siblings, 1 reply; 8+ messages in thread
From: Sasha Da Rocha Pinheiro @ 2017-07-17 17:16 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: elfutils-devel

So you're saying that the augmentation data of a FDE is the augmentation data of its CIE?
https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/ehframechpt.html says differently.

The thing is I need to get catch blocks, and eh_frame is not exactly Dwarf format. That's why I need FDE augmentation data also.
Libdw doesn't do this, am I correct?
   
  
From: Mark Wielaard <mark@klomp.org>
Sent: Monday, July 17, 2017 8:28:56 AM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: Dwarf_FDE (libdw)
    
On Mon, 2017-07-17 at 04:12 +0000, Sasha Da Rocha Pinheiro wrote:
> So how do you get the augmentation data out of a Dwarf_Frame?

You don't. You can only get the actual information relevant for the
frame through the augmentation data from the Dwarf_Frame. Is there
information missing you need?

> Or how do you "simulate" the two next functions as libdwarf do?
> 
> dwarf_get_cie_augmentation_data
> dwarf_get_fde_augmentation_data

I don't know what those functions do precisely. But if you really want
to do something low level like get the CIE augmentation data you could
do it through dwarf_next_cfi and DWarf_CFI_entry:

Dwarf_CFI_Entry entry;
dwarf_next_cfi (e_ident, d, true|false, off, &next, &entry);

if (dwarf_cfi_cie_p (&entry))
  {
     cie_aug = entry.cie.augmentation_data;
     cie_aug_size = entry.cie.augmentation_data_size;
  }
else
  {
    Dwarf_Off off = entry.fde.CIE_pointer;
    dwarf_next_cfi (e_ident, d, true|false, off, &next, &entry);
    assert (dwarf_cfi_cie_p (&entry));
    cie_aug = entry.cie.augmentation_data;
    cie_aug_size = entry.cie.augmentation_data_size;
  }

Plus some error handling. If you then also want to get the FDE
augmentation data it is a bit more work since you'll have to decode the
FDE data yourself (based on the CIE augmentation data you now got).

But instead of trying to extract the exact encoding of the low level
data it is probably better to see how we can make all the information
you need available through Dwarf_Frames.

Cheers,

Mark
    

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

* Re: Dwarf_FDE (libdw)
  2017-07-17 17:16       ` Sasha Da Rocha Pinheiro
@ 2017-07-17 17:48         ` Mark Wielaard
  2017-07-17 17:53           ` Sasha Da Rocha Pinheiro
       [not found]           ` <BN6PR06MB30906C0218E8B06135F18B87A6A10@BN6PR06MB3090.namprd06.prod.outlook.com>
  0 siblings, 2 replies; 8+ messages in thread
From: Mark Wielaard @ 2017-07-17 17:48 UTC (permalink / raw)
  To: Sasha Da Rocha Pinheiro; +Cc: elfutils-devel

On Mon, Jul 17, 2017 at 05:16:00PM +0000, Sasha Da Rocha Pinheiro wrote:
> So you're saying that the augmentation data of a FDE is the augmentation
> data of its CIE?
> https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/ehframechpt.html
> says differently.

If you need to read the low-level augmentation data from an FDE then you
need to know whether it is there and how the FDE addresses are encoded.
Which is encoded in the CIE augmentation data.

> The thing is I need to get catch blocks, and eh_frame is not exactly
> Dwarf format. That's why I need FDE augmentation data also.
> Libdw doesn't do this, am I correct?

libdw handles both .debug_frame and .eh_frame data.
And you can use the Dwarf_Frames to unwind.
I believe the only thing not directly exposed are the lsda and
personality pointers. Is that the functionality that you need for
"catch blocks"?

Cheers,

Mark

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

* Re: Dwarf_FDE (libdw)
  2017-07-17 17:48         ` Mark Wielaard
@ 2017-07-17 17:53           ` Sasha Da Rocha Pinheiro
       [not found]           ` <BN6PR06MB30906C0218E8B06135F18B87A6A10@BN6PR06MB3090.namprd06.prod.outlook.com>
  1 sibling, 0 replies; 8+ messages in thread
From: Sasha Da Rocha Pinheiro @ 2017-07-17 17:53 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: elfutils-devel

Yes, that's what I am trying to do right now. 
Try/catch blocks or exception handling is the right term I guess.



From: Mark Wielaard <mark@klomp.org>
Sent: Monday, July 17, 2017 12:48 PM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: Dwarf_FDE (libdw)
    
On Mon, Jul 17, 2017 at 05:16:00PM +0000, Sasha Da Rocha Pinheiro wrote:
> So you're saying that the augmentation data of a FDE is the augmentation
> data of its CIE?
>  https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-PDA/LSB-PDA/ehframechpt.html


Chapter 8. Exception Frames - Linux Foundation
refspecs.linuxfoundation.org
Chapter 8. Exception Frames. When using languages that support exceptions, such as C++, additional information must be provided to the runtime environment that ...
> says differently.

If you need to read the low-level augmentation data from an FDE then you
need to know whether it is there and how the FDE addresses are encoded.
Which is encoded in the CIE augmentation data.

> The thing is I need to get catch blocks, and eh_frame is not exactly
> Dwarf format. That's why I need FDE augmentation data also.
> Libdw doesn't do this, am I correct?

libdw handles both .debug_frame and .eh_frame data.
And you can use the Dwarf_Frames to unwind.
I believe the only thing not directly exposed are the lsda and
personality pointers. Is that the functionality that you need for
"catch blocks"?

Cheers,

Mark
    

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

* Re: Dwarf_FDE (libdw)
       [not found]           ` <BN6PR06MB30906C0218E8B06135F18B87A6A10@BN6PR06MB3090.namprd06.prod.outlook.com>
@ 2017-07-21 19:39             ` Mark Wielaard
  0 siblings, 0 replies; 8+ messages in thread
From: Mark Wielaard @ 2017-07-21 19:39 UTC (permalink / raw)
  To: Sasha Da Rocha Pinheiro; +Cc: elfutils-devel

On Tue, 2017-07-18 at 16:50 +0000, Sasha Da Rocha Pinheiro wrote:
> From: Mark Wielaard <mark@klomp.org>
>> The thing is I need to get catch blocks, and eh_frame is not exactly
>> > Dwarf format. That's why I need FDE augmentation data also.
>> > Libdw doesn't do this, am I correct?
>> 
>> libdw handles both .debug_frame and .eh_frame data.
>> And you can use the Dwarf_Frames to unwind.
>> I believe the only thing not directly exposed are the lsda and
>> personality pointers. Is that the functionality that you need for
>> "catch blocks"?
>
> Are you thinking in exposing them?

I am thinking about it. But we don't currently store them. So we would
have reparse them. And since I haven't used them myself I am not sure
what they best way is to expose them. Are you currently using
Dwarf_Frames or Dwarf_CFI_Entry? Could you show some code that uses the
CFI with personality routines and lsda?

Thanks,

Mark

P.S. Please don't top-post. It makes it really hard to see the context.
P.P.S. Please don't add HTML to your postings. The mailinglist will drop
such messages.

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

end of thread, other threads:[~2017-07-21 19:39 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-07-15  1:01 Dwarf_FDE (libdw) Sasha Da Rocha Pinheiro
2017-07-15 21:30 ` Mark Wielaard
2017-07-17  4:13   ` Sasha Da Rocha Pinheiro
2017-07-17 13:29     ` Mark Wielaard
2017-07-17 17:16       ` Sasha Da Rocha Pinheiro
2017-07-17 17:48         ` Mark Wielaard
2017-07-17 17:53           ` Sasha Da Rocha Pinheiro
     [not found]           ` <BN6PR06MB30906C0218E8B06135F18B87A6A10@BN6PR06MB3090.namprd06.prod.outlook.com>
2017-07-21 19:39             ` Mark Wielaard

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).