llvm dev - Jan 2016 - Getting _eh_frame parser for llvm

> 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

On 20 January 2016 at 09:52, Igor Laevsky <igor at azulsystems.com>
wrote:
>> 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?
I think just running check-all on windows should find them.

Cheers,
Rafael

Hi Igor, Rafael

I’m very sorry.  You’ve both pinged me more than once about this and I haven’t
yet been able to find the cause of the issue.

Igor, the failures I saw on a number of bots were complaining about one of the
CHECK lines in the test case (test/tools/llvm-objdump/eh_frame-arm64.test)I
adapted in the given review.

The line in question was:

# CHECK:   DW_CFA_def_cfa: reg31 +0

but the bots complained saying that there was no 'DW_CFA_def_cfa: reg31 +0’
but there was a 'DW_CFA_def_cfa: reg0 +31’.

That led me to thinking there was an endian issue and that different bots were
reading either 0 or 31 in the different parts of this instruction.

Unfortunately, that seemed likely given the first couple of failing bots were
big endian, but then an x86 win7 bot failed, so endian issues are unlikely.

I’m going to take a look at the DWARF instruction parser again right now and see
if there’s anything obviously going wrong.

One option may be to just not check the instructions in the test case for now,
but commit the code again with all the other check lines in place.  Then we can
work on the instruction issue independently of everything else.

Note, I did take a look at the fixes you proposed.  I need to write a test to
ensure your handling of DW_EH_PE_omit is correct, but I think the changes are
good.  We can work on integrating those after landing the original patch
(assuming its eventually ok to do so).

Thanks,
Pete
> On Jan 20, 2016, at 6:58 AM, Rafael Espíndola via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On 20 January 2016 at 09:52, Igor Laevsky <igor at azulsystems.com>
wrote:
>>> 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?
> 
> I think just running check-all on windows should find them.
> 
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev