Re: [catch-syscall] [patch] Drop entry_breakpoint at all

[Sérgio Durigan Júnior <sergiodj at linux dot vnet dot ibm dot com>]

On Wed, 2009-01-14 at 17:10 +0100, Jan Kratochvil wrote:
> Hi Sérgio,

Hi Jan,

> checked why there exists entry_breakpoint at all:
> breakpoint:
>    This is currently needed for us to know when to start setting
>    up catchpoints for syscalls in the inferior.  If we don't do that,
>    then we would set a "catch syscall" too early, which would
>    catch syscalls from ld.so and/or libc (and we don't want that).
> 
> I do not agree with this intention as I find perfectly valid to `catch
> syscall's for debugging of the ld.so startup.  Even `set debug infrun 1' etc.
> applies to this pre-main startup phase.  User is free and suggested to type
> `start' before typing `catch syscall'.

What really happened is that I was testing the patch one day (long time
ago, even before I submitted the first version of the patch), and I was
seeing a lot of segmentation faults. Unfortunately, I wasn't able to
solve them and asked for help, specifically from Thiago Bauermann and
Luis Machado. We investigated this issue a little deeper and found that
the probably reason for it was because the GDB was trying to catch
syscalls from ld.so. So, to solve this, we figured out this solution:
let's create an internal breakpoint which is going to be triggered
whenever the inferior's entrypoint is reached. After this, we are good
to enable the catch syscall if the user wants to.

I'm running my regression tests here in PPC and PPC64, and I really hope
that this patch doesn't bring this issue from the dead. If it does, then
we'll have to figure out another solution, or come back to the old one
(i.e., have the entry_breakpoint).

> The second part removes target_enable_tracesysgood() and makes it just
> a GNU/Linux-specific feature hooking the linux_enable_tracesysgood() call
> formerly at entry_breakpoint to be at the common first possible attach/start
> point of the inferior.
> 
> My reasons for Linuxizing target_enable_tracesysgood():
> (a1) Already the name suggests it is based on PTRACE_O_TRACESYSGOOD which is
>      a Linux-specific issue.  Other OSes would have a different name and even
>      different ways how to trace the syscalls.
> (a2) It makes it easy to hook the linux_enable_tracesysgood() call at the right
>      place without some function wrappers (due to GDB missing OO framework).
> (a3) So far only GNU/Linux implementation exists, implementors for other OSes
>      would generalize the infrastructure appropriately themselves.

This is something that we have discussed a lot in gdb-patches
mailing-list, due to a message from Eli Zaretskii. I still haven't
looked deeply into your patch, but thanks for this. When I have time
I'll send comments.

> Please update the branch against master, it is getting out of sync.

Will do.

Thanks,

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil