[llvm-dev] Getting _eh_frame parser for llvm

[Pete Cooper via llvm-dev]

Hi Igor

Thanks so much for working that out.  That was a very subtle issue that I just couldn’t see from the code itself.

Looks like Dave already gave a LGTM there so thats great.

Thanks again
Pete
> On Jan 23, 2016, at 8:57 AM, Igor Laevsky <igor at azulsystems.com> wrote:
> 
> Hi Pete,
> 
> I finally got my hands on windows machine and I think I found the issue. See http://reviews.llvm.org/D16509 for the fix. Thanks for the detailed explanation. It really helped to identify what was going wrong.
> 
> — Igor
> 
> On 20 Jan 2016, at 20:40, Pete Cooper <peter_cooper at apple.com> wrote:
> 
>> 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
>> 
>