I'm trying to compile my test program with various GCC optimizations options and I'd like to see all of them in the program output. Something like that (the __cpp_optimizations constant is invented for this question):
std::cout << __cpp_optimizations << std::endl;
Is it any way to do that?
Get the compiler options from a compiled executable? . Compile with -frecord-gcc-switches than read the command line options from the executable, in pseudocode:
buf = popen(std::string() + "readelf -p .GCC.command.line /proc/self/exe").read()
// or read elf yourself instead of popen
// tokenize buf, get all compiler options
// filter out only optimization options
Alternatively, you could instruct your build system to pass that information as a macro. For example, in CMake:
add_compile_options(-O3)
add_compile_definitions("CPP_OPTIMIZATIONS=\"-O3\"")
Related
I've been using WASM via emscripten for a few weeks now and had been making good progress, until this error:
exception thrown: RuntimeError: function signature mismatch,RuntimeError: function signature mismatch
This started happening in code that previously worked and seems to be something to do with WASMs lack of support for 64bit integers in javascript and the offsets used in file management. I've made an isolated case:
#include <iostream>
int main(int argc, char const *argv[])
{
char test[30];
std::cout << __LINE__ << std::endl;
FILE *f = fopen("minimal_call_dispatch.cpp","ra");
std::cout << __LINE__ << std::endl;
fseek(f, 100, SEEK_SET);
std::cout << __LINE__ << std::endl;
fclose(f);
std::cout << __LINE__ << std::endl;
return 0;
}
building with:
call emcc -o ./test.js test_file.cpp -s WASM=1 -s NO_EXIT_RUNTIME=1 -std=c++1z
Which outputs '6\n8\n' before failing on 'fseek' due to the mentioned error.
Somewhere along the line, I suspect that wasm is trying to use headers that communicate with javascript that have 64bit integers instead of 32bit ones but I can't see how that could have happened.
I'm going to try re-installing emscripten but even if that works, I'd like to get a better idea of what's causing this.
As a work around, does anybody know how to get emcc to ignore worries over 64bit integers and silently convert them to 32bit? I'm not looking to address more than 3gigs of ram, after all.
You got the error simply because your code is wrong.
You really don't need to worry about 32bit/64bit stuff. The current WebAssembly spec do not have 64-bit machine and it only have 32-bit addresses (but it supports 64-bit integer i64 internally and calculates 64-bit integers well. It just doesn't have 64-bit addresses.)
This means that the compiler is already knows the target machine is 32-bit and size_t will be 32-bit as will.
In the comments, I asked if you want to open the file or want to create the file. This is important because using "ra" with fopen() will cause segmentation fault when the file doesn't exist because of r flag!
Okay, lets try this in the native environment.
g++ test_file.cpp -o test.out
running ./test.out will prints the following if test_file.cpp doesn't exist:
6
8
[2] 14464 segmentation fault (core dumped) ./test.out
So your code is wrong, but why Emscripten throws the error differently? When you use emcc without debugging flags like -g, it will have the minimized environment that doesn't catch errors like segfault because such smart runtime will increase the binary size which is critical in the web environment. As a result the runtime keeps running ignoring segfualt and it will end up with a random error. So function signature mismatch doesn't mean anything.
You can build it using debugging-related options:
emcc -o ./test.html test_file.cpp -s WASM=1 -std=c++1z \
-g4 -s ASSERTIONS=2 -s SAFE_HEAP=1 -s STACK_OVERFLOW_CHECK=1 \
--source-map-base http://your_server_ip:port/
Then opening test.html you will see the correct error now:
exception thrown: RuntimeError: abort(segmentation fault) at Error
Now you won't get the misleading errors like signature mismatch :)
By the way, replace fopen("minimal_call_dispatch.cpp","ra"); with fopen("minimal_call_dispatch.cpp","a"); will fix the error.
With the correct --source-map-base server IP settings, you will have a better debugging experience. For example, you will get the source test_file.cpp in the browser so that you can set breakpoints to the .cpp file.
Have fun with debugging :)
Is there a way to store the compile-time flags in the output binary when using clang?
For example after running:
clang -O3 -c main.c
The resulting main.o file should somewhere contain -O3.
gcc has -frecord-gcc-switches but I'm unable to find an equivalent for clang.
As ecatmur already has implied in the comments. This feature is currently not supported as documented in bug https://llvm.org/bugs/show_bug.cgi?id=16291 .
However as a work around while the feature is not available I would suggest having your build process define a macro inside the program using clang's -D argument. For example assuming you are invoking this from a bash script (adjust to whatever build tool you use):
CLANG_ARGS='-O3 -c main.c'
clang $CLANG_ARGS -D CLANG_ARGS="\"${CLANG_ARGS}\""
Then in your C or C++ programs you add something along the lines of:
const char clangArgs[] = CLANG_ARGS;
Which you can then retrieve using a debugger or some such or even could add some code to print it from your program when invoked with the -V or --version switch.
I am trying to compile the following program:
#include <iostream>
int main(){
std::cout << "Hello, world!";
return 0;
}
When I compile it, I get this message:
C:\programs>g++ test.cpp
Info: resolving std::cout by linking to __imp___ZSt4cout (auto-import)
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: warning: a
uto-importing has been activated without --enable-auto-import specified on the c
ommand line.
This should work unless it involves constant data structures referencing symbols
from auto-imported DLLs.
The build succeeds and the executable runs as expected, but this warning still irritates me. I expect a successful build to be completely silent. This message gives the false impression that there's something wrong with my code.
I can silence this error with g++ -Xlinker --enable-auto-import test.cpp, but this is undesirable, as it triples the number of characters I need to type to compile a program.
Questions:
Why does this warning appear for the simplest of programs? i don't expect cryptic warnings when I compile Hello World.
Is it possible to silence this warning without passing the flag to the linker every time? An option in a config file hidden somewhere in c:\mingw, perhaps? Or maybe I missed an "automatically enable auto-import" checkbox during installation?
Possibly Relevant Specs
GCC Version 4.5.0
ld.exe Version 2.20.51.20100613
Windows XP Service Pack 3
I used to face same problem as you do with g++. I solved this irritating problem just now. Here is how I come to the solution, step-by-step:
On Windows, you can create an alias of g++ with all given options which you want to use with g++. Say, for example, you want to create an alias s++ of g++ -enable-auto-import, then you run this on cmd as:
C:\>doskey s++=g++ -enable-auto-import
This creates an alias called s++. But this alias will not take any command line argument, which means, you cannot write this:
C:\>s++ filename.cpp //it is not working
To make it work, if you've to tell the alias to accept command line arguments while creating it, so here is how it is done:
C:\>doskey s++=g++ -enable-auto-import $*
Please note the $* at the right, which indicates that now s++ can take command line argument:
C:\>s++ filename.cpp //yayyyy..its working now, without giving any warnings!
But you may not prefer to create the alias everytime you open cmd. In that case, you can create a shortcut of cmd.
For example, I created a shortcut called Console and in the Target textbox of shortcut window, I wrote this:
C:\WINDOWS\System32\cmd.exe /K doskey s++=g++ -enable-auto-import $*
And since this is too long (horizontally), one screenshot was not able to capture the entire command. I took two screenshots so that you could see yourself how I did it:
Left part of the command
Right part of the command
For more information on creating aliases on windows, see this:
Creating aliases on Windows
I did some reading and it looks like it might be related to the mingw32 dll not having dllimport attributes defined.
Perhaps there is a patch or you can rebuild mingw32 yourself and add them?
I am trying to compile the following program:
#include <iostream>
int main(){
std::cout << "Hello, world!";
return 0;
}
When I compile it, I get this message:
C:\programs>g++ test.cpp
Info: resolving std::cout by linking to __imp___ZSt4cout (auto-import)
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: warning: a
uto-importing has been activated without --enable-auto-import specified on the c
ommand line.
This should work unless it involves constant data structures referencing symbols
from auto-imported DLLs.
The build succeeds and the executable runs as expected, but this warning still irritates me. I expect a successful build to be completely silent. This message gives the false impression that there's something wrong with my code.
I can silence this error with g++ -Xlinker --enable-auto-import test.cpp, but this is undesirable, as it triples the number of characters I need to type to compile a program.
Questions:
Why does this warning appear for the simplest of programs? i don't expect cryptic warnings when I compile Hello World.
Is it possible to silence this warning without passing the flag to the linker every time? An option in a config file hidden somewhere in c:\mingw, perhaps? Or maybe I missed an "automatically enable auto-import" checkbox during installation?
Possibly Relevant Specs
GCC Version 4.5.0
ld.exe Version 2.20.51.20100613
Windows XP Service Pack 3
I used to face same problem as you do with g++. I solved this irritating problem just now. Here is how I come to the solution, step-by-step:
On Windows, you can create an alias of g++ with all given options which you want to use with g++. Say, for example, you want to create an alias s++ of g++ -enable-auto-import, then you run this on cmd as:
C:\>doskey s++=g++ -enable-auto-import
This creates an alias called s++. But this alias will not take any command line argument, which means, you cannot write this:
C:\>s++ filename.cpp //it is not working
To make it work, if you've to tell the alias to accept command line arguments while creating it, so here is how it is done:
C:\>doskey s++=g++ -enable-auto-import $*
Please note the $* at the right, which indicates that now s++ can take command line argument:
C:\>s++ filename.cpp //yayyyy..its working now, without giving any warnings!
But you may not prefer to create the alias everytime you open cmd. In that case, you can create a shortcut of cmd.
For example, I created a shortcut called Console and in the Target textbox of shortcut window, I wrote this:
C:\WINDOWS\System32\cmd.exe /K doskey s++=g++ -enable-auto-import $*
And since this is too long (horizontally), one screenshot was not able to capture the entire command. I took two screenshots so that you could see yourself how I did it:
Left part of the command
Right part of the command
For more information on creating aliases on windows, see this:
Creating aliases on Windows
I did some reading and it looks like it might be related to the mingw32 dll not having dllimport attributes defined.
Perhaps there is a patch or you can rebuild mingw32 yourself and add them?
I'm developing on an ARM9E processor running Linux. Sometimes my application crashes with the following message :
[ 142.410000] Alignment trap: rtspserverd (996) PC=0x4034f61c
Instr=0xe591300c Address=0x0000000d FSR 0x001
How can I translate the PC address to actual source code? In other words, how can I make sense out of this message?
With objdump. Dump your executable, then search for 4034f61c:.
The -x, --disassemble, and -l options are particularly useful.
You can turn on listings in the compiler and tell the linker to produce a map file. The map file will give you the meaning of the absolute addresses up to the function where the problem occurs, while the listing will help you pinpoint the exact location of the exception within the function.
For example in gcc you can do
gcc -Wa,-a,-ad -c foo.c > foo.lst
to produce a listing in the file foo.lst.
-Wa, sends the following options to the assembler (gas).
-a tells gas to produce a listing on standard output.
-ad tells gas to omit debug directives, which would otherwise add a lot of clutter.
The option for the GNU linker to produce a map file is -M or --print-map. If you link with gcc you need to pass the option to the linker with an option starting with -Wl,, for example -Wl,-M.
Alternatively you could also run your application in the debugger (e.g. gdb) and look at the stack dump after the crash with the bt command.