[LLVMdev] operator overloading fails while debugging with gdb for i386

[Mayur Pandey]

Hi,

I was going through this issue along with the standards. What the standard
states is(reference: http://www.sco.com/developers/devspecs/abi386-4.pdf):

If a function returns a structure or union, then the caller provides space
for the
return value and places its address on the stack as argument word zero. In
effect,
this address becomes a ‘‘hidden’’ first argument. Having the caller supply
the
return object’s space allows re-entrancy.

A function that returns a structure or union also sets% e a x to the value
of the original
address of the caller’s area before it returns. Thus when the caller
receives
control again, the address of the returned object resides in register% e a
x and can
be used to access the object. Both the calling and the called functions must
cooperate to pass the return value successfully.

Also i verified that through the assembly code, that when the caller calls
the callee function, the hidden pointer is stored in eax(other arguments
being passed in ecx and edx). But the callee function modifies eax and in
the end it does not store the hidden pointer in eax, but it is stored in
edx.

So this seems to be the cause of the problem.

*@Renato Golin*:- Does the code execute correctly? Does a printf on the sum
outputs the
correct value? : yes the code executes correctly and some gives the correct
value. Its only in gdb that we face this problem as gdb expects the hidden
pointer in eax.

Note: GDB  "struct return convention" : The caller passes an additional
hidden first parameter to the caller.  That parameter contains the address
at which the value being returned should be stored.


On Mon, Dec 3, 2012 at 2:37 PM, Renato Golin <rengolin at systemcall.org>wrote:

> On 2 December 2012 08:12, Mayur Pandey <mayurthebond at gmail.com> wrote:
> > So is this just a coincidence for g++ that eax points to this address and
> > gdb prints the right value on the command print sum(one,two)??
>
> The code is small, and the structure is probably set at the end of the
> block, so I think it's not that much of a coincidence.
>
> Regardless of the specific value on that specific compilation unit,
> you should never rely on behaviour of clobbered registers. That
> function returns void, you should look up in the caller, where is the
> address of the structure.
>
> Does the code execute correctly? Does a printf on the sum outputs the
> correct value? StrucRet is stable on Intel for years, I'd be surprised
> id that didn't work.
>
> However, it's possible that clang is messing up the position of the
> structure in Dwarf, so I'd investigate the Dwarf emission first, since
> your problem seems to bee with clang+gdb.
>
>
>
> --
> cheers,
> --renato
>
> http://systemcall.org/
>



-- 
Thanx & Regards
*Mayur Pandey *
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121203/a5a77dcc/attachment.html>