When I'm linking .o files with the LD linker using MinGW on Windows, it gives me the error "file.o: File not recognized: file format not recognized". I've tried to do it with cygwin instread, but the same thing happens. Any suggestions?
Most likely you have a object file in a format that the linker does not understand. There are lots of different formats out there: COFF, OMF, ELF (the list goes on..)
Fortunately there is a free tool that lets you convert from one format to another. It also lets you take a look into the internals of the object format and tells you in which format a object file is encoded.
http://www.agner.org/optimize/#objconv
That little command line utility solved all the object format problems I ever had. It can even disassemble libs, object files, DLLs and executables.
Related
I am trying to print all the Undefined function calls from a shared object file along with file name.
I tried with "nm" command, It print all the undefined function calls .But could not get the file name.
Example:
bash$ nm -u my_test.so
:
U _ZNSs4_Rep20_S_empty_rep_storageE##GLIBCXX_3.4
:
Environment : Ubuntu 18.04 , X86 Arch (Intel processor)
Study in details the specification of the DWARF format (which is the format used by debugging information on Linux). So you could extract the information (but it is not exactly simple) by parsing the DWARF inside your ELF binary.
Consider looking inside the source code of Ian Taylor's libbacktrace. It is doing this extraction of file name from DWARF inside ELF.
Perhaps your real problem is getting precise backtrace information, and then that libbacktrace is exactly what you need!
You might also use gdb : it is extensible and scriptable in Python (or Guile) and you could write your own specialized script.
Perhaps you'll better solve your real problem with some GCC plugin working when you compile your code.
Read How to write shared libraries by Drepper and read more about ELF.
You could for example collect all the undefined symbols in your shared library using nm (or readelf). Then a second script will find the occurrences of these in your source code. It could be even a simple awk script (or some for shell loop using grep), or something as sophisticated as a GCC plugin.
Your example shows (probably) a mangled C++ name. You could use nm -C to get it unmangled. And later write a GCC plugin to find all the GIMPLE CALL instructions using it.
Writing a GCC plugin may take some time, in particular if you are not familiar with GCC internals.
I use embedded system. After the C source code building I get many files. The file name is the same, but the extension is different:
.s37
.elf
.hex
.sig
What is the differences between them? Mainly what is the differences between .s37 and .elf?
Those are just different executable formats.
.s37 is one variant of SREC format, it's ascii/line fixed text including hex (binary)
This format is well known by flash/upload software in most embedded targets.
.elf is an executable & linkable file, product of a linker like gcc or other commercial compilers (Windriver, CodeWarrior...).
.elf format is hardly uploadable on embedded targets without conversion to .SREC with objcopy first.
One of the main differences in contents is that .elf format can contain debugging symbols, whereas .srec/.s37 cannot.
My guess is that your toolchain does it all: link: .elf, then objcopy to convert .elf to .s3 for target upload (losing symbol information if any, which requires you to keep the .elf file handy when debugging your application on the target, the SREC file contains only code & data, no debug).
S3 format can't contain symbols. They're discarded, even using a simple objcopy command. That format is only useful to contain code/data to upload on a target.
I am working with a different compiler CC. It doesn't work like GCC.
When I was using GCC, I can do "gcc -o exe_filename source_filename" and the output would be a exe file.
When I use CC, I need 2 steps. First I compile the source files (suppose it involve a .c and a .h file ) and it create a .lis file and a .obj file. Then I do a link command which created a .exe file.
What is the relationship between LIS, OBJ and EXE files? I ask this because I wonder which files do I need if I want to use the exe in another machine without including unnecessary files. If LIS and OBJ were only used for compilation, I don't need it in another machine.
The compiler takes C files (and includes H files as referenced) and produces object (OBJ) and listing (LIS) files. The object file contains the code and data, but has unresolved external references. The listing typically includes line numbers, error and warning messages, and optional sections such as a type and variable cross-reference.
The linker combines object files and resolves external references to libraries. The result is an executable (EXE) image. (Or shareable image when creating libraries.)
Only the executable file needs to be copied from one system to another to run the application. The listing may be useful for interpreting error messages as it provides the properly correlated line numbers. The object could be useful if the application needs to be relinked due to changes in libraries, particularly if the target system has older versions than the original system.
the OBJ files are the compiled C files in a format that they can be "Linked" together by a linker and turned into an EXE.
Compile -> OBJ -> Link -> EXE
the LIS file is just informational output of the C that the compiler ends up compiling.
All you need once compiled and linked is the EXE
You don't need the other files. The exe will work fine by itself.
I don't have much idea on LIS. But the difference between OBJ and EXE is OBJ file may contain unresolved symbols and in EXE file all symbols are linked and resolved.
If another machine also has same hardware then u can use direct exe to run else you have to cross compile
got a nasm project and i'm calling a c function from it
I put the name of the function in "extern"
and when linking i put all the links together but i can an error of "undefined reference to"
here is my compile/link command
gcc -o Project4 Project4.o array1c.c readdouble.o writedouble.o readarray.o printarray.o addarray.o invertarray.o invertarray2.o invertarray3.o averagearray.o quicksort.c
I would first compile all of your .c files using the "gcc -c" command into object files, then link those resulting .o files (such as "array1c.o" and "quicksort.o") together with your other pre-existing object files and see if that still gives you an undefined reference. That may be an unnecessary step, but I've never combined raw .c files and .o files in a single call to gcc.
You may also have to add an underscore to the beginning of any c-functions called ... I know this an be a platform dependent thing (i.e., Linux typically doesn't need underscores on c-functions whereas OSX and some other UNIX platforms do).
Lastly you could try, using ld, to just link all the object files together at once rather than linking some of the object files together into Project4.o, and then linking that to what you had assembled using nasm (at least that's what I'm assuming you're doing, i.e., you're making a Project4.o, and then calling functions from that in your assembly code).
Hope this helps,
Jason
I have checked the assembler options of GNU assembler as and I didn't find an option to specify the output object file format. If I am using the following command
as -o foobar.o foobar.s
What object file format will I get?
The as manual says that "The GNU as can be configured to produce several alternative object file formats." But how? How can I change it to a ELF format?
Many thanks.
On linux the output from gas is ELF already, it is unlikely you have a version which is building the old a.out format, or that you are using a cross compiler to say build to MachO or PE.
Use a cross-compiler for specific formats (ARM,MIPS etc.)
Get the entire CODESOURCERY toolchain here for free:
www.codesourcery.com/sgpp/lite_edition.html
GoodLUCK!!