llvm dev - Dec 2012 - [LLVMdev] operator overloading fails while debugging with gdb for i386

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/

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>

On 3 December 2012 10:42, Mayur Pandey <mayurthebond at gmail.com>
wrote:
> So this seems to be the cause of the problem.
I guess you're mixing two different problems. First, is the possible
lack of conformance with the ABI you state, which I can't comment
since I don't know that ABI very well. Second, is the fact that clang
is not printing correct debug information (or is not interoperating
well enough with gdb).

Fixing the first issue will not necessarily fix the second.

> @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.
As I expected. Following the ABI is not a requirement to have working
code, or a debuggable code. GDB is probably expecting programs to
follow the ABI if they do not have decent Dwarf, which seems clang is
failing on both.

Debuggers have to deal with all sorts of user (and compiler) code, and
to give users the "debug illusion", they make too many guesses.
However, if the Dwarf information is correct to begin with, I
seriously hope that GDB would rely on that, rather than "expect"
values to be on specific registers.

Have a look in the Dwarf symbols clang generates with your code and
make sure that clang is not printing the correct location information
for that variable on the ranges where it lives on registers and which
registers.

If clang's info is right, there's only the ABI bug and GDB is being
silly. If the info is wrong, then we may need to fix *both* bugs (ABI
+ Dwarf), not just the ABI one.


--
cheers,
--renato

http://systemcall.org/