This is the mail archive of the gdb-prs@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]

[Bug gdb/10737] catch syscall name mappings (xml) should be per-arch or per-target, not global


https://sourceware.org/bugzilla/show_bug.cgi?id=10737

--- Comment #4 from Sergio Durigan Junior <sergiodj at redhat dot com> ---
BTW, the test needs to be different than what Pedro suggested.

When you start GDB with an inferior, it sets the architecture correspondingly. 
Then, when you call "catch syscall", GDB loads the syscall names from the XML
file related to the current architecture.  Therefore, in this scenario, you
*will* see the correct syscall, even if the inferior is not of the same
architecture as your host.

What this means is that triggering the bug is a bit simpler, and you don't even
need an inferior for that (I discovered this while writing the testcase for the
patch).  For example, on i386 the "open" syscall is 5, but on x86_64 the
"fstat" is 5.  Therefore, to see the bug you can only do:

(gdb) set architecture i386
The target architecture is assumed to be i386
(gdb) catch syscall 5
Catchpoint 1 (syscall 'open' [5])
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) catch syscall 5
Catchpoint 2 (syscall 'open' [5])

With my patch:

(gdb) set architecture i386
The target architecture is assumed to be i386
(gdb) catch syscall 5
Catchpoint 1 (syscall 'open' [5])
(gdb) set architecture i386:x86-64
The target architecture is assumed to be i386:x86-64
(gdb) catch syscall 5
Catchpoint 2 (syscall 'fstat' [5])

This is also the approach I will use to test the patch.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


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