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. aef929023e3f9c68126564a96431935d35ce032e


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  aef929023e3f9c68126564a96431935d35ce032e (commit)
       via  5fff78c4e0d938bb4fc1375792ffae02a134943c (commit)
       via  1d1f1ccb331f1fe9825c3bb6f6231a3aeb560d6f (commit)
      from  31f0c4c1c653b59ce8552402ecc1b3249273f2de (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=aef929023e3f9c68126564a96431935d35ce032e

commit aef929023e3f9c68126564a96431935d35ce032e
Author: Markus Metzger <markus.t.metzger@intel.com>
Date:   Tue May 20 15:53:44 2014 +0200

    btrace: pretend we're not replaying when generating a core file
    
    When generating a core file using the "generate-core-file" command while
    replaying with the btrace record target, we won't be able to access all
    registers and all memory.  This leads to the following assertion:
    
        gdb/regcache.c:1034: internal-error: regcache_raw_supply: Assertion `regnum >= 0 && regnum < regcache->descr->nr_raw_registers' failed.
        A problem internal to GDB has been detected,
        further debugging may prove unreliable.
        Quit this debugging session? (y or n) FAIL: gdb.btrace/gcore.exp: generate-core-file core (GDB internal error)
        Resyncing due to internal error.
    
    Pretend that we are not replaying while generating a core file.  This will
    forward fetch and store registers as well as xfer memory calls to the target
    beneath.
    
    gdb/
    	* record-btrace.c (record_btrace_generating_corefile)
    	(record_btrace_prepare_to_generate_core)
    	(record_btrace_done_generating_core): New.
    	(record_btrace_xfer_partial, record_btrace_fetch_registers)
    	(record_btrace_store_registers, record_btrace_prepare_to_store):
    	Forward request when generating a core file.
    	(record_btrace_open): Set record_btrace_generating_corefile to zero.
    	(init_record_btrace_ops): Set to_prepare_to_generate_core and
    	to_done_generating_core.
    
    testsuite/
    	* gdb.btrace/gcore.exp: New.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5fff78c4e0d938bb4fc1375792ffae02a134943c

commit 5fff78c4e0d938bb4fc1375792ffae02a134943c
Author: Markus Metzger <markus.t.metzger@intel.com>
Date:   Tue May 20 15:22:53 2014 +0200

    gcore, target: allow target to prepare/cleanup for/after core file generation
    
    Add new target functions to_prepare_to_generate_core and
    to_done_generating_core that are called before and after generating a core
    file, respectively.
    
    This allows targets to prepare for core file generation and to clean up
    afterwards.
    
    gdb/
    	* target.h (target_ops) <to_prepare_to_generate_core>
    	<to_done_generating_core>: New.
    	(target_prepare_to_generate_core, target_done_generating_core): New.
    	* target.c (target_prepare_to_generate_core)
    	(target_done_generating_core): New.
    	* target-delegates.c: Regenerate.
    	* gcore.c: (write_gcore_file): Rename to ...
    	(write_gcore_file_1): ...this.
    	(write_gcore_file): Call target_prepare_to_generate_core
    	and target_done_generating_core.

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1d1f1ccb331f1fe9825c3bb6f6231a3aeb560d6f

commit 1d1f1ccb331f1fe9825c3bb6f6231a3aeb560d6f
Author: Markus Metzger <markus.t.metzger@intel.com>
Date:   Thu May 22 08:47:42 2014 +0200

    make_corefile_notes: have caller free returned memory
    
    The various make_corefile_notes implementations for gdbarch as well as target
    currently make an xfree cleanup on the data they return.  This causes problems
    when trying to put a TRY_CATCH around the make_corefile_notes call.
    Specifically, we get a stale cleanup error in restore_my_cleanups.
    
    Omit the make_cleanup and have the caller free the memory.
    
    gdb/
    	* fbsd-nat.c (fbsd_make_corefile_notes): Remove make_cleanup call.
    	* gcore.c (write_gcore_file): Free memory returned from
    	make_corefile_notes.
    	* linux-tdep.c (linux_make_corefile_notes): Remove make_cleanup call.
    	* procfs.c (procfs_make_note_section): Remove make_cleanup call.

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

Summary of changes:
 gdb/ChangeLog                                      |   33 ++++++++++++++++++++
 gdb/fbsd-nat.c                                     |    1 -
 gdb/gcore.c                                        |   32 ++++++++++++++++---
 gdb/linux-tdep.c                                   |    1 -
 gdb/procfs.c                                       |    1 -
 gdb/record-btrace.c                                |   29 +++++++++++++++--
 gdb/target-delegates.c                             |   30 ++++++++++++++++++
 gdb/target.c                                       |   16 +++++++++
 gdb/target.h                                       |   14 ++++++++
 gdb/testsuite/ChangeLog                            |    4 ++
 gdb/testsuite/gdb.btrace/{nohist.exp => gcore.exp} |   19 ++++-------
 11 files changed, 157 insertions(+), 23 deletions(-)
 copy gdb/testsuite/gdb.btrace/{nohist.exp => gcore.exp} (73%)


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]