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


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  d9a472877066d56b0546af71890bc92eef85df67 (commit)
       via  e5e01dbf8911d62631e5f53c083477442e2f1119 (commit)
      from  0a770bb257845d8c701e67b16395b9c1b922f607 (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=d9a472877066d56b0546af71890bc92eef85df67

commit d9a472877066d56b0546af71890bc92eef85df67
Author: Yao Qi <yao@codesourcery.com>
Date:   Fri Jun 6 19:16:47 2014 +0800

    Restrict the pattern in gdb.base/jit.exp
    
    I see the following fail in some thumb multi-lib in arm-none-linux-gnueabi,
    
    info function jit_function^M
    All functions matching regular expression "jit_function":^M
    ^M
    Non-debugging symbols:^M
    0x00000790  __real_jit_function_XXXX^M
    0x0000079c  __jit_function_XXXX_from_arm^M
    0x0000079c  jit_function_0000^M
    0x00000790  __real_jit_function_XXXX^M
    0x0000079c  __jit_function_XXXX_from_arm^M
    0x0000079c  jit_function_0001^M
    (gdb) FAIL: gdb.base/jit.exp: one_jit_test-2: info function jit_function
    
    the test expects to see only jit_function_0000 and jit_function_0001
    
    one_jit_test 2 "${hex}  jit_function_0000\[\r\n\]+${hex}  jit_function_0001"
    
    Symbols with the prefix "__real_" or suffix "_from_arm" is generated
    by gcc/ld for arm/thumb interworking.
    
    This patch is to restrict the pattern from "jit_function" to
    "^jit_function", the output becomes expected.
    
    gdb/testsuite:
    
    2014-06-06  Yao Qi  <yao@codesourcery.com>
    
    	* gdb.base/jit.exp (one_jit_test): Restrict the pattern
    	from "jit_function" to "^jit_function".

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

commit e5e01dbf8911d62631e5f53c083477442e2f1119
Author: Yao Qi <yao@codesourcery.com>
Date:   Fri Jun 6 14:32:42 2014 +0800

    Tweak gdb.base/async.exp
    
    I see two fails in async.exp on arm-none-eabi target:
    
    nexti&^M
    (gdb) 0x000001ba        14       x = 5; x = 5;^M
    completed.^M
    FAIL: gdb.base/async.exp: nexti&
    finish&^M
    Run till exit from #0  0x000001ba in foo () at /scratch/yqi/arm-none-eabi-lite/src/gdb-trunk/gdb/testsuite/gdb.base/async.c:14^M
    (gdb) 0x000001e6 in main () at /scratch/yqi/arm-none-eabi-lite/src/gdb-trunk/gdb/testsuite/gdb.base/async.c:32^M
    32       y = foo ();^M
    Value returned is $1 = 8^M
    completed.^M
    FAIL: gdb.base/async.exp: finish&
    
    The corresponding test is "test_background "nexti&" "" ".*y = 3.*"",
    and it assumes that GDB "nexti" into the next source line.  It is wrong
    on arm.  After "nexti", it still stops at the same source line, and it
    fails.
    
    When gdb does "finish", if the PC is in the middle of a source line,
    the PC address is printed too.  See stack.c:print_frame,
    
      if (opts.addressprint)
        if (!sal.symtab
    	|| frame_show_address (frame, sal)
    	|| print_what == LOC_AND_ADDRESS)
          {
    	annotate_frame_address ();
    	if (pc_p)
    	  ui_out_field_core_addr (uiout, "addr", gdbarch, pc);
    	else
    	  ui_out_field_string (uiout, "addr", "<unavailable>");
    	annotate_frame_address_end ();
    	ui_out_text (uiout, " in ");
          }
    
    frame_show_address checks whether PC is the middle of a source line.
    Since after "nexti", the inferior stops at the middle of a source line,
    when we do "finish" the PC address is displayed.
    
    In sum, GDB works well, but test case needs update.  This patch is to
    add a statement at the same line to make sure "nexti" doesn't go to
    the new line, match the next instruction address in the output and
    match the hex address the output of "finish".
    
    gdb/testsuite:
    
    2014-06-06  Yao Qi  <yao@codesourcery.com>
    
    	* gdb.base/async.c (foo): Add one statement.
    	* gdb.base/async.exp: Get the next instruction address and
    	match the output of "nexti" by instruction address.  Match
    	the hex address in the output of "finish".

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

Summary of changes:
 gdb/testsuite/ChangeLog          |   12 ++++++++++++
 gdb/testsuite/gdb.base/async.c   |    2 +-
 gdb/testsuite/gdb.base/async.exp |   16 ++++++++++++++--
 gdb/testsuite/gdb.base/jit.exp   |    2 +-
 4 files changed, 28 insertions(+), 4 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]