Due to a bug in ld I need to copy an ELF section from one object file to another. I can dump the desired section to a file but the problem is that objcopy's --add-section option expects a binary file and the section type information is therefore lost. As far as I can tell I cannot set the type of a section using binutils but I'm hoping I'm wrong :)
I can edit the binary manually to set the section type and that
solves the underlying problem, but I'm curious as to whether there's a solution based on standard tools.
For the curious the underlying problem is that when GNU ld links an
ARM object file without the .ARM.attributes section (such as a file
with just a binary blob living in its own section) it picks some
default that causes it to generate invalid veneers to RAM-functions
even when the files containing the calls have good .ARM.attributes
sections. The only solution (pending
https://sourceware.org/bugzilla/show_bug.cgi?id=11897) that I can come up with is to add a .ARM.attributes section to the binary-blob object file. However, that only works if the .ARM.attributes section has the type ARM_ATTRIBUTES.
Related
I have to relocate an elf at runtime and so I want to have access to all the relocations emitted by the linker: hence the use of the --emit-relocs ld option. The thing is I want to group all the .rela.* sections into one .rela.dyn section in the linker script and then go through this only section to relocate all the symbols.
But I can't get my linker script to achieve this, I still see a lot of .rela.* sections in the final elf and not the output section .rela.dyn. The following is what I used in the linker script and actually is simply copied from another architecture linker script that works but that does not use --emit-relocs:
.rela.dyn : ALIGN(8) {
*(.rela .rela*)
}
Does the --emit-relocs option 'bypass' the linker script ? Or did I simply miss something ?
Thanks,
Alex
Can somebody explain what the GNU ld option --undefined does?
Working on a LiteOS project. The app is linked with many -u options. For example -utask_shellcmd.
The GNU linker manual for --undefined=symbol simply says:
Force symbol to be entered in the output file as an undefined symbol. Doing this may, for example, trigger linking of additional modules from standard libraries.
So the symbol will be included in the output file as an undefined. What if the symbol is already defined in one of the linked obj files? If it is really undefined, when the linking of additional modules will happen and how does that happen?
The -u option is only relevant when archive (.a) libraries are involved (maybe also .so libraries with --as-needed in effect).
Unlike individual object files (.o) on the linking command line, which are all linked in the order in which they appear, object files from an archive library are only linked when they satisfy one or more undefined symbol references at the point they appear in the link command line order. Once once .o file from the archive is pulled into the link, the process is repeated recursively, so that if it introduces more undefined symbol references, other object files from the same (or later) archives will be pulled in to satisfy them.
Using -u allows you to cause a particular symbol (and, indirectly, all dependencies of the object file it was defined in) to be pulled into the link. Of course you could just put all .o files on the command line directly, without using any archive libraries, but by using libraries you can avoid linking unused object files (this is especially useful if large parts of the code may be unused depending on build-time-configurable settings in other files!) while getting the ones you need.
I'm using IAR toolchain to compile few source files and then link generated .o files.
However, I'm running into linking errors like below:
Error[Li005]: no definition for "main" [referenced from cmain.o(rt7M_tl.a)]
Error[Lc036]: no block or place matches the
pattern "ro code section .intvec in vector_table_M.o(rt7M_tl.a)"
As I understand, ILINK linker is trying to link object files as an executable image and in the process adding dependencies from standard libraries[ i.e looking for main() and interrupt vector table ].
What I'm looking for :
How to configure linker to not to add these system-library dependencies like main/start/interrupt-vector-table etc. ?
How to configure linker to output a non-executable image from bunch of object files - if that at all is possible ?
You can think of this non-executable image sort of configuration-table image which will be put in persistent memory to be read/write by main application image.
If you tell the linker that you don't have an entry point with the command line option '--no_entry' you will get rid of the reference to main and the .intvec data.
However you do need to tell the linker what it should keep.
--keep and/or __root can help you with that.
I am reading xv6 lectures.
I have a file named initcode.S that is to be linked in the kernel.
Now two symbols are created that way :
extern char _binary_initcode_start[], _binary_initcode_size[];
inside a function.
The lecture says :
as part of the kernel build process, the linker embeds that binary that defines two special symbols, _binary_initcode_starcode_size, indicating the location and size of the binary.
I understand that binutils is getting the address and the size of this assembled code.
I wonder about the notation : is it default ? my searches didn't prove that clearly.
_binary -> it is originally an assembly code
_initcode -> the name of my file
_start -> the parameter i am interested in.
It would imply that any assembly code compiled would have those variables too.
I have no proof of that, though.
The question is :
is _binary_myAsmFileHere_myParameterhere the default variable structure binutils give to the assembly file to export their address, size and so on ?
Could someone tell me if my assumption is right and if it is better than that : the rule
Thanks
Strangely enough, it doesn't seem to be documented in the ld manual. However, man objcopy does say this:
You can access this binary data inside a program by referencing the
special symbols that are created by the conversion process. These
symbols are called _binary_objfile_start, _binary_objfile_end and
_binary_objfile_size. e.g. you can transform a picture file into an object file and then access it in your code using these symbols.
Apparently the same logic is used by ld when embedding binary files.
Notice that the Makefile for xv6 contains this line for linking the kernel:
$(LD) $(LDFLAGS) -T kernel.ld -o kernel entry.o $(OBJS) -b binary initcode entryother
As you can see, it uses -b binary to embed the files initcode and entryother, so the above symbols will be defined during this process.
when a .global variable is defined in an assembly file, for a C file to be able to reference that variable, the C file has to prepend a '_' to the variable name. This is so the linker can 'link' the name in the C file with the name in the assembly file.
I'm looking for a convenient way (for use in a build testing script) to query individual symbols in an object file. Is there a tool that can answer the question (preferably by its exit status) "does symbol X exist in file Y?" or do I just need to parse the output of nm(1), e.g. with grep and an appropriate regex? Even better would be if such a tool could give detailed information on the symbol (size, type, value, ...).
For an executable/shared library, give readelf or Objdump a look over, they can dump a binaries symbols (mangled or unmangled), which you should be able to grep.
Their source is easily obtainable, so you could probably taloir them down into simpler tools for the task at hand or directly import their code base (not that you really need to, you could just load the binary with in question with dlopen and use dlsym to check if the symbol is there).
Objdump is geared towards binaries, nm and readelf will read elf object files.
You could use libbfd directly, but glancing through the API it isn't obvious how to get straight to the information you want.