I need to make hand crafted object file's and then link it with each other under windows. So what is linux .o files, GNU linker and nm windows alternatives?
I've already read this http://www.lurklurk.org/linkers/linkers.html it's great article but analysis of object file covers only linux. So I want to know how translated sources and names becomes object file, and then executable file.
Related
Looks like there are tons of webpages online and questions on SO, but I still can't get this to work after several hours of searching.
I'm cross-compiling from Linux to Windows by setting CC/CXX to x86-64 MinGW-w64. Compilation actually works and the exe runs fine on Windows.
With file I get this output:
PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows
I have two resource files (a Windows *.ico file and a *.res ASCII file that contains properties such as VERSIONINFO and the like).
The two resource files are transformed into *.o files with MinGW's windres tool. They look like COFF files now. That's as far as I could get.
What I want to do is link those two resources into the exe.
I don't find any way to instruct the Go linker to include those files during linking (I run go build, not go tool). I've also tried to add the resource post-linking with objcopy following various pages online and other SO questions... but to no avail.
All I want is Windows to recognize those two resources (icon and info) so that the executable behaves like any other on Windows.
If I should instruct the Go linker (go tool instead of go build), then how can I tell it which files to link? I have "simple" *.go files and then C dependencies (GLFW and OpenGL) I link with CGO.
How can this be done on the Linux command-line? I want to add these steps to a broader CI/CD (build workflow/asset pipeline). A Windows GUI tool or similar would not help much.
Thanks!
I don’t know if you are using Fyne, but it sounds like what “fyne package” does (embed icon and metadata).
If you are in Fyne land then you can use their tools, if not maybe check out the source and see for yourself how it’s done? https://github.com/fyne-io/fyne/blob/master/cmd/fyne/internal/commands/package-windows.go
I'm working on different Android projects and need to setup project in Source Insight for different kernel source tree.
There are many unused files in kernel, I want to find a method to pick out all .c,.h,.S files that are compiled in kernel. I was nearly crazy when I pick the source files manually.
I'd wrote a script that can pick up the files corresponding to the .o files, but there are some .o files are compiled by multiple .c files, which make it more complicated.
Is there an easier way to know what files are handled in the compiling process?
Any information would be greatly appreciated.
It's my first question in stackoverflow, I love here so much.
Thanks.
I always need to search the kernel source without looking at powerpc, ia86, sparc, alpha, infiniband, etc. Assuming you can compile the kernel, several ways of doing this:
1) $K/scripts/basic/fixdep.c is called from Makefile.build to create a .cmd file for each source which contains information about the compile options, compile source/target and dependency list. Modify this to write a separate file with just the source file or source/dependencies.
2) Hack $K/scripts/Makefile.build to log the currently compiled file. See the cmd_as_o_S and rule_cc_o_c areas.
Option #1 is the best but requires a little coding. Option #2 is easiest but a true hack, and doesn't pick up the dependencies.
i'm new year and I need some answer. I searched on the web to some answer but i didn't found anything usefull. What am i searching is for a shell programms that when you execute it, create a Makefile with the binary name in arguments like :
./automakefile.sh hello .
Will build you a Makefile with a binary name called hello.
I hope you guys will help me, i'm counting on you <3
There is, unfortunately, no such magic command. If there was, we wouldn't need Makefiles to start with because the magic would most likely have been incorporated in the compiler.
There are several reasons why there isn't a command like that.
Given a random binary file, you can't generally say what programming language it was written in.
You also can't tell what source file were used to compile the binary file from, or where in the file hierarchy they are located (not just where they were located when the binary file was compiled last time, maybe on another system).
You don't know the dependencies between the source code files. Makefiles are primarily useful for keeping track of these (and compiler flags etc.), so that changing one single source file in a big project does not trigger a recompilation of everything.
You don't know what compiler to use, or what flags to pass to it. This is another thing a Makefile contains.
There are build tools available for making the creation of Makefiles easier, and for making them portable between systems on different architectures (the Makefiles that is, not necessarily the programs, that's down to the programmer). One such set of tool is GNU's autotools, another is CMake, and I'm sure there are others as well, but those are the ones I use.
Now you're facing another but similar problem, and that is that you still need to learn the syntax of, and writ,e your Makefile.am and configure.ac files (for the GNU tools), or your CMakeLists.txt files (for CMake).
I'm messing around with compilers, .obj files, assembly, etc. The .obj file contains info that eventually ends up in the PDB, but I can't find any reference to the format that's used within the debug sections of the .obj file. (I have, however, found a reference to the COFF file format -- so I already know about that).
So: What's the format of the .debug$S and .debug$T sections when the source C file is compiled with the /Zi flag?
This information isn't published (the format used for native PDBs). If you can link the object file into an executable using "link" there are windows "debugging apis" you can use to "interrogate" symbols in an image. However, the format used for object files is not made publicly available.
You could try and reverse engineer it. If you find any info, please share it.
EDIT:
What I want is to distinguish statically linked library functions and user self-written functions within a compiled file (e.g. PE file).
How to achieve that? (I am thinking of database comparison but I do not know any database.)
By the way, (I have already known long before I asked this question) for dynamically linked library functions, they are just an entry in the import table (of PE).
By library functions, I mean those defined in libraries, such as STL (I know this is a bad name).
By user-defined functions, I mean those written by individual programmers.
Is there any programmatic way to achieve this goal?
Right now I am thinking about comparing binaries with a database, but I do not know any database so far.
Please recommend a database or a different way as an answer. Thank you.
This answer is assuming you want to analyze a standard Windows executable that is dynamically linked against other import libraries (.lib and assoicated .dll files that are not statically linked), and if this is the case, you want to interperet the PE (Portable Executable) file structure.
Here's a good article to get you started, with sample code on dumping the PE header.
You will want to focus on the Import table (.idata section) for external library calls, and the Export table (.edata section) for calls defined inside the executable and marked as exportable (usually this only exists in .dll files).
For static libraries, their format is called COFF, and there is the DUMPBIN utility that ships with Visual Studio that you can use to quickly peer into your lib files and even dump the disassembly of the code if you wanted.
The DUMPBIN utility, which is provided with the 32-bit version of
Microsoft Visual C++, combines the abilities of the LINK, LIB, and
EXEHDR utilities. The combination of these tools features the ability
to provide information about the format and symbols provided in
executable, library, and DLL files.
For information on the structure of COFF files, see this article.
Figuring out if a function call is from a lib or not would be tricky, but from what I remember, most static lib calls in code are actually thunk calls (simple jmp calls to the actual object code copied in from the lib) and are small in size (usually around 5 bytes), while "user defined" ones are not thunks, and are bp-based framed calls.
When your programm is linked, static functions and user-define functions are
include file by file.
So if you dump the header of a PE file, and look at the symbols
table (using objdump -x if you run with mingw32, or anything else)
you will see the name of a file and then all functions import from this one,
after an other file name and its functions...
Or if you have debug information, may be this can be easier.
So after you link functions with a file you can sort the functions by analysing their file name. Looking for extention (.c / .lib / .a) or check in a list of file you have somwhere.
Be carefull to eliminate crt0 files...
However this is kind a tricky solution and I'm not sure this'll work for every program.