clang link fails with undefined reference to `__stack_chk_guard'

[llvmbot]

Bugzilla Link	22248
Resolution	FIXED
Resolved on	May 05, 2016 08:03
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@hfinkel,@marxin,@sylvestre,@uweigand

Extended Description

Hi people, building a software with hardening flags enabled seems to result on build failures, at least for hedgewars and kfreebsd- ppc64el mips and s390x

https://buildd.debian.org/status/fetch.php?pkg=hedgewars&arch=kfreebsd-amd64&ver=0.9.21.1-4&stamp=1420651885

https://buildd.debian.org/status/package.php?p=hedgewars&suite=unstable

clang version is 3.5, and the snip of the build log is here:

[ 58%] Building C object project_files/hwc/CMakeFiles/hwengine.dir/uGearsUtils.c.o cd /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/project_files/hwc && /usr/bin/clang -DPAS2C -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden -Wall -pipe -O3 -DNDEBUG -O2 -I/«PKGBUILDDIR»/project_files/hwc/rtl -I/«PKGBUILDDIR»/misc/libphyslayer -I/usr/include/lua5.1 -I/usr/include/SDL -Werror=incompatible-pointer-types -o CMakeFiles/hwengine.dir/uGearsUtils.c.o -c /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/project_files/hwc/uGearsUtils.c /usr/bin/cmake -E cmake_progress_report /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/CMakeFiles [ 58%] Building C object project_files/hwc/CMakeFiles/hwengine.dir/hwengine.c.o cd /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/project_files/hwc && /usr/bin/clang -DPAS2C -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden -Wall -pipe -O3 -DNDEBUG -O2 -I/«PKGBUILDDIR»/project_files/hwc/rtl -I/«PKGBUILDDIR»/misc/libphyslayer -I/usr/include/lua5.1 -I/usr/include/SDL -Werror=incompatible-pointer-types -o CMakeFiles/hwengine.dir/hwengine.c.o -c /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/project_files/hwc/hwengine.c Linking C executable ../../bin/hwengine cd /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/project_files/hwc && /usr/bin/cmake -E cmake_link_script CMakeFiles/hwengine.dir/link.txt --verbose=1 /usr/bin/clang -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -fPIC -fvisibility=hidden -Wall -pipe -O3 -DNDEBUG -O2 -Wl,-znoexecstack -Wl,-zorigin -Wl,-zrelro -Wl,-znow -Wl,--as-needed -Wl,-z,relro CMakeFiles/hwengine.dir/uAmmos.c.o CMakeFiles/hwengine.dir/uGearsRender.c.o CMakeFiles/hwengine.dir/uLandPainted.c.o CMakeFiles/hwengine.dir/SDLh.c.o CMakeFiles/hwengine.dir/uSinTable.c.o CMakeFiles/hwengine.dir/uInputHandler.c.o CMakeFiles/hwengine.dir/uAILandMarks.c.o CMakeFiles/hwengine.dir/uLand.c.o CMakeFiles/hwengine.dir/uLandTexture.c.o CMakeFiles/hwengine.dir/uAIAmmoTests.c.o CMakeFiles/hwengine.dir/uWorld.c.o CMakeFiles/hwengine.dir/uSound.c.o CMakeFiles/hwengine.dir/uCommandHandlers.c.o CMakeFiles/hwengine.dir/uLandObjects.c.o CMakeFiles/hwengine.dir/uCaptions.c.o CMakeFiles/hwengine.dir/uTeams.c.o CMakeFiles/hwengine.dir/uMisc.c.o CMakeFiles/hwengine.dir/uLandGenMaze.c.o CMakeFiles/hwengine.dir/uLandOutline.c.o CMakeFiles/hwengine.dir/uGears.c.o CMakeFiles/hwengine.dir/adler32.c.o CMakeFiles/hwengine.dir/uVisualGears.c.o CMakeFiles/hwengine.dir/uAIActions.c.o CMakeFiles/hwengine.dir/uDebug.c.o CMakeFiles/hwengine.dir/uLandTemplates.c.o CMakeFiles/hwengine.dir/uRender.c.o CMakeFiles/hwengine.dir/uLandGenTemplateBased.c.o CMakeFiles/hwengine.dir/uConsole.c.o CMakeFiles/hwengine.dir/uRandom.c.o CMakeFiles/hwengine.dir/uCursor.c.o CMakeFiles/hwengine.dir/uGearsHedgehog.c.o CMakeFiles/hwengine.dir/uCommands.c.o CMakeFiles/hwengine.dir/uGame.c.o CMakeFiles/hwengine.dir/uLandUtils.c.o CMakeFiles/hwengine.dir/uStore.c.o CMakeFiles/hwengine.dir/LuaPas.c.o CMakeFiles/hwengine.dir/uTextures.c.o CMakeFiles/hwengine.dir/uLandGenPerlin.c.o CMakeFiles/hwengine.dir/uGearsHandlers.c.o CMakeFiles/hwengine.dir/uIO.c.o CMakeFiles/hwengine.dir/uRenderUtils.c.o CMakeFiles/hwengine.dir/uChat.c.o CMakeFiles/hwengine.dir/uMatrix.c.o CMakeFiles/hwengine.dir/uLandGraphics.c.o CMakeFiles/hwengine.dir/uPhysFSLayer.c.o CMakeFiles/hwengine.dir/uVariables.c.o CMakeFiles/hwengine.dir/uConsts.c.o CMakeFiles/hwengine.dir/uAIMisc.c.o CMakeFiles/hwengine.dir/uCollisions.c.o CMakeFiles/hwengine.dir/uUtils.c.o CMakeFiles/hwengine.dir/uAI.c.o CMakeFiles/hwengine.dir/uFloat.c.o CMakeFiles/hwengine.dir/uTypes.c.o CMakeFiles/hwengine.dir/ArgParsers.c.o CMakeFiles/hwengine.dir/uScript.c.o CMakeFiles/hwengine.dir/uVisualGearsHandlers.c.o CMakeFiles/hwengine.dir/uLocale.c.o CMakeFiles/hwengine.dir/uGearsHandlersMess.c.o CMakeFiles/hwengine.dir/uGearsHandlersRope.c.o CMakeFiles/hwengine.dir/uVisualGearsList.c.o CMakeFiles/hwengine.dir/uGearsList.c.o CMakeFiles/hwengine.dir/uStats.c.o CMakeFiles/hwengine.dir/uGearsUtils.c.o CMakeFiles/hwengine.dir/hwengine.c.o -o ../../bin/hwengine ../../bin/libfpcrtl.a -llua5.1 -lGLU -lGL -lSM -lICE -lX11 -lXext -Wl,-Bstatic -lSDLmain -Wl,-Bdynamic -lSDL -lpthread -lSDL_mixer -lSDL_net -lSDL_image -lSDL_ttf -lGLEW /usr/lib/x86_64-kfreebsd-gnu/libphysfs.so ../../bin/libphyslayer.so -lm -Wl,-Bstatic -lSDLmain -Wl,-Bdynamic -lSDL -lpthread /usr/lib/x86_64-kfreebsd-gnu/libphysfs.so /usr/lib/x86_64-kfreebsd-gnu/liblua5.1.so -Wl,-rpath,"\$ORIGIN/../lib/:\$ORIGIN/:/usr/lib/hedgewars/lib/" /usr/bin/cmake -E cmake_progress_report /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/CMakeFiles CMakeFiles/hwengine.dir/uAmmos.c.o: In function uammos_FillAmmoStore': /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/project_files/hwc/uAmmos.c:35: undefined reference tostack_chk_guard' /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/project_files/hwc/uAmmos.c:51: undefined reference to `stack_chk_guard' CMakeFiles/hwengine.dir/uAmmos.c.o: In function uammos_AddAmmoStore': /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/project_files/hwc/uAmmos.c:54: undefined reference tostack_chk_guard' /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/project_files/hwc/uAmmos.c:129: undefined reference to `stack_chk_guard' CMakeFiles/hwengine.dir/uAmmos.c.o: In function uammos_SetAmmo': /«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/project_files/hwc/uAmmos.c:215: undefined reference tostack_chk_guard' CMakeFiles/hwengine.dir/uAmmos.c.o:/«PKGBUILDDIR»/obj-x86_64-kfreebsd-gnu/project_files/hwc/uAmmos.c:290: more undefined references to `stack_chk_guard' follow

thanks,

Gianfranco

[llvmbot]

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.

[llvmbot]

The issue should be now fixed on kfreebsd, sparc, sparc64, powerpc, powerpc64, powerpc64le, s390x. Can you try the build with current llvm trunk?

[llvmbot]

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).

[uweigand]

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(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 ...

[llvmbot]

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

[llvmbot]

Do you have an example of a file (.ii) where clang introduces a reference to __stack_chk_guard but gcc does not?

[llvmbot]

glibc version should be 2.19-12 or 2.19-13 (debian revision)