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.
Related
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.
I have builded the U-boot for minnowboard max. I am seeing the files like uboot.rom uboot.bin etc.
what is the difference between uboot.rom and uboot.bin ? Which files I should flash to SPI NOR flash.
This is explained in doc/README.x86. In short, if you are going to be writing U-Boot to SPI NOR then you need to ensure that you have the correct binary blobs in the correct locations AND use BUILD_ROM=y so that u-boot.rom is generated as this is the file that is required on x86 to run on bare metal (rather than say as a coreboot payload).
Edit to address the comment:
The file 'u-boot' is the ELF object that is the result of building all of the U-Boot sources and linking them. This includes all of the extra sections and information an ELF file can contain. This is also by and large not bootable. The u-boot.bin file is the ELF u-boot but passed via objcopy to strip out (by and large, see the Makefile for the various flags or build with V=1) everything except for text/data sections so that we have only what is required to boot. Then u-boot.rom is the combination of objects and formatting that the x86 architecture requires in order to execute and run an image. Building with V=1 will show all of the details here.
This may be compiler specific, in which case I am using the IAR EWARM 5.50 compiler (firmware development for the STM32 chip).
Our project consists of a bunch of C-code libraries that we compile first, and then the main application which compiles its C-code and then links in those libraries (pretty standard stuff).
However, if I use a hex editor and open up any of the library object files produced or the final application binary, I find a whole bunch of plain text references inside the output binary to the file paths of the C files that were compiled. (eg. I see "C:\Development\trunk\Common\Encryption\SHA_1.c")
Two issues with this:
we don't really want the file paths being easily readable as that indicates our design some what
the size of the binary grows if you have your C-files located in a long subdirectory (the binary contains the full path, not just the name)...this is especially important when we're dealing with firmware that has a limited amount of code space (256KB).
Any thoughts on this? I've tried all the switches in the compiler I can think of to "remove debug information", etc., but those paths are still in there.
"The command-line option --no_path_in_file_macros has been added. It removes the path leaving only the filename for the symbols FILE and BASE_FILE."
It is defined in the release notes if IAR.
http://supp.iar.com/FilesPublic/UPDINFO/005832/arm/doc/infocenter/iccarm_history.ENU.html
Or you can look for FILE and BASE_FILE macros and remove it you do not want to use the flag.
I need to do some Trace32 debugging and i need to see the symbols of the IFS image.
I generate the IFS image for my ARM A9 platform but dont know how to generate the ELF file.
can somebody help me out ?
thanks.
IFS is a file system with many binaries and scripts. For trace32, when you try to debug any process (including procnto), you'd need the symbols of that process of interest. There is not such thing as ELF for IFS. It's like asking for the ELF of your harddisk.
Use dumpifs. Example:
dumpifs shell.ifs
check this
the -x option can extract the files specified after the image.
I have a program which compiles and runs scripts.
To create a standalone version of the script, I reserve a large static buffer to hold the compiled script. The compiled script is copied into a copy of the program and it can then be run from that copy.
This works fine. It has some disadvantages however:
the buffer is static and takes up space if there's no compiled
program in it.
if the script to be included exceeds the buffer's size, I need to build a new version with a larger buffer.
I'd like to add the compiled script to the end of the program, but naively doing so doesn't work as the exe loader chokes on the new file size.
Is there a way to manipulate the exe so it would be acceptable for the loaders (mind this is a cross platform program)?
would be acceptable for the loaders (mind this is a cross platform program)?
I would think that this is unlikely to be possible without being platform specific. Time for a common interface with different implementations (so the code that saves/loads the script is common, but the executable manipulation is specific).
On Windows you'll hit the problem that a running executable file is locked against modification. By working on copies this can be worked around (but the only way to rename back in a completely deterministic way it is perform the move on boot, but scheduling a job might be acceptable).
On Windows the easiest way to add data to an image (executable or dll) is using resources. Define a custom resource type and add into the image (UpdateResource function) and later retrieve with LoadResource.
You said "script", so I suppose you have a separate file containing the script (a text file?). You could write a simple program that reads the script file and convert it in a compilable form (e.g. a C source containing the initialization of an array of byte). There are also tools you can use to convert an arbitrary file into a linkable object (.o or .obj). In the past I have used the command "objcopy" from GNU bimutils. In particular, on linux:
objcopy -I binary -O elf32-i386 mydata mydata.o
This command creates an object and three public symbols you can use to find the start, the end and the size of your data block:
_binary_mydata_start
_binary_mydata_end
_binary_mydata_size
Something similar may work also on Windows, provided that you install a Windows version of GNU binutils (e.g. cygwin).