llvm dev - Jan 2016 - Getting _eh_frame parser for llvm

Sent from my iPhone
> On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> There is some eh_frame section parsing going on in the linker which is
> required for .eh_frame_hdr creation and probably useful for dead-frame
> elimination in the future.
I think there's 2 linker parsers (a macho one and elf/coff), runtime dyld,
and dwarf dump. 
> 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.

Pete
> 
> On Wed, Jan 20, 2016 at 2:21 PM, Igor Laevsky via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Hi all,
>> 
>> Not so long ago we have found ourselves in need of a robust _eh_frame
parser. All we wanted is the ability to parse .eh_frame section emitted by
LLVM's MCJIT. Considering this, LLVM would be a natural place for
implementing such parser.
>> 
>> Previous email thread about the issue
(https://groups.google.com/forum/#!topic/llvm-dev/Vb_VYU7Eo0k) showed some
interest among the community. Folks seemed to agree that DebugInfo is a good
place to put implementation in.
>> 
>> Next there was submission by Pete Cooper
(http://reviews.llvm.org/D15535). It completely covered the issue. However it
was reverted due to some windows test failures and wasn’t resubmitted since.
While I was adapting Pete’s parser for our needs I have found a couple of small
issues in it. However I can’t check if they were causing original failures.
>> 
>> So the question is what is the right way of moving this forward? I can
resubmit original Pete’s change with my fixes and see if it will cause any
failures. Or maybe there are some alternative approaches which we haven’t
thought about? Any opinions on this?
>> 
>> — Igor
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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:
>>
>> There is some eh_frame section parsing going on in the linker which is
>> required for .eh_frame_hdr creation and probably useful for dead-frame
>> elimination in the future.
> I think there's 2 linker parsers (a macho one and elf/coff), runtime
dyld, and dwarf dump.
>> 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.

Cheers,
Rafael

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>