<p dir="ltr"><br>
On Jan 26, 2016 10:00 AM, "Igor Laevsky" <<a href="mailto:igor@azulsystems.com">igor@azulsystems.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> I was very curious so I went ahead and resubmitted Pete’s original change. So far no buildbot failures, looks promising.<br>
><br>
>> On 26 January 2016 at 09:19, Pete Cooper via llvm-dev<br>
>> <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>><br>
>>> Sent from my iPhone<br>
>>><br>
>>>> On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>>> It would be great if there was a single<br>
>>>><br>
>>>> parser used by all llvm tools.<br>
>>><br>
>>> Absolutely. We'll get to that stage, I hope.<br>
>>><br>
>>> 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.<br>
>><br>
>><br>
>> +1.<br>
>><br>
>> A common parser is definitely a good thing.<br>
><br>
><br>
> 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?</p>
<p dir="ltr">Maybe. For splitting the only part we need is finding where each CIE and fde is.</p>
<p dir="ltr">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.</p>
<p dir="ltr">So we have fairly small needs, so it would be nice to have an api that doesn't parse everything upfront.</p>
<p dir="ltr">Cheers,<br>
Rafael</p>