This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: [RFC/RFA] MIPS extract_return_value


Hey Andrew, Daniel,

I encountered another problem with 32/64 bit mips.  Don't know if this
is the right way to fix it, but it illustrates it (and fixes several
hundred failures).

The problem is that extract_return_value and store_return_value both
call return_value_location, but then one of them uses the raw register
and the other uses the cooked register (which are not the same size).
So the offset into the register cache, computed by
return_value_location, has to be wrong for one of them.

The underlying problem here is that eabi (32 and 64) and o64 still use:


      set_gdbarch_deprecated_store_return_value (gdbarch,
      set_gdbarch_deprecated_extract_return_value (gdbarch,

There should instead be separate eabi and o64 return_value methods (see mips_n32n64_return_value for an example).

If this is done the return/finish code will really be fixed (and as a side effect return_value_location will be eliminated). Can that be done?

The simple-minded approach I've taken below is to add a parameter
to return_value_location, telling it whether to use the raw or cooked
registers.  I've only tested it on one architecture (isa64 with gcc
-mips32), so consider it more of a suggestion than a patch.

Just FYI, the code should just manipulate the cooked registers.


Andrew



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