Re: [PATCH v3 2/2] Fix an undefined behavior in record_line

[Bernd Edlinger <bernd.edlinger@hotmail.de>]

On 4/5/20 12:55 AM, Andrew Burgess wrote:
> * Bernd Edlinger <bernd.edlinger@hotmail.de> [2020-04-04 18:34:07 +0200]:
> 
>> Okay, I think I see what is wrong.
>>
>>  Line Number Statements:
>>   [0x000000b4]  Extended opcode 2: set Address to 0x73c
>>   [0x000000bf]  Advance Line by 75 to 76
>>   [0x000000c2]  Copy
>>
>> ....
>>
>>   [0x00000129]  Extended opcode 2: set Address to 0x73c
>>   [0x00000134]  Advance Line by 1 to 73
>>   [0x00000136]  Copy
>>   [0x00000137]  Extended opcode 1: End of Sequence
>>
>> so the second line was previously deleted,
>> but now it is a non-is-stmt line.
>> The address is the same,
>>
>> There was previously a discussion that two consecutive line-entries are a
>> rogue method to notify the debugger of where the end of header is.
>> I don't recall in the moment where this code is located.
>> But if someone could point out the place to me, I could
>> probably add code to ignore non-is-stmt lines,
> 
> It's in symtab.c:skip_prologue_using_sal.
> 
>>
>> Andrew, are you already on that target, with one of your patches from
>> yesterday?
> 
> Not really.  The other aarch64 issue only required me to get a target
> started, so I was using the gdbsim.  But this is known to be pretty
> iffy, you'd probably have more luck building QEMU and running against
> that.
> 

Yeah, that is on my wish list since a while.

I have no idea how much work it is, I would also be
happy to have an aarch64 QEMU, for testing my openssl
patches, I heard they emulate the full instruction set.


Maybe not today, but what are the necessary steps?


Thanks
Bernd.

> Thanks,
> Andrew
> 
>>
>>
>> Thanks
>> Bernd.