Re: Get longjmp target check in breakpoint.c - is it necessary?
Sergio Durigan Junior <[email protected]>
| Newsgroups | gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
On Thursday, October 31 2013, Edjunior Barbosa Machado wrote: > Hi Tiago, Hey :-) > On 10/31/2013 12:36 AM, Tiago Stürmer Daitx wrote: >> We have in gdb/breakpoint.c the following condition checking: >> >> 3222 if (!gdbarch_get_longjmp_target_p (gdbarch))¬ >> 3223 » continue;¬ >> >> Which is forcing me to implement an (unnecessary?) arch specific >> get_longjmp_target while having a longjmp user probe in glibc should be >> enough. Removing that if/continue statement showed no regressions - it >> actually fixed 3 longjmp failures (assuming proper support in glibc for >> a longjmp probe is in place). > > If I understood correctly, there are different longjmps symbols search > strategies on this create_longjmp_master_breakpoint() function: the > recent libc probe search and the per-objfile cache lookup. > > It seems this 'if' works like an optimization to avoid searching for > symbols if the arch didn't provide support for get_longjmp_target(). > However, <arch>_get_longjmp_target() function became unnecessary in > targets that provide libc probe support, as you noticed with the > addition of probes on ppc64 glibc. > > What if you try to move this 'if' to a bit below in the function (right > before "for (i = 0; i < NUM_LONGJMP_NAMES; i++)" loop)? Edjunior is right, Tiago. This is a bug, actually. This check should be moved to the place Edjunior mentioned. Could you post a patch to fix that? Thanks a lot for looking into this :-). -- Sergio