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

gdb and binutils branch master updated. 4924df7977f97475c93709bd3119f3b83d84bc6a


This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  4924df7977f97475c93709bd3119f3b83d84bc6a (commit)
      from  3f10b67a597334c1f7459ba696d40925fa7f4ae3 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4924df7977f97475c93709bd3119f3b83d84bc6a

commit 4924df7977f97475c93709bd3119f3b83d84bc6a
Author: Gabriel Krisman Bertazi <gabriel@krisman.be>
Date:   Thu Dec 19 17:01:49 2013 -0200

    Fix PR breakpoints/16297: catch syscall with syscall 0
    
    Code rationale
    ==============
    by: Gabriel Krisman Bertazi
    
    This is a fix for bug 16297. The problem occurs when the user attempts
    to catch any syscall 0 (such as syscall read on Linux/x86_64). GDB was
    not able to catch the syscall and was missing the breakpoint.
    
    Now, breakpoint_hit_catch_syscall returns immediately when it finds the
    correct syscall number, avoiding a following check for the end of the
    search vector, that returns a no hit if the syscall number was zero.
    
    Testcase rationale
    ==================
    by: Sergio Durigan Junior
    
    This testcase is a little difficult to write.  By doing a quick
    inspection at the Linux source, one can see that, in many targets, the
    syscall number 0 is restart_syscall, which is forbidden to be called
    from userspace.  Therefore, on many targets, there's just no way to test
    this safely.
    
    My decision was to take the simpler route and just adds the "read"
    syscall on the default test.  Its number on x86_64 is zero, which is
    "good enough" since many people here do their tests on x86_64 anyway and
    it is a popular architecture.
    
    However, there was another little gotcha.  When using "read" passing 0
    as the third parameter (i.e., asking it to read 0 bytes), current libc
    implementations could choose not to effectively call the syscall.
    Therefore, the best solution was to create a temporary pipe, write 1
    byte into it, and then read this byte from it.
    
    gdb/ChangeLog
    2013-12-19  Gabriel Krisman Bertazi  <gabriel@krisman.be>
    
    	PR breakpoints/16297
    	* breakpoint.c (breakpoint_hit_catch_syscall): Return immediately
    	when expected syscall is hit.
    
    gdb/testsuite/ChangeLog
    2013-12-19  Sergio Durigan Junior  <sergiodj@redhat.com>
    
    	PR breakpoints/16297
    	* gdb.base/catch-syscall.c (read_syscall, pipe_syscall)
    	(write_syscall): New variables.
    	(main): Create a pipe, write 1 byte in it, and read 1 byte from
    	it.
    	* gdb.base/catch-syscall.exp (all_syscalls): Include "pipe,
    	"write" and "read" syscalls.
    	(fill_all_syscalls_numbers): Improve the way to obtain syscalls
    	numbers.

-----------------------------------------------------------------------

Summary of changes:
 gdb/ChangeLog                            |    6 ++++++
 gdb/breakpoint.c                         |    7 +++----
 gdb/testsuite/ChangeLog                  |   12 ++++++++++++
 gdb/testsuite/gdb.base/catch-syscall.c   |   16 ++++++++++++++++
 gdb/testsuite/gdb.base/catch-syscall.exp |   11 ++++++-----
 5 files changed, 43 insertions(+), 9 deletions(-)


hooks/post-receive
-- 
gdb and binutils


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