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

[Bug exp/18285] New: ptype expr-with-xmethod -> SEGV


https://sourceware.org/bugzilla/show_bug.cgi?id=18285

            Bug ID: 18285
           Summary: ptype expr-with-xmethod -> SEGV
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: exp
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com

gdb unique-ptr
(gdb) start
(gdb) pt *foo # foo is a std::unique_ptr<> object
-> segv

The problem, I think, is in value_x_unop:

      if (noside == EVAL_AVOID_SIDE_EFFECTS)
        {
          struct type *return_type;

          return_type
            = TYPE_TARGET_TYPE (check_typedef (value_type (argvec[0])));
=>        return value_zero (return_type, VALUE_LVAL (arg1));
        }
      if (TYPE_CODE (value_type (argvec[0])) == TYPE_CODE_XMETHOD)
        {
          /* Static xmethods are not supported yet.  */
          gdb_assert (static_memfuncp == 0);
          return call_xmethod (argvec[0], 1, argvec + 1);
        }
      else
        return call_function_by_hand (argvec[0], nargs, argvec + 1);

(top-gdb) p argvec[0]->type->main_type->code
$6 = TYPE_CODE_XMETHOD
xmethods don't have TYPE_TARGET_TYPE, it's NULL.

The user would want the result of the ptype command to be the type of the
result of the xmethod, not the type of the xmethod.
Check for xmethods before EVAL_AVOID_SIDE_EFFECTS?
OTOH, the xmethod may well have side effects.
Propagate EVAL_AVOID_SIDE_EFFECTS into the xmethod?

-- 
You are receiving this mail because:
You are on the CC list for the bug.


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