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

[Andrew Burgess <andrew.burgess@embecosm.com>]

* 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.

Thanks,
Andrew

> 
> 
> Thanks
> Bernd.