This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/4] 'catch syscall' feature -- Architecture-independent part
>>>>> "SÃrgio" == SÃrgio Durigan JÃnior <sergiodj@linux.vnet.ibm.com> writes:
SÃrgio> + memset ((void *) cur_name, '\0', 128 * sizeof (char));
Tom> I don't think this is needed.
Tom> Also, sizeof(char)==1 by definition.
SÃrgio> Yeah, I know hehe. It just happens that I like to be "explicit", so
SÃrgio> you'll likely find "sizeof (char)" in every code I make :-)... But
SÃrgio> there's no problem for me to take it off.
Just to be clear, here I meant that the whole memset appears
unnecessary.
Tom> I think it would be more useful to make a single catchpoint. A single
Tom> catchpoint gives the user a way to set commands, conditions, etc, for
Tom> a whole range of syscalls at once. It is analogous, I think, to
Tom> having a breakpoint with multiple locations.
SÃrgio> I have a question right here, then. Is the "breakpoint with multiple
SÃrgio> locations" implemented this way? I'm sorry for my ignorance on this :-(
Yeah. That might not be the best example, since there is also
"rbreak", which makes lots of separate breakpoints.
SÃrgio> I was talking to Thiago about this, and I don't know if we need this
SÃrgio> *right now*, for this patch. I think it's good the way it is, and as you
SÃrgio> said, it won't take much to modify things in order to make it work the
SÃrgio> way you want :-). Also, currently the "catch syscall" command doesn't
SÃrgio> allow the user to set commands, conditions, etc. So for now it's only
SÃrgio> "catch syscall [name|number]".
SÃrgio> What do you think?
I'd still like it, for a long term UI reason. If "catch syscall"
makes separate catch points for each syscall, then when we move to
froggy we won't be able to take advantage of the kernel-side
filtering, because that would be a change to how the command works.
We would probably have to invent a new user command.
Another option would be to make "catch syscall" only take a single
argument for now. Then we could extend it gracefully in the future.
Also, can't you set conditions and commands on syscall catchpoints
using the "condition" and "commands" commands? I would have thought
that came for free -- but I didn't try it and I didn't read the code
closely enough to know for sure.
SÃrgio> Thanks for your comments :-).
Thanks for writing this and for persevering :)
Tom