Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Windows] Segmentation fault when returning a struct from a function or instance method #14048

Closed
timurrrr opened this issue Aug 23, 2012 · 12 comments
Assignees
Labels
bugzilla Issues migrated from bugzilla c++

Comments

@timurrrr
Copy link
Contributor

Bugzilla Link 13676
Resolution FIXED
Resolved on Apr 17, 2013 09:56
Version unspecified
OS Windows NT
Depends On llvm/llvm-bugzilla-archive#15556
Blocks #12849
CC @chandlerc,@DougGregor,@efriedma-quic

Extended Description

As of r160851,

$ cat with_cl.cpp
struct S {
int a, b;
};

class C {
public:
S foo();
};

S C::foo() {
S ret;
ret.a = 1;
ret.b = 2;
return ret;
}
///////////////////// EOF
$ cat with_clang.cpp
struct S {
int a, b;
};

class C {
public:
S foo();
};

int main() {
C c;
S s = c.foo();
if (s.a != 1)
return 1;
if (s.b != 2)
return 2;
}
///////////////////// EOF
$ clang -Xclang -cxx-abi -Xclang microsoft -c with_clang.cpp && cl -nologo -c with_cl.cpp && link -nologo with_cl.obj with_clang.o

$ with_cl.exe
Segmentation fault

@timurrrr
Copy link
Contributor Author

assigned to @timurrrr

@efriedma-quic
Copy link
Collaborator

Could you attach the assembly generated by MSVC?

@chandlerc
Copy link
Member

Could you attach the assembly generated by MSVC?

Please don't attach output generated by the MSVC compiler to the public bug tracker unless you understand all of the implications of its EULA.

I don't think we need it for Timur to continue working on this.

@timurrrr
Copy link
Contributor Author

I don't think we need it for Timur to continue working on this.
FTR,
I'm not working on this at the moment.
This was found in SPEC 2006 tests on the povray benchmark.

Currently I'm prioritized to get Clang working on Chromium and I don't think the pattern described in this bug is widespread there due to our strict code style. I might be wrong though as we have a lot of third_party/ there.

So feel free to take over unless I explicitly take it myself :)

@chandlerc
Copy link
Member

I don't think we need it for Timur to continue working on this.
FTR,
I'm not working on this at the moment.
This was found in SPEC 2006 tests on the povray benchmark.

Currently I'm prioritized to get Clang working on Chromium and I don't think
the pattern described in this bug is widespread there due to our strict code
style.

I'll wager you one beverage of your choice that you end up having to fix this for Chromium. ;]

Anyways, prioritize as is convenient for you, I just was pointing out that whomever chooses to dig into this can likely do so w/o someone posting asm.

@timurrrr
Copy link
Contributor Author

I'll wager you one beverage of your choice that you end up having to fix
this for Chromium. ;]
I was wise enough not to make a bet with you ;)

Indeed, Chromium's FilePath::DirName returns a FilePath by value, it's a 32-byte structure => boom it crashes.

--
Some more info.

Actually it turns out the problem is not that the struct is "2 integers".
At least I observe the same crash regardless of the "S" size (tested 4,8,12,32).

A similar "returning a struct" scenario works fine for non-class functions or static class method.
The crash also happens if I explicitly mark the method as __cdecl so it's likely not unique to thiscall (default method CC).

Changing the subject accordingly.

@timurrrr
Copy link
Contributor Author

timurrrr commented Oct 2, 2012

Taking this.

After some investigation, there are at least three different problems here:

  1. LLVM: "sret" is currently mishandled on Windows.
    The current version of lib/Target/X86/X86CallingConv.td puts SRet into EAX though it should push the address on stack

  2. Clang problem #​1:
    Returning a struct with non-trivial default constructor should imply "sret";
    Currently, only the presence of a copy constructor or destructor implies sret.

  3. Clang problem #​2: Handling of __cdecl instance methods - to be investigated later.

I have small patches for (1) and (2), but their current versions likely break the Itanium ABI.
I'll send a couple of e-mails to llvm-dev and cfe-dev for design suggestions soon;
as well as adding a test for (2).

@timurrrr
Copy link
Contributor Author

A fix for everything I know except for __cdecl methods has been committed as r179681.
I'll file an issue for __cdecl soon.

@timurrrr
Copy link
Contributor Author

(See also r178291, r178634)

@timurrrr
Copy link
Contributor Author

Re: cdecl - see llvm/llvm-bugzilla-archive#15768

@timurrrr
Copy link
Contributor Author

mentioned in issue llvm/llvm-bugzilla-archive#15556

@timurrrr
Copy link
Contributor Author

mentioned in issue llvm/llvm-bugzilla-archive#16226

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from bugzilla c++
Projects
None yet
Development

No branches or pull requests

3 participants