[PATCH] gdb: Don't skip prologue for explicit line breakpoints in assembler

[Pedro Alves]

On 6/22/19 12:23 PM, Andrew Burgess wrote:

>> The problem seems to be that when the explicit_line flag was first
>> added there was just function for decoding linespec line numbers
>> 'decode_all_digits'.  At some point in time this split into
>> decode_digits_ordinary and decode_digits_list_mode, when this happened
>> the explicit_line flag was only ever being set in one path.
>>
>> I suspect that if the behaviour you discussed above ever existed, then
>> it was before the split in how digits were decoded.

I'm like, 98.64% sure older gdbs behave like that.  But I can't rule out
misremembering without trying an old gdb, which I don't have built handy
at the moment either.

>>
>> I'm running out of time to investigate this today, but when I get some
>> more time I'll dig a little more on this line of enquiry to see if I
>> can confirm or deny the above theory.
> 
> The decode_all_digits function split into decode_digits_ordinary and
> decode_digits_list_mode with commit f8eba3c61629b3c03a back in Dec
> 2011, I suspect that the behaviour you recall would have stopped
> working then.  Though I haven't confirmed this (building such old
> versions of GDB is time consuming).

Indeed.

> 
> Related to what we're discussing seems to be commit a9e408182d2faaed5
> from Jan 2018, where we appear to double down on having the breakpoint
> file and line update to reflect where the breakpoint was placed, not
> where the breakpoint ended up.

Indeed.  Thanks for digging that up.

> 
> The question then would be if we can confirm GDB did used to behave
> the way you recall some time ago, do we want to go back to that
> behaviour now?  

No, I don't think we want to go back.

I've thought for a few years that "info breakpoints" should show
BOTH the canonical spec behind each breakpoint, and the actual
location(s) where the breakpoint is inserted.  It wouldn't
be that hard, even.  I cooked up a prototype patch for that.
I'll post it as a follow up.

> And is that a blocker for my change going in?  Yes if
> we did want to go back to the old behaviour then part of my patch
> would probably end up being reverted - as I suspect would
> a9e408182d2faaed5.  I'm happy to keep digging on this to see if I can
> confirm if/when the behaviour changed if that helps bring clarity to
> this issue.

Thanks,
Pedro Alves