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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.