Skip to content

Tag: gcc

why does the local array has extra empty location at the end(c/c++/gcc)?

Check below program, In the above program, even though array size is 10, after the first array there is exactly 6 extra locations reserved in the stack (12bytes), I am wondering why this extra space got reserved? and this extra space size is varying for different size(Its not 12 for size 20). Can anybody explain the concept behind these allocations?

Why does this nostdlib C++ code segfault when I call a function with a thread local variable? But not with a global var or when I access members?

Assembly included. This weekend I tried to get my own small library running without any C libs and the thread local stuff is giving me problems. Below you can see I created a struct called Try1 (because it’s my first attempt!) If I set the thread local variable and use it, the code seems to execute fine. If I call

Compiler cannot find header file within header file in C++

I have a header file provided by yaml-cpp library, yaml.h yaml.h: main.cpp All the header files are in the same directory (/home/user/application/libs/yaml-cpp/include), but the compiler is unable to find parser.h and all the other includes. Why is this so and how do I fix it? I have tried using g++ -I/home/user/application/libs/yaml-cpp/include main.cpp but that did not work. I am on

Compiler version in C++ vs pre-compiled C libraries

I have a code that uses std=c++20. I want to use a C library that was build with old gcc version. Should I recompile the C library using the same compiler ? If no, how could you judge that the 2 ABIs are compatible? Answer There should be no problem using the library as it is. Don’t forget to add

Understanding ELF64 text/data segment layout/padding

I’m trying to brush up on UNIX viruses and one text I’m reading mentions that parasitic code can be inserted in the padding between the text and the data segment, supposedly up to 2MB in size on x86-64 systems. But when I compile a simple hello world program with gcc -no-pie… …and inspect its segment headers with readelf -W -l

Stringizing / stringify name mangling

I load a path name with cmake and want to use as a string in my C++ program to load some data. For this the stringification operator # is really handy – I use the macro provided in this answer which is the same as here. Now when I have “linux” or “unix” in my path, this goes horribly wrong

Why does link against unexpected location?

I have installed a new glibc in /root/tools/ in debian which already has a pre-installed glibc. For testing the new glibc, I type : produces a.out, then type: it shows But type ls -l /root/tools/lib/ , it shows /root/tools/lib/ -> Why does in new glibc link against in /lib64 ? How to explain this ? Answer then

GCC promotes weird relocation R_X86_64_32S error but not in manually linking

I’m trying to invoke sys_write via the syscall instruction under Linux environment on an x86_64 machine with inline assembly in C files. To achieve this, I wrote the following code: While my compiling it with GCC, the following error promoted: Then I added -fPIE to the compiler command. Unfortunately, nothing changed: This is so weird that it made me curious

Why tm_gmtoff field of struct tm is not documented in man page?

I need to get the difference between UTC and the local time using GCC on Linux. It seems that the preferred way is to examine tm_gmtoff field of a struct tm returned by localtime function. However, tm_gmtoff is not documented in the man page of localtime, but only tm_zone is. It looks like tm_gmtoff and tm_zone exist in