llvm dev - Jan 2016 - Getting _eh_frame parser for llvm

Hi,

I was very curious so I went ahead and resubmitted Pete’s original change. So
far no buildbot failures, looks promising.

On 26 January 2016 at 09:19, Pete Cooper via llvm-dev
<llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
wrote:

Sent from my iPhone

On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
It would be great if there was a single
parser used by all llvm tools.
Absolutely. We'll get to that stage, I hope.

We'll need to work out if there's a way to abstract what we need from
each client without slowing down or complicating any of them too much.

+1.

A common parser is definitely a good thing.

Agree. However currently DWARFDebugFrame doesn’t have any public interface.
Would it be a good first step to extract some reasonable set of accessors and
back them up by unit tests?


Cheers,
Rafael
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160126/832a98ce/attachment.html>

On Jan 26, 2016 10:00 AM, "Igor Laevsky" <igor at
azulsystems.com> wrote:
>
> Hi,
>
> I was very curious so I went ahead and resubmitted Pete’s original
change. So far no buildbot failures, looks promising.
>
>> On 26 January 2016 at 09:19, Pete Cooper via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>>
>>>
>>> Sent from my iPhone
>>>
>>>> On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>>>> It would be great if there was a single
>>>>
>>>> parser used by all llvm tools.
>>>
>>> Absolutely. We'll get to that stage, I hope.
>>>
>>> We'll need to work out if there's a way to abstract what we
need from
each client without slowing down or complicating any of them too
much.
>>
>>
>> +1.
>>
>> A common parser is definitely a good thing.
>
>
> Agree. However currently DWARFDebugFrame doesn’t have any public
interface. Would it be a good first step to extract some reasonable set of
accessors and back them up by unit tests?

Maybe. For splitting the only part we need is finding where each CIE and
fde is.

George wrote the code in lld that parses bits of .eh_frame and creates
.eh_frame_hdr. I think all it needs to parse is the location of the program
pointer for a fde.

So we have fairly small needs, so it would be nice to have an api that
doesn't parse everything upfront.

Cheers,
Rafael
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160126/2b09dda1/attachment.html>

>>
>> Hi,
>>
>> I was very curious so I went ahead and resubmitted Pete's original
change. So far no buildbot failures, looks promising.
>>
>>> On 26 January 2016 at 09:19, Pete Cooper via llvm-dev
>>> <llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>> wrote:
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>>> On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev
<llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
wrote:
>>>>> It would be great if there was a single
>>>>>
>>>>> parser used by all llvm tools.
>>>>
>>>> Absolutely. We'll get to that stage, I hope.
>>>>
>>>> We'll need to work out if there's a way to abstract
what we need from each client without slowing down or complicating any of them
too much.
>>>
>>>
>>> +1.
>>>
>>> A common parser is definitely a good thing.
>>
>>
>> Agree. However currently DWARFDebugFrame doesn't have any public
interface. Would it be a good first step to extract some reasonable set of
accessors and back them up by unit tests?
>Maybe. For splitting the only part we need is finding where each CIE and fde
is.
>George wrote the code in lld that parses bits of .eh_frame and creates
.eh_frame_hdr. I think all it needs to parse is the location of the program
pointer for a fde.
>So we have fairly small needs, so it would be nice to have an api that
doesn't parse everything upfront.
>
>Cheers,
>Rafael

For creating .eh_frame_hdr I was need to parse CIE to find pointer encoding for
the address pointers used in the FDE. And then used it to read the initial PC,
what was the main aim. Even the CIE augmentation string is not fully parsed
because once we found the encoding we have nothing to do there and just exit.
All unnecessary data was just skiped during parse process. So agree with Rafael
about api.


George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160127/ab671a3c/attachment.html>