This is the mail archive of the gdb-patches@sourceware.org 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: [RFC] Support command "catch syscall" properly on different targets


Sergio Durigan Junior <sergiodj@redhat.com> writes:

> Anyway, I just raised this point because we shouldn't "return 1" when
> asked if inf-ttrace.c supports "catch syscall".

Sergio,
I'll remove inf_ttrace_supports_syscall_catchpoint from my updated
patch.  Thanks for pointing this out.

In my patch, "catch syscall" command is allowed on the target which
supports catch syscall.  On exec target, GDB will error on command
"catch syscall", so it causes regressions in catch-syscall.exp.

The proc test_catch_syscall_multi_arch in catch-syscall.exp tests
syscall number is mapped to different syscall number on different
gdbarch, but it has:

	# We are not interested in loading any binary here, and in
	# some systems (PowerPC, for example), if we load a binary
	# there is no way to set other architecture.

As you mentioned in
https://sourceware.org/bugzilla/show_bug.cgi?id=10737#c4 , when GDB
starts an inferior, the arch is set correspondingly, so it is unable
reproduce the bug.  test_catch_syscall_multi_arch is the simpler
reproducer, IMO.  How about 'upgrade' test_catch_syscall_multi_arch like
this?

 - file 32-bit program
 - run to main
 - catch syscall 5
 - kill
 - file 64-bit program
 - run to main
 - catch syscall 5

-- 
Yao (éå)


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