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]

[PATCH] Partial fix for PR breakpoints/10737: Make syscall info be per-arch instead of global


This patch series intends to partially fix PR breakpoints/10737, which
is about making the syscall information (for the "catch syscall"
command) be per-arch, instead of global.  This is not a full fix
because of the other issues pointed by Pedro here:


However, I consider it a good step towards the real fix.  It will also
help me fix <>,
so I think it is good if the patch goes in.

What this patch does, basically, is move the "syscalls_info"
struct to gdbarch.  Currently, the syscall information is stored in a
global variable inside gdb/xml-syscall.c, which means that there is no
easy way to correlate this info with the current target or
architecture being used, for example.  This causes strange behaviors,
because the syscall info is not re-read when the arch changes.  For
example, if you put a syscall catchpoint in syscall 5 on i386 (syscall
open), and then load a x86_64 program on GDB and put the same syscall
5 there (fstat on x86_64), you will still see that GDB tells you that
it is catching "open", even though it is not.  With this patch, GDB
correctly says that it will be catching fstat syscalls.

As I said, there are still some problems on the "catch syscall"
mechanism, because (for example) the user should be able to "catch
syscall open" on i386, and then expect "open" to be caught also on
x86_64.  Currently, it doesn't work.  I intend to work on this later.

Anyway, I would like to know what you think about the current patch.
I guess it is simple enough to understand, and should not pose any
difficulties to be accepted (I expect).

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