Closed Quuxplusone closed 8 years ago
Bugzilla Link | PR22248 |
Status | RESOLVED FIXED |
Importance | P normal |
Reported by | Gianfranco (costamagnagianfranco@yahoo.it) |
Reported on | 2015-01-16 04:22:52 -0800 |
Last modified on | 2016-05-05 08:03:43 -0700 |
Version | trunk |
Hardware | All Linux |
CC | hfinkel@anl.gov, koriakin@0x04.net, llvm-bugs@lists.llvm.org, mattias.ellert@fysast.uu.se, mliska@suse.cz, rafael@espindo.la, sylvestre@debian.org, uweigand@de.ibm.com, wschmidt@linux.vnet.ibm.com |
Fixed by commit(s) | |
Attachments | |
Blocks | |
Blocked by | |
See also |
glibc version should be 2.19-12 or 2.19-13 (debian revision)
Do you have an example of a file (.ii) where clang introduces a reference to __stack_chk_guard but gcc does not?
Hi, unfortunately not.
There are two ways to build hedgewars.
with fpc and haskell
with clang compiling generated c files from pascal sources via "pas2c" tool.
We need clang because of this:
"‘overloadable’ attribute directive ignored [-Wattributes]
void __attribute__((overloadable)) fpcrtl_readLn(File f) {
"
basically seems that gcc doesn't reconize the overloadable functions.
http://stackoverflow.com/questions/9864513/gcc-allow-overloaded-functions-in-c99
Use of __stack_chk_guard depends on the platform ABI. Some Linux architectures
do *not* provide this as a variable in glibc, but instead store the stack guard
value in a well-known location in the TLS area.
LLVM currently implements this for x86, but falls back to __stack_chk_guard on
all other platforms. This is certainly wrong at least on PowerPC and SystemZ,
both of which also use a TLS area stack guard.
This is implemented in lib/CodeGen/StackProtector.cpp, CreatePrologue:
unsigned AddressSpace, Offset;
if (TLI->getStackCookieLocation(AddressSpace, Offset)) {
Constant *OffsetVal =
ConstantInt::get(Type::getInt32Ty(RI->getContext()), Offset);
StackGuardVar =
ConstantExpr::getIntToPtr(OffsetVal, PointerType::get(PtrTy,
AddressSpace));
} else if (TT.isOSOpenBSD()) {
StackGuardVar = M->getOrInsertGlobal("__guard_local", PtrTy);
cast<GlobalValue>(StackGuardVar)
->setVisibility(GlobalValue::HiddenVisibility);
} else {
SupportsSelectionDAGSP = true;
StackGuardVar = M->getOrInsertGlobal("__stack_chk_guard", PtrTy);
}
Unfortunately, it does not seem possible to simply implement TLI-
>getStackCookieLocation for those other platforms, as common code here enforces
the notion that the TLS area is accessed via a non-default address space.
That's true on x86, but not anywhere else AFAIK. The TLI interface probably
needs updating to allow other platforms to access the TLS area in the way
that's appropriate for them ...
I'm going to fix this for kfreebsd, sparc, ppc*, and s390x. However, the
problem shouldn't apply for mips - IMO you're seeing a different bug here (not
related to __stack_chk_guard).
The issue should be now fixed on kfreebsd, sparc, sparc64, powerpc, powerpc64, powerpc64le, s390x. Can you try the build with current llvm trunk?
Hi, thanks! I'll wait for Debian to import the new llvm snapshot and report
back in case of troubles!
(no news: good news)
cheers,
G.