llvm dev - Jan 2016 - Getting _eh_frame parser for llvm

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

On 20 January 2016 at 09:21, 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 would suggest first trying to reproduce the original issue on
windows and fixing just that.

Improvements can than be discussed independently.

Cheers,
Rafael

> On 20 January 2016 at 09:21, 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 would suggest first trying to reproduce the original issue on
> windows and fixing just that.
> 
> Improvements can than be discussed independently.
Unfortunately I can't find any record of the original test failure. Is there
a way to search for it in the buildbot archives?
> 
> Cheers,
> Rafael

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. It would be great if there was a single
parser used by all llvm tools.

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

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