[PATCH v3 2/2] Fix an undefined behavior in record_line
Bernd Edlinger
bernd.edlinger@hotmail.de
Sun Apr 5 00:12:38 GMT 2020
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.
More information about the Gdb-patches
mailing list