Patch for PR 9399

Chris Moller
Wed Dec 9 15:10:00 GMT 2009

On 12/09/09 09:05, Daniel Jacobowitz wrote:
> On Wed, Dec 09, 2009 at 08:32:34AM -0500, Chris Moller wrote:
>> The patch file includes the patch to gdb/valops.c, gdb/ChangeLog,
>> gdb/testsuite/ChangeLog, gdb/testsuite/gdb.cp/, and
>> mc-log.diffs.  (The patch to is to incorporate the
>> testcase for 'make check'; mc-log.diffs are the diffs between before
>> and after runs of 'make check')
> Next time, please diff -u gdb.sum files; the rest is just noise.

Okay--if I ever do this again. :-)

> Those do vary a little bit but they're more stable.  It looks like
> your only change is mi-nsmoribund.exp, which is sometimes flaky.
>> I can't do a 'cvs add' so the the
>> testcase expects and .cc file are attached separately as
>> gdb/testsuite/gdb.cp/ and
>> gdb/testsuite/gdb.cp/virtfunc2.exp.
> Take a look at cvsutils; "cvsdo add" works.
> (Or, nowadays, I suppose you could use the git mirror! :-)

Didn't know you had a git mirror--I just pulled the CVS version because 
it was pointed to on

>> You can see what the patch does by compiling -g, gdb-ing
>> it, breaking in the return stmt at // marker1, and doing things like
>> "print o.do_print()".  Without the patch, gdb tries to access
>> location 0x0; with the patch it does the right thing.  (There are
>> more tests in virtfunc2.exp)
> Where does the access to 0x0 come from?  Is it inside
> search_struct_field?

Ultimately, yes.  Without the patch, the thread ultimately gets to

      if (BASETYPE_VIA_VIRTUAL (type, i))

in search_struct_field and then to the memcpy about 30 lines later that 
extracts a new value struct.  That main_type of that value doesn't 
include a field for the virtual function, so it's never found, and 
ultimately returns a null pointer.  I haven't a clue why it works that 
way--for a while I was working on the assumption that the DWARF reader 
was screwing up, but if it is, it's too subtle for me.

>   I wouldn't expect value_cast_structs to do any
> cast in this case,

value_cast_structs only does nothing if both TYPE_NAME()s are null.  I 
was wondering if, back when the code was originally written, if there 
never was a case when both TYPE_NAME()s were non-null--it's the only 
way, other than simple oversight, I can account for that case not being 

> but it does do a little extra work.
>> +   if ((TYPE_NAME (t1) != NULL)&&
>> +       (TYPE_NAME (t2) != NULL)&&
>> +       !strcmp (TYPE_NAME (t1), TYPE_NAME (t2)))
> &&  on the beginning of the line, please.

More information about the Gdb-patches mailing list