I have created some special sections in a linked file and I want them to be in separated segments to have different page permissions.
In linker script, PHDRS command can specify segments in linked file. However, as the document says, PHDRS will create no default-defined segments other than specified in the command. And I found no PHDRS command in ld --verbose output.
Is there any way to keep the default ones? Or what is the default specifications of segments so I can write them in my own linker script?
Came across this when looking for similar answers. It's late, but someone else might come across it. To get the currently used linker script you can use gcc -Wl,--verbose ... or ld --verbose ... when linking, which will dump the script (and a bunch of other stuff) to stdout. As far as I'm aware, there is no way to keep the default program headers and just append an entry to them without writing a custom script to parse the output of the above. If you want to add a section on the other hand, apparently there's a trick with objcopy --add-section that allows you to add a section to an existing elf file.
Related
Having built my application, initially using debug, I now move to make it production ready. I have changed my compile options from
-c -W"c,debug,LP64,sscomm,dll"
to
-c -s -W"c,LP64,sscomm,dll"
which reduces the size of the resultant executable to 60% of the debug version.
I changed my link options from
-W"l,LP64,DYNAM=DLL"
to
-s -W"l,LP64,DYNAM=DLL"
which further reduces the size of the resultant executable to 20% of the original debug version.
So it certainly seems to be doing something. But when I view the executable, I can still see all the function name eye-catchers in the executable, and when I force an abend, the CEEDUMP generated still shows all the function names in that file. I expected -s to remove all symbolic information.
So my question is "how do I remove all symbolic information?"
In addition, once linked with -s I can no longer copy the module to an MVS dataset, from the USS file where it is generated. I use the following command:-
cp -X prog "//'ME.USER.LOAD(PROG)'"
which fails with:-
IEW2523E 3702 MEMBER *NULL* IDENTIFIED BY DDNAME /0000002 IS NOT AN EDITABLE
MODULE AND CANNOT BE INCLUDED.
IEW2510W 3704 ENTRY OFFSET 0 IN MODULE *NULL* IDENTIFIED BY DDNAME /0000002
DOES NOT EXIST IN A VALID SECTION.
cp: FSUMF140 IEWBIND function "INCLUDE" failed with return code 8 and reason code 83000505
This error message seems to say that I need the EDIT linkage option, but if I add that in, it appears to negate the step of using -s on the link, as the size goes back up to 60% of the debug version size.
So my second question is, "how do I copy the file to an MVS dataset and also remove symbolic information?"
Maybe there is a subsequent step that I can take to drive the binder again to remove symbolic information from the USS file and from the MVS dataset after the copy?
You can use COMPRESS compiler option and to some extent COMPACT. The COMPRESS option will suppress emitting function names in control blocks, while the COMPACT option will influence the compiler optimization choices to favor smaller object size.
Even though you are compiling and linking your executable in USS, you do not need to produce the executable in USS and then copy it to a data set. You can put your executable straight into the data set by using -o "//'ME.USER.LOAD(PROG)'" syntax. Just make sure your output data set is a PDSE.
Since you are compiling and linking in USS, you should use the xlc utility with -q syntax for compiler options as this syntax avoids the use of parenthesis which have special meaning in shell.
Is it possible to use a linker script or mapfile to rename a symbol?
I'm trying to adapt some code written in a mix of C++ and Fortran so that it will work with more than one Fortran compiler - on Linux. It is currently written for the Solaris Studio compiler with the option for case-sensitivity enabled. I'd like to handle variations in Fortran symbol name mangling automatically (such as from the Makefile).
It does appear to be possible to create aliases so, a linker script containing:
C_Function_ = c_function;
will sort-of work. Unfortunately, adding the -T option to reference this script causes some other change in behaviour and I get errors due to libdl.so.2/librt.so.1 not being found. Is there some sort of default linker script that I need to include or something? I've tried with both bfd and gold linkers on Linux.
You cannot really rename symbols, but you can define aliases to existing symbols like
PROVIDE(c_function = C_function_);
...
in a linker script.
If you pass this linker script with the -T option to ld, it will replace the original (default) linker script. If you rather want to have the linker script extend the default, pass it without the -T option (just like you would with an additional object file).
This way, everything should work as expected.
The -T command to the GCC linker replaces the default linker script.
But I don't want to replace the default linker script.
I want to append my new section definitions to the existing default linker script.
How to add new memory sections to the default linker script?
I don't think there is a direct way to do what you want to.
What you could do though, is to have ld print the default script file (with -Wl,-verbose, the section between ===============s is the linker script), put it in a file, modify the file with your additions and finally feed this to your link command as the linker script.
It should be fairly easy to write a script that does this and integrate it in your build scripts.
Using IAR IDE for building ARM executables from C source, I can see the disassembly, including labels, addresses, opcode and instructions in the relevant window.
I am trying to dump the contents of a range of addresses to a text file, but can't find a way to do that. The window text is not selectable so I cannot use copy/paste. There is no menu associated that enables this.
As an alternative, I can generate the list and assembly files, but these seem to be limited to my code, and do not contain the CRT code or any ROM sections, which I am interested in.
Any way to dump a selected address range?
You want to use ielfdumparm located in your Workbench directory under arm/bin. Here's the help for the tool.
Usage: IElfDump input_file [output_file]
Available command line options:
--all Dump all sections
--code Dump only code sections
--no_header Do not produce a list header
--no_rel_sections
Do not output associated .rel sections
--no_strtab Do not include strtab sections
--output file
-o file Name of text file to create
--raw Use raw text format
--section #|name[,...]
-s #|name[,...] Dump only section(s) with given numbers/names
--source Include source in disassembled code in executables
--use_full_std_template_names
Don't use short names for standard C++ templates
-a All sections, except strtab sections
-f file Read command line options from file
To get a similar output to the debug view, I would suggest --code to avoid dumping your data space, and --source to have it embed your original C woven in with the assembly.
You can specify sections, but it doesn't look like you can specify address range. You may be able to pair this with some of the other ELF tools to extract just a specific address range, and then run this tool on that. Alternatively, this dumps in address order so you could dump the entire ELF file and then just look at the address range you want after the fact.
I use Snagit to capture text that is not selectable.
Snagit is a screen snapshot tool (a very good one). Besides making classic screen shots it supports to capture text and save it as ASCII text. It can also automatically scroll windows to capture long texts.
Maybe it is worth a try. There is a 30-day trial version available.
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.