On Thu, Dec 8, 2011 at 4:33 PM, Kevin Pouget <kevin.pouget@gmail.com> wrote:
> On Thu, Dec 8, 2011 at 3:56 PM, Tom Tromey <tromey@redhat.com> wrote:
>>>>>>> "Kevin" == Kevin Pouget <kevin.pouget@gmail.com> writes:
>>
>> Kevin> and we're .... not ready!
>> Kevin> there are some regressions this morning, certainly due to your
>> Kevin> ambiguous linespec patch!
>>
>> Kevin> first one is quite obvious:
>>
>> Kevin> a/gdb/testsuite/gdb.python/py-finish-breakpoint.exp
>> Kevin> -if ![runto "getpid"] then {
>> Kevin> -    fail "Cannot run to getpid."
>> Kevin> +if ![runto_main] then {
>> Kevin> +    fail "Cannot run to main."     return 0 }
>> Kevin> +gdb_breakpoint "getpid" {temporary}
>> Kevin> +gdb_test "continue" "Temporary breakpoint .*in getpid.*" "continue to getpid"
>> Kevin> +
>>
>> Kevin> "break getpid" used to work before actually starting the inferior, but
>> Kevin> now it's unresolved
>>
>> This test assumes that there is no debuginfo for getpid -- but in my
>> case, I have glibc debuginfo installed.  This isn't unheard of for gdb
>> developers :)
>>
>> The test would be more robust if you put a new function in a new file
>> and arranged for that file to be compiled without debuginfo.
>>
>> Sorry I didn't notice this before.
>
> I'll work on that, thanks for noticing it
>
>> Kevin> bpfinishpy_out_of_scope can't be triggered anymore because you set
>> Kevin> b-> pspace to NULL. I hesitated about how to fix it, but I think that
>> Kevin> FinishBP have to be bound to the pspace in which they were set, so I
>> Kevin> added this line:
>>
>> It seems to me that one of these breakpoints has to be thread-specific
>> as well.  Maybe the code to set b->pspace should notice thread-specific
>> breakpoints and allow pspace to be set there.
>>
>> I'd rather this be done in breakpoint.c than have other modules modify
>> struct breakpoint directly.
>>
>> Tom
>
> you're right about thread-specific, but I'm not sure how to enforce
> it. Currently, FinishBreakpoint only accepts a frame as parameter, and
> a frame is only bound to a pspace, not a thread ...
>
> My code
>> self_bpfinish->py_bp.bp->pspace = current_program_space;
> was wrong, it should rather be
>> pspace = get_frame_program_space (prev_frame);
> and this also implies that we can't really defer this setting to
> another place ...
>
> Maybe we can state in the documentation that FinishBreakpoint will be
> created by default in the selected thread, and add another parameter
> in the constructor to specify another thread?

so it was not possible to allow the user to specify the thread as I
suggest, for the reason I mentioned two lines above ... :(
I added this line to the doc to express it:

> Finish breakpoints are thread specific and must be create with the right
> thread selected.


cordially,

Kevin

(I'll send getpid fix tomorrow)