We are building an embedded application (ARM Cortex M4) with some third party library (**.a files). Would symbols from that library shows up in map file?
As I understand it map file list all symbols including variable and function names but in my map file, I do not find certain symbol from a linked library listed.
A library is a collection of object files in a single file package. The linker extracts and links only those object files necessary to resolve references from other object files, anything else will be omitted.
So your map file will only show the symbols actually included by the linker, not the entire library.
Your compiler may support a "used" directive for force other wise usreferenced code to be included in the link.
Related
I'm building a shared library. I need only one function in it to be public.
The shared library is built from a few object files and several static libraries. The linker complains that everything should be build with -fPIC. All the object files and most static libraries were built without this option.
This makes me ask a number of questions:
Do I have to rebuild every object file and every static library I need for this dynamic lib with -fPIC? Is it the only way?
The linker must be able to relocate object files statically, during linking. Correct? Otherwise if object files used hardcoded constant addresses they could overlap with each other. Shouldn't this mean that the linker has all the information necessary to create the global offset table for each object file and everything else needed to create a shared library?
Should I always use -fPIC for everything in the future as a default option, just in case something may be needed by a dynamic library some day?
I'm working on Linux on x86_64 currently, but I'm interested in answers about any platform.
You did not say which platform you use but on Linux it's a requirement to compile object files that go into your library as position independent code (PIC). This includes static libraries at least in practice.
Yes. See load time relocation of shared libraries and position independent code pic in shared libraries.
I only use -fPIC when compiling object files that go into libraries to avoid unecessary overhead.
So I'm trying to wrap my head around static and dynamic linking. There are many resources on SO and on the web. I think I pretty much get it, but there's still one thing that seems to bother me. Also, please correct me if my overall understanding is wrong.
I think I understand static linking:
The linker unpacks the linked libraries, and actually includes the libraries' object files inside the produced executable. The unresolved-stubs in the application object files are then replaced by actual function-calling code, which calls functions in addresses known at build time.
Dynamic linking on the other hand is what puzzles me more: I understand that in dynamic linking, the stubs in the object-code which reference yet-unresolved names, are going to stay as stubs until runtime.
Then at runtime, the dynamic loader of the OS would look through precompiled libraries stored at standard filesystem locations. It would look in the object-files of the libraries, inside their symbol tables (?) and try to find a matching function definition for each unresolved-stub. It would then load the matching object-files into memory, and replace the stubs to point to the function definitions.
So the part I'm missing is this: where does the OS dynamic loader look - does it look in the symbol tables for all object-files in the system-libraries directory? Or does it only look in object-files specified somewhere in the application-executable file? Is this the reason why at compile time we must specify all dynamic dependencies of our program? Also, is it true dynamic libraries expose a symbol-table too?
So the part I'm missing is this: where does the OS dynamic loader look
- does it look in the symbol tables for all object-files in the system-libraries directory?
No dynamic linker I'm aware of does this.
Or does it only look in object-files
specified somewhere in the application-executable file?
Nor exactly this, either.
Details vary, but generally, a dynamic linker looks for specific shared libraries by name in various directories. The directories searched may be built into the linker, specified by the operating system, specified in the object being linked, or a combination. The linker does not (generally) examine libraries' symbol tables until after it locates them by name and selects them for linking.
Is this the
reason why at compile time we must specify all dynamic dependencies of
our program?
Yes, though under some circumstances we do not need to specify all dynamic dependencies at compile time. Some dynamic linkers support on-demand dynamic loading as directed by the program itself. This can be used to implement plugin systems, among other purposes.
Also, is it true dynamic libraries expose a symbol-table
too?
Yes. Dynamic libraries have their own symbol tables because
The dynamic linker uses them to do its work, and
Dynamic libraries can have their own dynamic linking requirements, which are not necessarily reflected in the main program's.
In the normal usage, "dynamic linking" is performed by the loader. "Static linking" is performed by the linker.
Generally, linkers can create either executable files or shared libraries. The linker output for both is an instruction stream that tells the loaders how to place the executable or library in memory.
Dynamic linking on the other hand is what puzzles me more: I understand that in dynamic linking, the stubs in the object-code which reference yet-unresolved names, are going to stay as stubs until runtime
That is not [usually] correct. The linker will locate the shared library in which the symbol exists. The executable will have an instruction to find the symbol in that shared library. Linkers generally puke if they cannot find all the symbols that need to be resolved.
So the part I'm missing is this: where does the OS dynamic loader look - does it look in the symbol tables for all object-files in the system-libraries directory?
This a system specific question. In well designed operating systems, the shared libraries are designated by the system manager. The loader uses the library specified by the system. Poorly designed systems frequently use some kind of search path to find the shared libraries (which created a massive security hole).
I want to distribute a static library which consists of many source files and therefore, when compiled, consists of many object files. Within the object files there are some static functions and some functions which are not static. The non-static functions are needed because functions in one object file may need to be called from other objects.
I have one of the objects which is basically the API into the library and it has an associated header file which the application developer would include in their project in order to use the library. I want the symbols in that header file to be the only ones exposed to the application using the library.
I use IAR to compile my code into .a file, then include the public API header into my application and link the .a to my application.
The problem is that the non-static functions in my library which are supposed to only be called by other objects in the library are visible to the application using the library. This is an issue if the application tries to define a function with the same name as one of my library's functions (by accident, coincidence or intentionally). I cannot make every function static (and therefore visible to only their compilation unit) because then that function would be unusable to the rest of the library.
Basically I want to hide symbols from the application who is using the library.
I have a way to fix this in Keil already which works:
In Keil, I can do partial linking by actually linking my library using the flags
-ldpartial --privacy --no_locals --no_comment_section
and by providing a steering file through the option
--edit=steering.txt
to selectively choose what symbols I show and hide.
Example of a steering file:
HIDE *
SHOW my_public_func1
SHOW my public_func2
Is there any way to do this in IAR. I.e. is there a way to partially link a library and then link that library into an application.
What I have tried: https://www.iar.com/support/tech-notes/linker/hiding-symbols-from-a-library-using-isymexport-with-a-steering-file/
This is a good idea, but it requires loading my library separately onto the device when what I want to do is link it right into the application. Ideally, I would want to link the generated .out file from the above iar.com link into the application instead of loading it separately.
We know that when linking a static library, the linker copies the relevant code from .a file to the executable binary file. And when linking a dynamic library, the linker just copies the addresses of functions it found in .lib file (under Windows) into the binary file, and the functions themselves are not copied. At runtime, the OS loads the dll, and the program runs the code according to the addresses. The question is, could I use the .lib file and dll to link the dynamic library statically? The linker reads addresses from the .lib, and then copies relevant code from the dll to binary file. It should work, right?
I have no clue whether your idea could work, but do note that -- on Windows, with Visual Studio at least -- a static library is something very different from a DLL.
With VS, a static library is basically just an object file container, that is, you have a .lib file, but that .lib file is just a container for all the .obj files that the compiler produced for the project.
The important thing here is that the .objcode in the static library hasn't gone through the linking stage yet, no linker has been involved.
Whereas the DLL is (finally) produced by the linker (from object files).
So the question here is really one of toolchain support, since the DLL is already a linker output, I doubt you could get the linker to re-link its PE code directly into the executable.
If you want to link the .dll at build time instead of run time yes, it can be done using the .lib file that corresponds to the .dll. The exact method depends on what you are using to build your application.
In Visual Studio you start by adding the .lib file in Linker->Input on the project properties.
While this is static linking it does not copy the .dll code into your executable; you still need the .dll to run the application.
Additionally, if the .dll is something you developed and/or have the source code, it can be modified/rebuild as a static library and linked into your executable (so you will not have a separate .dll file).
I have an issue I don't know how to solve.
I have ever written a program (Python script) which returns a list of dynamic libraries with all the executables using them.
(My script uses the ldd utility).
Now, I'd like to do a program which would return a list of functions of dynamic libraries with all the executables using them.
But how can I do that ??
(I think the main problem is that libraries are build and to do that I need source code, right ?)
Thanks !!
JC
If you have ldd you should also have nm. This will list symbols in a binary, executable or shared object alike assuming symbols are included. This tool reports the function names indicating both local and external dependency information. You should be able to use this to do what you want.