I'm trying to enable gcc' s canaries' generation but I get an undefined reference to __stack_chk_guard.
From gcc's man about canaries :
-mstack-protector-guard=guard
Generate stack protection code using canary at guard. Supported locations are global for
global canary or tls for per-thread canary in the TLS block (the default). This option
has effect only when -fstack-protector or -fstack-protector-all is specified.
These -m switches are supported in addition to the above on x86-64 processors in 64-bit
environments.
I've done this test program :
#define VALUE 2048
int main()
{
char arr[VALUE];
int i;
for (i = 0; i < VALUE + 15; i++) // "i < VALUE + 15" is to test if canaries works but the code doesn't compile anymore with "i < 10"
arr[i] = '0';
return 0;
}
As said in gcc's man, my compilation line is :
gcc main.c -fstack-protector-all -mstack-protector-guard=global
But I get the following error :
/tmp/ccXxxxVd.o: In function `main':
main.c:(.text+0xe): undefined reference to `__stack_chk_guard'
main.c:(.text+0x51): undefined reference to `__stack_chk_guard'
collect2: error: ld returned 1 exit status
How can I remove this error ?
EDIT:
OS: ubuntu 14.10 utopic
architecture: x86-64
environments: 64-bit
It would appear that the -mstack-protector-guard option is only for backwards compatibility with how the stack protector worked in the past. In the past the canary was in a global variable. Later it was switched to TLS. It would appear that the operating system / libc you use either removed or never had support for the global variable canary, so only TLS works.
Don't touch the -mstack-protector-guard option and everything should work. The default should be fine when you use -fstack-protector-all.
Provide __stack_chk_guard with a random value in c file, avoid using regular values like all zero's or FF's because the stack can easily get these values during any memory operation. Wiki on providing magic number implementation. This __stack_chk_guard will be placed at the top and bottom of the stack, which will be checked during every stack access. Any change in the value implies a corrupted stack and returns with error providing the stack protection.
unsigned long __stack_chk_guard;
void __stack_chk_guard_setup(void)
{
__stack_chk_guard = 0xBAAAAAAD;//provide some magic numbers
}
void __stack_chk_fail(void)
{
/* Error message */
}// will be called when guard variable is corrupted
There are two ways to remove this error: 1. From the compiler option disable(comment out) the "stack guard".
Define __stack_chk_guard in you c file.
When you define __stack_chk_guard make sure you provide random value to it. For providing random value you need to pass as an argument to the random function.
For any further detail you can refer to the compiler manual.
For those that get this error in bare metal software development with a custom linker script, make sure to pass the option -nostdlib option:
gcc -nostdlib
since Ubuntu 16.04 for example enables the stack protection by default on the compiler. man gcc says:
NOTE: In Ubuntu 14.10 and later versions, -fstack-protector-strong is enabled by default for C, C++, ObjC, ObjC++, if none of -fno-stack-protector, -nostdlib, nor -ffreestanding are found.
-fno-stack-protector also solved it for me, but you should likely tell your poor compiler that you are doing baremetal stuff to prevent other such problems.
I'm guessing this is because the feature relies on symbols which are normally defined if a linker script is not given? But TODO I found no mention of those symbols by dumping the default linker script with:
aarch64-linux-gnu-gcc -Wl,-verbose main.c
so I'm not sure.
I grepped GCC 6.4.0 source code and it suggests that the symbol comes from libgcc2.c at gcc/doc/tm.texi:
The default version of this hook creates a variable called
#samp{__stack_chk_guard}, which is normally defined in #file{libgcc2.c}.
Related
I'm trying to move from msvc to clang and I'm having trouble finding info on some of the flags I'm using. Also, I know there is clang-cl but I'm trying to use zig cc as my compiler and it only excepts normal clang flags as far as I know.
In msvc I use -Eha- since I don't use exceptions and don't want compiler to generate any exception handling code. Is there an equivalent flag on clang? Or is this disabled by default? Also, I'm not linking to the CRT and in order to do this with MSVC I'm disabling security checks with -GS- and stack probing with -Gs9999999 (according to this guide https://hero.handmade.network/forums/code-discussion/t/94-guide_-_how_to_avoid_c_c++_runtime_on_windows). Is there an equivalent with clang? I searched for some keywords in clangs compiler flag documentation but having trouble finding info
Edit:
Was given a suggestion to try to add the option 'clang:-fno_exceptions' to clang-cl but got the warning: "clang-cl: warning: fno-exceptions: 'linker' input unused [-Wunused-command-line-argument]". Tried adding it as an argument to lld-link but get unknown argument.
Here is the argument list I'm passing with clang-cl
REM -GS- tells compiler to not worry about security calls (like __security_cookie) that would typically be inserted with c libs. -Gs99999999999 basically says don't worry about __chkdsk for checking stack overruns
set compiler_flags=-clang:-g -clang:-fdebug-macro -clang:-O0 -clang:-fno-exceptions -GS- -clang:-mstack-probe-size=9999999 -wd4505 -wd4101 -wd4530 -w14700 -wd4100 -we4820 -wd4201 -wd4189 -fno-builtin
REM -STACK:0x100000,0x100000 is setting function stack default to 1MB. Can increase this if we need to. Keep in mind though this also increases default stack size for all threads created
set linker_flags=-subsystem:windows -machine:x64 -incremental:no -opt:ref -debug:full -ignore:4099 -NODEFAULTLIB -STACK:0x100000,0x100000
Code as below:
int main (int argc, char *argv[]) {
long pid = (long)getpid();
long test = pid + 1;
}
Have not included any head files, still can compile code successfully and still can run program successfully.
Why?
Environment info: Ubuntu 18.04.2 LTS, gcc (Ubuntu 4.8.5-4ubuntu8) 4.8.5
Have not included any head files,still can compile code successfully.
still can run program successfuly.Why?
Why not?
All question of whether the particular code presented conforms to the language standard notwithstanding, language non-conformance does not imply that compilation or execution must fail. Instead, you get undefined behavior, which can manifest in any manner within the power of the machine to produce, including compiling successfully and running as intended.
In your particular case, however, you are using GCC 4.8.5. The GCC 4.8 series defaults to compiling for the C90 standard, with GNU extensions. C90 allows calls to functions with no in-scope declaration, for compatibility with earlier, pre-standardization practice. That is no longer allowed in C99 or later, but many implementations nevertheless continue to accept it as an extension.
It should be understood, however, that C interprets some argument lists differently when the called function has an in-scope prototype than when it doesn't (which may be the case even for functions that are declared, because not all declarations provide prototypes). You may be able to get away with calling undeclared functions under some circumstances, but it is poor style, and if you do it enough then it will bite you at some point.
Note also that GCC 4 definitely has the ability to emit warnings about usage such as yours, even when compiling in C90 or GNU90 mode. You would be well served to turn on the -Wall option when you compile, and maybe additional warning options as well.
Normally, to use a dynamic library function you would have to link against the specified library at compile time through the -l switch, like for example gcc -lm prog.c when using the mathematic functions (from libm).
However, since it's so common, GCC always links the standard C library by default, meaning that doing gcc prog.c is actually the same as doing gcc -lc prog.c. This is always done whether you include any header or not.
The second thing that makes this work, is that GCC assumes any function that has not been declared at compile time to have the signature int func(void). In this case, the signature is quite similar to the one of the real getpid() function.
If you take a look at your compiled program with the ldd tool to show which dynamic libraries are required, you'll see that the program is linked against libc:
$ ldd prog
linux-vdso.so.1 (0x00007ffede7d0000)
==> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0f47018000)
/lib64/ld-linux-x86-64.so.2 (0x00007f0f475b9000)
When your program runs, it asks the dynamic loader where (at which address) to find the getpid function before calling it the first time. The dynamic loaders checks the loaded libraries, and finds a function with that name in libc, so everything seems to work without a problem.
You can tell GCC to not link against the standard library by default using the -nostdlib compiler switch, but this is not that useful in your case. The real solution is to always treat warnings about implicit function declarations as errors (-Werror=implicit-function-declaration).
If your compiler doesn't give this warning by default, I would suggest you to upgrade it to a newer version. GCC 4 is definitely not the latest version available for Ubuntu 18.
$ sudo apt update
$ sudo apt upgrade
Is there any way to make a global variable both "hidden" and "aliased"? It would seem the following would be sufficient:
int __voo __attribute__((visibility("hidden")));
extern int voo __attribute__((weak,alias("__voo")));
But this results in:
$ gcc -c alias.c
/tmp/cczCek0H.s: Assembler messages:
/tmp/cczCek0H.s:5: Error: `voo' can't be equated to common symbol '__voo'
Removing "weak" has no effect.
However, adding "static" to the variable declaration allows the link to succeed, but is not the desired effect, as static limits the variable visibility scope to the compilation unit, not the broader scope of the linked object.
Intel System Studio 2019, GCC 4.8.5 and GCC 5.3.1 all show the same behavior.
I had a similar issue. I wasn't even trying to use hidden, and I still got the "can't be equated to common symbol" error. The fix was to initialize the int __voo to some value (even 0). Perhaps it was a BSS vs Data thing, or just a bug.
I got it to work by also supplying -fno-common to the compiler invocation. This might make some not strictly correct C code stop working though, so read what -fno-common does before using it.
It also works if I compile with clang.
I am currently writing a C program with threads and I make use of pthread_cleanup_push_defer_np() and pthread_cleanup_pop_restore_np(). Provided that:
I have included pthread.h;
I am compiling with -pthread option;
I am on Ubuntu 14.04 and using gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1);
when compiling I get back a nasty undefined reference error to the above mentioned functions and I can't figure out why. I have tried to take a look into pthread.h and it seems those two functions are commented out, so I am wondering whether I need to enable them in some way or use some other kind of options. I've read the manual pages and google it up but I can't find a solution, so I would appreciate a little help. Here it is a snippet:
void *start_up(void *arg)
{
char *timestamp;
// ... code ...
timestamp = get_current_timestamp("humread");
pthread_cleanup_push_defer_np(free, timestamp);
// ... some other code
pthread_cleanup_pop_restore_np(1);
// ... more code ...
}
I compile with
gcc -pthread -o server *.c
The manual of pthread_cleanup_push_defer_np and pthread_cleanup_pop_restore_np say these two (non portable) functions are GNU extensions and are enabled
by defining _GNU_SOURCE:
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
pthread_cleanup_push_defer_np(), pthread_cleanup_pop_defer_np():
_GNU_SOURCE
This results in linker error (as opposed to compile time error) because your compiler is pre-C99 (or you are compiling in pre-C99 mode) and assumes these functions return int by default.
The rule functions-return-int if no prototype is present has been removed since C99. Enabling more compiler switches can help you with better diagnostics.
(Running MingW on 64-bit Windows 7 and the GCC on Kubuntu)
This may possibly be just a MingW problem, but it's failed on at least one Kubuntu installation as well, so I'm doubtful.
I have a short, simple C program, which is supposed to call an assembly function. I compile the assembler using nasm and the c program using MingW's implementation of the gcc. The two are linked together with a makefile - bog-simple. And yet, linkage fails on the claim the claim that the external function is an 'undefined reference'
Relevant part of the makefile:
assign0: ass0.o main.o
gcc -v -m32 -g -Wall -o assign0 ass0.o main.o
main.o: main.c
gcc -g -c -Wall -m32 -o main.o main.c
ass0.o: ass0.s
nasm -g -f elf -w+all -o ass0.o ass0.s
The beginning of the assembly file:
section .data ; data section, read-write
an: DD 0 ; this is a temporary var
section .text ; our code is always in the .text section
global do_str ; makes the function appear in global scope
extern printf
do_str: ; functions are defined as labels
[Just Code]
And the c file's declaration:
extern int do_str(char* a);
This has worked on at least one Kubuntu installation, failed on another, and failed on MingW. Does anyone have an idea?
... the claim that the external function is an 'undefined reference'
LOL! Linkers do not "claim" falsehoods. You will not convince it to change its mind by insisting that you are correct or it is wrong. Accept what the tools tell you to be the truth without delay. This is key to rapidly identifying the problem.
Almost every C compiler, including those you are using, generates global symbols with an underscore prefix to minimize name collisions with assembly language symbols. For example, change your code to
extern _printf
...
call _printf
and error messages about printf being undefined will go away. If you do get an undefined reference to _printf, it is because the linker is not accessing the C runtime library. The link command can be challenging to get correct. Usually doing so is not very educational, so crib from a working project, or look for an example. This is way that IDEs are very helpful.
As for the C code calling the assembly function, it is usually easiest to write the assembly function using C's conventions:
global _do_str
_do_str:
Alternatively, you could declare the function to use the Pascal calling convention:
extern int pascal do_str ( whatever parameters are needed);
...
retval = do_str ("hello world");
The Pascal calling convention is substantially different from C's: it does not prepend a leading underscore to the symbol, the caller is responsible for removing the parameters after return, and the parameters are in a different order, possibly with some parameter data types being passed in registers rather than on the stack. See the compiler references for all the details.
C compilers may call the actual "function" differently, e.g. _do_str instead of do_str. Name mangling not happening always could depends on the system (and of course on the compiler). Try calling the asm function _do_str. Using proper attributes (in gcc) could also fix the problem. Also read this.