This is the mail archive of the gdb-patches@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] |
The bug with examples where it manifests is detailed on the bug page. To summarize here: When expressions involving calls to virtual methods are evaluated under EVAL_AVOID_SIDE_EFFECTS, the intermediate objects could be zeroed values. In which case, when find_overload_match tries to (indirectly) lookup the method for the most derived type of the object via its vptr, GDB trips with "Cannot access memory at address 0x0." This patch adds an additional argument NOSIDE to find_overload_match which serves as a flag to indicate whether method resolution should be performed by looking up the most derived object via the vptr. When NOSIDE is EVAL_AVOID_SIDE_EFFECTS, the method for the compile time type (instead of the most derived type) of the object is returned by find_overload_match. This will not affect the functionality as all that is important when evaluating under EVAL_AVOID_SIDE_EFFECTS is the return type of the method. Regression tested testsuite/gdb.cp. But, am I simplifying the problem somewhere? ChangeLog 2014-07-09 Siva Chandra Reddy <sivachandra@google.com> gdb/ * eval.c: Update all calls to find_overload_match. * valarith.c: Update calls to find_overload_match. (value_user_defined_cpp_op, value_user_defined_op): New argument NOSIDE. Update all callers. * valops.c (find_overload_match): New argument NOSIDE. * value.h (find_overload_match): Update signature. gdb/testsuite * gdb.cp/pr17132.cc: New file. * gdb.cp/pr17132.exp: New file.
Attachment:
fix_pr17132_v1.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |