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. 706d088346930eeee11befa93330375164e175b9


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  706d088346930eeee11befa93330375164e175b9 (commit)
      from  5caa2f0b272d2a6edf56571fd0c59f922f26eb41 (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=706d088346930eeee11befa93330375164e175b9

commit 706d088346930eeee11befa93330375164e175b9
Author: Pedro Alves <palves@redhat.com>
Date:   Wed Feb 12 13:30:21 2014 +0000

    Explicitly mark vtables as code space
    
    Ports for Hardvard architectures will typically have in their
    pointer_to_address hook a check for TYPE_CODE_SPACE in their
    "pointer_to_address" gdbarch method.  E.g., rl78's:
    
      /* Is it a code address?  */
      if (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_FUNC
          || TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_METHOD
          || TYPE_CODE_SPACE (TYPE_TARGET_TYPE (type))
          || TYPE_LENGTH (type) == 4)
        return rl78_make_instruction_address (addr);
      else
        return rl78_make_data_address (addr);
    
    The avr port is similar.
    
    The vtable type is a struct type gdb itself bakes.  Being neither a
    function, nor a method, and absent explicit flagging as residing in
    code space, ends up being considered data.
    
    This patch marks the type as code when it is created, on the theory
    that this is needed for all Hardvard architectures.  I believe this
    should make no difference on archs with flat address space.  Testing
    on x86-64 GNU/Linux shows no changes.
    
    gdb/
    2014-02-12  Pedro Alves  <palves@redhat.com>
    	    Kevin Buettner <kevinb@redhat.com>
    
    	* gnu-v3-abi.c (build_gdb_vtable_type): Return a type marked with
    	TYPE_INSTANCE_FLAG_CODE_SPACE.
    
    Kevin Buettner, at
    <https://sourceware.org/ml/gdb-patches/2014-02/msg00338.html>, writes,
    re. rl78:
    
    This patch, for rl78 using the default multilib, fixes 5 failures in
    gdb.cp/casts.exp, 2 failures in gdb.cp/class2.exp, 115 failures in
    gdb.mi/mi-var-rtti.exp, and 2 failures in gdb.python/py-value.exp.
    
    It introduces 9 failures (regressions) in gdb.mi/mi-var-rtti.exp.
    
    One of the regressions is:
    
     FAIL: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
    
    The relevant lines from the log file from a pre-patch test run are as
    follows:
    
     -var-list-children  S.public
     ^done,numchild="1",children=[child={name="S.public.ptr",exp="ptr",numchild="1",type="Base *",thread-id="1"}],has_more="0"
     (gdb)
     PASS: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
     Expecting: \^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"
     Expecting: ^(-var-list-children  S\.public\.ptr  [
     ]+)?(\^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"[
     ]+[(]gdb[)]
     [ ]*)
    
    The same set of lines for the failing (post-patch) run are instead:
    
     -var-list-children  S.public
     &"warning: can't find linker symbol for virtual table for `Base' value\n"
     &"warning:   found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
     &"warning: can't find linker symbol for virtual table for `Base' value\n"
     &"warning:   found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
     &"warning: can't find linker symbol for virtual table for `Base' value\n"
     &"warning:   found `typeinfo for __cxxabiv1::__vmi_class_type_info' instead\n"
     ^done,numchild="1",children=[child={name="S.public.ptr",exp="ptr",numchild="1",type="Base *",thread-id="1"}],has_more="0"
     (gdb)
     FAIL: gdb.mi/mi-var-rtti.exp: list children of s.public in type_update_when_use_rtti
     Expecting: \^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"
     Expecting: ^(-var-list-children  S\.public\.ptr  [
     ]+)?(\^done,numchild=".*",children=\[child={name="S.public.ptr.public",exp="public",numchild="1"(,thread-id="[0-9]+")?}.*\],has_more="0"[
     ]+[(]gdb[)]
     [ ]*)
    
    Note that the difference between these are the warnings regarding
    linker symbols.  Aside from the warnings, the result is the same.
    I.e.  gdb produces the correct answer despite the warnings.  The
    reason for the other 8 failures is the same: the test harness is not
    expecting these warnings.
    
    I spent some time (a while ago) looking at the reason for these
    warnings.  As I recall, we are now getting further along in the type
    resolution process than we were without my patch.  I.e.  for the
    example above, the code in question never got to the point where it
    was looking for the specified linker symbol.  So it seems to me that,
    at worst, my patch exposes some other problem, but is not directly the
    cause of the problem.

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

Summary of changes:
 gdb/ChangeLog    |    6 ++++++
 gdb/gnu-v3-abi.c |    2 +-
 2 files changed, 7 insertions(+), 1 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]