This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/4] 'catch syscall' feature -- Architecture-independent part

>>>>> "SÃrgio" == SÃrgio Durigan JÃnior <> 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

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 :)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]