This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Python Finish Breakpoints


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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]