Wondering if it is possible to generate interleaved source and assembly from clang?
I am looking for something equivalent to gcc command (as demonstrated at http://www.fclose.com/240/generate-a-mixed-source-and-assembly-listing-using-gcc/)
gcc -Wa,-adhln -g source_code.c > assembly_list.s
I have visited Link: How do you get assembler output from C/C++ source in gcc? but it gets so far as to list the assembly - but no interleaving.
Also Visual Studio does give you pretty nice interleaved assembly output, details here: How to view the assembly behind the code using Visual C++?
Thank you for all the help.
Sarang
There seems to be a bug reported sometimes last year stating exactly this: http://llvm.org/bugs/show_bug.cgi?id=16647
Bug 16647 - No option to produce mixed source + assembly listing?
So since it is still NEW I guess clang does not have this supported yet.
As an alternative, how about compiling your code and then use objdump -S ? The output format is somewhat similar ...
As of August 2016, the bug that #dragosht mentioned still is open. However, there is a workaround offered by the linked bug 17465: clang -no-integrated-as -Xassembler -adhln. It disables the clang-integrated assembler and calls an external assembler, which hopefully supports the listing-generating options.
That works OK in Linux, but it doesn't work in Mac OS X (as of 10.11.6). The problem is that even the external assembler in OS X does not support the listing-generating options - you can check that with man as.
objdump -S is an alternative that also works well in Linux, but Mac OS X's alternative to objdump is otool, which does provide disassembly but not source interlacing. Hopefully that will change soon-ish, because otool seems to be on its way out while llvm grows its own objdump. See man llvm-otool.
Finally, for OS X the best option seems to be using gobjdump -S, from binutils. It can be installed with MacPorts or brew.
You can Generate Assembly Code from a .cc/.cpp source file by using this command
clang++ -c -S test-function.cc
Related
I am trying to compile a code with crayftn.
I get an error message
/opt/cray/pe/cce/10.0.1/binutils/x86_64/x86_64-pc-linux-gnu/bin/ld: failed to convert GOTPCREL relocation; relink with --no-relax
So it wants the flag --no-relax? OK, I can do that. So I re-link with that flag, and then it tells me
ftn -O3 --no-relax -dynamic -h pic -h omp -o stream_cray stream_mpi.o mysecond.o
ftn-2115 crayftn: ERROR in command line
"-no-relax" is an invalid command-line option.
So it asks for "--no-relax", but then it doesn't understand it. Anyone know of a way out of this conundrum? Or another way of solving the root problem in the first place?
I found this link:
https://bb.cgd.ucar.edu/cesm/threads/failed-to-convert-gotpcrel-relocation-relink-with-no-relax.4494/
PROBLEM:
Hi, I get the following error message for CLM5.0 compilation with
Intel compilers, during the final cesm bld ..ld: failed to convert GOTPCREL relocation; relink with --no-relax
SOLUTION:
Hi, Seems like found a solution to fix the compilation ...Adding of
"-Wl,--no-relax" in LDFLAGS does not solve this problem, but
"-mcmodel medium" in FFLAGS fixes this issue, after searching for
"Relocation truncated to fit" in google search engine, it comes up
with this link which was helpful to solve the issue
"https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/268394"
Best Regards,Prabhakar
See also:
https://community.intel.com/t5/Intel-Fortran-Compiler/relocation-truncated-to-fit/td-p/1146616
This looks like mixing compilers and libraries from different systems
mixed up, either 32bit vs. 64bit or installations for ifort and
mpiifort based on different glibc or something similar.
I'm still curious about your "development environment":
Q: Have you been able to successfully compile, link and run ANY
program with your crayftn? Q: What version of crayftn? 10.0.1? Q: What
platform? Where is x86_64-pc-linux coming from? Just curious...
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 have just downloaded clang 3.3 (homebrew) from the LLVM web page to my mac (OS X 10.8.4), but get this compiler error when using std=c++11 stdlib=libc++:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:594:
In file included from /usr/include/c++/v1/memory:590:
In file included from /usr/include/c++/v1/typeinfo:61:
/usr/include/c++/v1/exception:146:5: error: an attribute list cannot appear here
_LIBCPP_NORETURN friend void rethrow_exception(exception_ptr);
^~~~~~~~~~~~~~~~
/usr/include/c++/v1/__config:190:28: note: expanded from macro '_LIBCPP_NORETURN'
# define _LIBCPP_NORETURN [[noreturn]]
^~~~~~~~~~~~
It seems that I also need another libc++ (even though it was said that it was 100% complete on MAC ...), but I cannot find any. Any help appreciated. Just for your info:
> clang++ -v
clang version 3.3 (tags/RELEASE_33/final)
Target: x86_64-apple-darwin12.4.0
Thread model: posix
And, yes, I googled it and found this: http://comments.gmane.org/gmane.comp.compilers.llvm.bugs/24138 claiming it's resolved in libc++ trunk ???
Okay, as suggested by Howard, I've downloaded tip-of-the-trunk libc++ into /opt/local/share/libcxx, but have trouble building it. The manual says to cd libcxx/lib, export TRIPLE=-apple-, and run ./buildit. I presume this implies bash (I'm usually a tcsh user, so I moved my .tcshrc, got a new shell and started bash). I did that and the compilations worked, but the library build failed. Apparently ./buildit doesn't see $TRIPLE=-apple-, as it picks the wrong LDSHARED_FLAG (not that on line 81, but that on line 103, which is to be used if $TRIPLE is not set), even though echo $TRIPLE yields -apple- as it should. When I add the statement echo TRIPLE = $TRIPLE at the top of buildit, it reports nothing. How come? What is wrong here?
The failure was that because the wrong LDSHARED_FLAG was picked the loading didn't work (ld complaint about the unknown option -soname which, I think, makes sense under linux). I don't know why buildit (a #! /bin/sh file) didn't pick up the TRIPLE environment variable (it did pick up several unwanted ones such as CXX and CC). I now simply added TRIPLE=-apple- at the top of that file and it did built the library. However, the loader spitted out several warnings all of which were of the form
ld: warning: direct access in ___cxa_bad_typeid to global weak symbol typeinfo for std::bad_typeid means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
But most importantly, it works (the compilation at least, I have yet to test the library). I have one final question. The advice was to use -I and -L to tell the compiler about the whereabouts of this version. Is it not possible to put it into the usual place /usr/include/c++/v1/? Note that Xcode has its version somewhere else anyway and I had put in a symbolic link (/usr/include/c++/v1/) to that one to get my homebrew clang 3.2 working (after the some Xcode update). What about the library? Can I also put it in a standard place?
Here is the home page of libc++:
http://libcxx.llvm.org
You can download the tip-of-trunk libc++ from there. You can tell clang to point to your download with -nostdinc++ -I<path-to-libc++>/include. You can also tell clang to link to your tip-of-trunk libc++ with -L<path-to-libc++>/lib and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib. The directions are all on the libc++ home page.
Xcode is the easiest way to get clang + libc++. But if you want the very latest, this is the place to go.
Congratulations!
Don't worry about the ld warning. It is a harmless ld bug that will be fixed in a future release. I see it on 10.8.4 too and it doesn't hurt anything.
The libc++ headers no longer live at /usr/include/c++/v1. Xcode has migrated them into itself. Having libc++ headers at /usr/include/c++/v1 from older installs has been a source of confusion and bugs. I regularly use -nostdinc++ -I to point to the libc++ headers I want (I often have several versions going at the same time), and that works well for me.
It is possible for you to replace your /usr/lib/libc++.1.dylib with that you have built. I do not recommend doing this. I have to sometimes to do a proper test, but I always do so very carefully because sometimes this causes me to have to reboot onto a backup disk and restore my /usr/lib to its original state. If you do go this route, it is a very good idea to have a backup of the original /usr/lib/libc++.1.dylib very handy.
I recommend instead -L on the command line, and export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib in the shell. More than one person (including myself) has gotten their computer into a really nasty place by not following this advice.
If you run testit (under test/), all you need is DYLD_LIBRARY_PATH in that shell. The testit script is set up to point to the right places without an install.
Also I recommend figuring out why you had to modify buildit. No one else is seeing that behavior. printenv on your command line may help in this endeavor.
libc++ is updated often. We try to keep tip-of-trunk always in a shippable state.
Perhaps a very trivial question:
I need to compile a program as 64-bit (earlier makefile written to compile it as 32-bit).
I saw the option -m32 appearing in command line parameters with each file compilation. So, I modified the makefile to get rid of -m32 in OPTFLAG, but again when the program compiles, I still see -m32 showing up and binaries are still 32-bit. Does this m32 come from somewhere else as well?
-m32 can only be coming from somewhere in your makefiles, you'll have to track it down (use a recursive grep) and remove it.
When I am able to force -m64, I get "CPU you selected does not support x86-64 instruction set".Any clues?. uname -a gives x86_64
That error means there is an option like -march=i686 in the makefiles, which is not valid for 64-bit compilation, try removing that too.
If you can't remove it (try harder!) then adding -march=x86-64 after it on the command line will specify a generic 64-bit CPU type.
If the software you are trying to build is autotools-based, this should do the trick:
./configure "CFLAGS=-m64" "CXXFLAGS=-m64" "LDFLAGS=-m64" && make
Or, for just a plain Makefile:
env CFLAGS=-m64 CXXFLAGS=-m64 LDFLAGS=-m64 make
If you are using CMake, you can add m64 compile options by this:
add_compile_options(-m64)
When using gcc version 4.3.2, I see how to generate specs using:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Using built-in specs
Now changing to the same directory as libgcc:
cd /usr/local/gcc-4.3.2/lib/gcc/x86_64-unknown-linux-gnu/4.3.2
/usr/local/gcc-4.3.2/bin/gcc -dumpspecs > specs
I have a populated specs file that I can modify. However, once that is done I still see that:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Using built-in specs
How do I tell gcc to use that specs file by default rather than forcing me to pass a -specs parameter every compile? I would like it to match another system I have where I get the following:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Reading specs from /usr/local/gcc-4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/specs</code>
As you can see, the major difference between the two systems is that the existing setup is 32-bit and I am now trying to match that on a 64-bit system. The version of Linux is otherwise the same and I am compiling the same version of gcc. (With both systems gcc 4.3.2 is the second gcc installation, with 4.1.2 being used to compile 4.3.2)
As hinted at by the strace suggestion by Johannes Schaub - litb, it was a problem with where the compiler was looking for the file. As it turns out, the non-working installation had an environment variable set in the .bashrc that was causing the confusion.
The correct location for the specs file is indeed the same directory that libgcc is in. Just be sure you're looking there.
I used this command line:
/usr/bin/set-gcc-default-3.sh i686-pc-mingw32
but you'll probably want:
/usr/bin/set-gcc-default-4.sh i686-pc-linux-gnu
(Note the -4 instead of -3)
This is built using the "alternatives" stuff, please see
/usr/sbin/alternatives.exe --help
And also see pages such as http://linux.about.com/library/cmd/blcmdl8_alternatives.htm
You rebuild gcc with your specs file as part of the build!
A simpler solution is to create an alias:
alias gcc_Gary gcc -specs /<folder With Specs File>/newSpecsFile