[ was: Re: [PATCH][gdb/testsuite] Fix
gdb.python/py-finish-breakpoint2.exp with -m32 ]

On 1/21/21 3:22 PM, Simon Marchi wrote:
> On 2021-01-21 3:45 a.m., Tom de Vries wrote:
>> On 1/21/21 9:29 AM, Tom de Vries wrote:
>>> The different outcomes for -m32 and -m64 are both valid given the
>>> semantics of FinishBreakpoint, which is "set at the return address of a
>>> frame".  It all depends where that return address is.  There is no
>>> guarantee that the return address is an insn that uniquely represent the
>>> function return control path.
>>
>> And, reading the documentation:
>> ...
>> Function: FinishBreakpoint.out_of_scope (self)
>>
>>     In some circumstances (e.g. longjmp, C++ exceptions, GDB return
>>     command, …), a function may not properly terminate, and thus never
>>     hit the finish breakpoint. When GDB notices such a situation, the
>>     out_of_scope callback will be triggered.
>> ...
>> this may be somewhat misleading or unclear, given that it's possible (as
>> the -m64 case demonstrates) that both:
>> - the function does properly terminate, and
>> - the finish breakpoint still hits (meaning the stop method is called).
>>
>> Thanks,
>> - Tom
>>
> 
> I think don't see how FinishBreakpoint can be useful with that kind of
> inconsistency.  Given that an exception is thrown in both cases, and the
> throw_exception_1 call frame never properly terminates, it seems obvious
> to me that out_of_scope should be called both times, and stop should not
> be called, both times.

Hi Simon,

thanks for your reaction, apologies for my late reaction.

I ran into this once more and gave it another try, that is, to
consolidate current state in terms of implementation, documentation and
testing.

I propose to commit this patch (perhaps split in two), and then
deprecate the functionality.

Thanks,
- Tom