This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH 0/4] 'catch syscall' feature
- From: Sérgio Durigan Júnior <sergiodj at linux dot vnet dot ibm dot com>
- To: Michael Snyder <msnyder at vmware dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Wed, 01 Oct 2008 20:03:08 -0300
- Subject: Re: [PATCH 0/4] 'catch syscall' feature
- References: <1222798405.30389.22.camel@miki> <48E3FBE1.email@example.com>
IMHO, the patch won't apply on CVS HEAD indeed. Also, I've used git to
generate it, so it might be easy for you to get the specific revision to
apply my patch.
The revision is: 337099393e64741ed0fbbb8c60ca3f6adb5d5974
You can easily checkout a copy of it by doing:
#> git clone git://sourceware.org/git/gdb.git
#> git reset --hard 337099393e64741ed0fbbb8c60ca3f6adb5d5974
Then the patch should apply without errors.
Well, to make things a little easier, that's the last ChangeLog entry
2008-09-27 Tom Tromey <firstname.lastname@example.org>
* NEWS: Update.
* macrocmd.c (extract_identifier): Add is_parameter argument.
* macroexp.c (stringify): New function.
(gather_arguments): Add nargs argument. Handle varargs.
(substitute_args): Add is_varargs and va_arg_name arguments.
Handle varargs, splicing, stringification. Use find_parameter.
(expand): Handle varargs.
Hope that it helps :-).
On Wed, 2008-10-01 at 15:38 -0700, Michael Snyder wrote:
> Hi Sergio,
> What source tree or snapshot is your diff taken from?
> I tried applying it to current cvs, and got a lot of
> failures and fuzzes.
> Sérgio Durigan Júnior wrote:
> > Hello guys,
> > As this is my first "serious" patch to GDB, I'm sure there will be a lot
> > of mistakes in it :-). Anyway, I hope this adds something useful to the
> > program.
> > The purpose of this patch is to implement a new feature in GDB called
> > "catch syscall". In this first moment, the feature should look something
> > like the 'strace' utility, but less "capable" (it still can't, for
> > example, get the syscall arguments and return code - although, the way I
> > see, this would be easy to do).
> > With this feature, you can start over you GDB and tell it to start
> > catching syscalls in the inferior. Whenever a syscall is called (or
> > returns), GDB stops and tell you the name of it. You can also ask GDB to
> > "filter" the syscalls so that you'll only see calls/returns from that
> > specific syscall.
> > For now the feature is only implemented for PPC32 and PPC64, but in a
> > future not so distant I intend to send patches for x86 and x86_64 too.
> > I've tried to organize the code the best way I could, and I've
> > extensively used the codes for "catch fork", "catch exec" and "catch
> > unload" as an example. I'd be glad if you could give some opinions about
> > the way I did it :-).
> > I've also splitted the patch into 4 logical "sequences", that are
> > organized in this way:
> > - First part implements the architecture-independent part of the
> > feature.
> > - Second part implements the architecture-dependent (PPC32 and PPC64)
> > part of the feature.
> > - Third part refers to the documentation.
> > - Fourth part brings the testcase.
> > Unfortunately, if one applies the patch and compiles GDB for PPC64, it
> > doesn't work properly. This is due to a bug which we have found that
> > makes the inferior segfault when there is a breakpoint inserted at its
> > entrypoint (AT_ENTRY). Luis Machado is taking a closer look into this
> > issue, so I think he'll have a solution soon :-).
> > Special thanks goes to Thiago Bauermann, Luis Machado and Carlos Seo,
> > who helped me a lot with my never-ending questions about GDB.
> > Regards,
> > --
> > Sérgio Durigan Júnior
> > Linux on Power Toolchain - Software Engineer
> > Linux Technology Center - LTC
> > IBM Brazil
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC