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

[RFC] Struct return values


Recently Andrew did some work on structure return values.  The result
was that GDB now refuses to make a function return, that returns a
struct accoriding to the "struct value" convention.  The reasoning
behind this is that in general, we can't determine the address of the
bit of memory where we're supposed to return the value if we're in the
middle of such a function.  However, it turns out that with 32-bit
SPARC, we can find out.  The SPARC stack frames have a reserved slot
for this address.  Should we allow returning in this case?

Furthermore, the testsuite contains the following comment:

                # The struct return case.  Since any modification
                # would be by reference, and that can't happen, the
                # value should be unmodified and hence Z is expected.
                # Is this a reasonable assumption?

I think the answer to the question is "no".  It's perfectly allowed
for the caller to provide a bit of scratch memory for the return
value, and copy the contents of this bit of memory to the variable
after the callee returns.  Now if we return from a random point in the
callee, the contents of the scratch memory will be undetermined, and
some random bytes will be copied into the variable.  This happens for
code generated by the Sun compiler.  A way to fix this, is to make
sure that GDB stops immediately after we return from the callee.  Is
there an easy way to achieve this?  Otherwise, I think we should
refrain from checking the value in this case.

Comments?

Mark


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