[llvm-dev] Getting _eh_frame parser for llvm

[George Rimar via llvm-dev]

>>

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