gdb and binutils branch master updated. 43968415b0025fa8e1fa5c813e53e87ae392e977

[brobecke at sourceware dot org]

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  43968415b0025fa8e1fa5c813e53e87ae392e977 (commit)
      from  abdef8eb901ce829fdc9fbe7eb89c8327c262f07 (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=43968415b0025fa8e1fa5c813e53e87ae392e977

commit 43968415b0025fa8e1fa5c813e53e87ae392e977
Author: Joel Brobecker <brobecker@adacore.com>
Date:   Fri Sep 19 18:00:07 2014 -0400

    [gdbserver/lynx] spurious failure to write in inferior memory
    
    We noticed the following error on ppc-lynx178, using just about
    any program:
    
            (gdb) tar remote mytarget:4444
            Remote debugging using mytarget:4444
            0x000100c8 in _start ()
            (gdb) b try
            Breakpoint 1 at 0x10844: file try.adb, line 11.
            (gdb) cont
            Continuing.
     !!!->  Cannot remove breakpoints because program is no longer writable.
     !!!->  Further execution is probably impossible.
    
            Breakpoint 1, try () at try.adb:11
            11          Local : Integer := 18;
    
    And, of course, trying to continue yielded the expected outcome:
    
           (gdb) c
           Continuing.
           warning: Error removing breakpoint 1
           Cannot remove breakpoints because program is no longer writable.
           Further execution is probably impossible.
    
    It turns out that the problem is caused by an intentional test
    against a variable with an undefined value. After GDB receives
    notification of the inferior stopping, it tries to remove the
    breakpoint by sending a memory-write packet ("X10844,4:9 ").
    This leads us to lynx_write_memory, where it tries to split
    the memory-write into chunks of 4 bytes. And, in order to handle
    writes which are not aligned on word boundaries, we have the
    following code:
    
          if (skip > 0 || truncate > 0)
            /* We need to read the memory at this address in order to preserve
               the data that we are not overwriting.  */
            lynx_read_memory (addr, (unsigned char *) &buf, xfer_size);
            if (errno)
              return errno;
    
    (the comment explains what the code is about).
    
    Unfortunately, the not-so-glaring error that we've made here is
    that we're checking ERRNO regardless of whether we've called
    lynx_read_memory. In our case, because we are writing 4 bytes
    aligned on a word boundary, we do not call lynx_read_memory and
    therefore test an ERRNO with an undefined value.
    
    gdb/gdbserver/ChangeLog:
    
            * lynx-low.c (lynx_write_memory): Put lynx_read_memory and
            corresponding ERRNO check in same block.

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

Summary of changes:
 gdb/gdbserver/ChangeLog  |    5 +++++
 gdb/gdbserver/lynx-low.c |   12 +++++++-----
 2 files changed, 12 insertions(+), 5 deletions(-)


hooks/post-receive
-- 
gdb and binutils