I am currently working with some µC systems and I'd like to go deeper into detail to understand what is going on beneath.
I am currently working with a Motorola Coldfire and an ARM 9. For both I am using the GCC toolchain as a cross compiler!
ELF files contain more information than needed to get the application run! A BIN file would be enough though! I know the ELF format keeps some extra information. it concatenates symbols and their addresses in memory, right? Are the extra information for the software debugger (e.g. GDB) only or are some of theses information transfered to the target device as well? So if there is a breakpoint hit, the on-chip debugger tells the host the regarding address and the software debugger can show me the relevant code section instead of the boring memory address only?
Can I debug using a BIN file only (Ok this would be stupid, but basically?)?
Some enlightenment regarding this topic is appreciated!
thynk you
You are right that ELF files contain extra information, such as symbols used for debugging. Typically in a µC environment, you will use the BIN file to execute on the processor (usually loaded into flash) and then you would pass the ELF file to GDB for debugging. When running the cross-compiled GDB on your development PC, it will use the ELF file for reference (so it knows code line numbers, variable names, etc.) but it will communicate with the on-chip debugger to read memory locations, set breakpoints, etc. To get GDB to communicate with the on-chip debugger, you use the target remote command in GDB, passing it whatever parameter is necessary (often a serial port of network address & port).
Related
I searched a lot a bout this question and I did not find any clear answer yet.
As you know, AVR microcontrollers e.g. Atmega128 have a Flash memory which can be divided into Bootloader and Application memory. I've adjusted the parameters of each one and loaded my boot and application load. Is there any way (using code or from terminal) to know the exact size of each memory and the available bytes????
Some people may be mention avr-size command. This command give me the size of the whole flash memory. I want to distinguish between boot and application memory.
Thanks in Advance
You have two firmwares, the bootloader and application, each will have its own size.
For each build, add the linker flag to your linking command line -print-memory-usage to make it print how much flash and RAM is used.
(This flag is not supported by every tool-chain, but AVR might support it)
More info: https://stackoverflow.com/a/41389481/2002198
Or, you can get the memory usage with avr-size:
avr-size -C --mcu=atmega168 project.elf
Reference: http://www.avrfreaks.net/forum/know-code-size-and-data-size
There's other detail you have to be aware: Depending the way you are loading your application (flash writing vs bootload loading) you will align the application with FLASH blocks (usually 2 kibs). Depending the way you are doing you will have smaller available flash memory to the application.
Just read the manual:
The actual address of the start of the Boot Flash section is deter-
mined by the BOOTSZ fuses
and you will find your answer.
If you have already built your bootloader then you should be able to tell how big it is either by looking carefully at the steps you performed to build it, or by examining the HEX file for the bootloader. The HEX file says exactly what addresses the code in it are written to.
I have seen a document here http://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file. This example is all about crash seen in Windows file? I am looking for the same mathematics that has been done here for the crash generated on Linux systems. If I get the crash on Linux, then how will I debug the issue in the similar lines like Microsoft document http://www.codeproject.com/Articles/3472/Finding-crash-information-using-the-MAP-file. Please help?
Is load address and the code segment address are same in Linux? what is the following in Linux as mentioned in the link "The first part of the binary is the Portable Executable (PE), which is 0x1000 bytes long."?
PE is windows format. Linux uses ELF. Of course you can parse ELF manually, but you shouldn't - gdb could do that for you. Even more, you can use addr2line utility to map address to file/line in source code (of course both of these will require debug build).
Map files are rarely used in linux - it usually just a part of debug executable. It could be dumped from debug build, however, but it don't have too much practical value.
Also, take a look at How to use addr2line command in linux
I am developing an operating system from scratch for ARM processors in c and assembly. I have finished the kernel and I am beginning to start the userspace (an evironment where applications can be run). I am going to have my applications programmed in C and compiled in gcc.
How can I have gcc compile the .c files in such a way that they are compiled so they come out as a specific file format (ex. .app, .exe, .apk, .ipa)
How can the operating system run the file? By this I mean, when the user selects the application from the List of apps how will the operating system interact with the file and tell the application "The app is open call OnApplicationOpen()"?
P.S. Also sorry how the question was phrased. It was difficult to explain
1) 'come out as a specific file format' - usually, the linker does that. Look at your linker options.
2) I don't know - it's your OS! Basically, inspect the executable header to find out what resources are required, allocate them, read in the sections that need to be loaded, zero those sections that need to be zeroed, relocate sections that need to be relocated, find the code start address, create a thread to run it.
I've been following the "Mike OS Guide" to make my own kernel, and I got it working. But then I went onto the many guides on the internet for making a boot sector in NASM that loads a main function from a compiled C object. I have tried compiling and linking with all kinds of GCC installations:
x86_64-pc-linux-
arm-uclinux-elf-
arm-agb-elf-
arm-elf-
arm-apple-darwin10-
powerpc-apple-darwin10-
i686-apple-darwin10-
i586-pc-linux-
i386-elf-
All of them fail once I put them onto a floppy like I do with the MikeOS bootstrap. I've tried various tutorials on http://www.osdever.net/ like the one here and I've tried http://wiki.osdev.org/Bare_Bones , but none work when trying to compile on a Mac, yet I have not tired on an actual Linux machine yet. But I was wondering how I could get a bootstrap in assembly the calls the C function and put them together into a working kernel file and then load the onto a floppy file then onto an ISO like in the MikeOS tutorial. Or should I just make the kernel.bin and load it with syslinux? Could anyone give me a tip on how to make this all work on a Mac developement environment? I have tolls via macports and homebrew so that helps. Anyone successively done this?
EDIT
Here's my bootsector so far.
I just wanna know how to jump to an extern function from the C and link it.
There's a few problems with this. First of all, all the compilers you mentioned output either 32-bit or 64-bit code. That's great, but when the boot sector starts, it's running in 16-bit real mode. If you want to be able to run that 32-bit or 64-bit code, you'll need to first switch to the appropriate mode (32-bit protected mode for, well, 32-bit, and long mode for 64-bit).
Then, once you switch to the appropriate mode, you don't even have that much space for code: boot sectors are 512 bytes; two bytes are reserved for the bootable signature, and you'll need some bytes for the code that switches to the appropriate mode. If you want to be able to use partitions on that disk or maybe a FAT filesystem, take away even more usable bytes. You simply won't have enough space for all but the most trivial program.
So how do real operating systems deal with that? Real operating systems tend to use the boot sector to load a bigger bootloader from the disk. Then that bigger bootloader can load the actual kernel and switch to the appropriate mode (although that might be the responsibility of the loaded kernel — it depends).
It can be a lot of work to write a bootloader, so rather than rolling your own, you may want to use GRUB and have your kernel comply to the Multiboot standard. GRUB is a bootloader which will be able to load your kernel from the disk (probably in ELF format) and jump to the entry point in 32-bit protected mode. Helpful, right?
This does not free you from learning assembly, though: The entry point of the kernel must be assembly. Often, all it does is set up a little stack and pass the appropriate registers to a C function with the correct calling convention.
You may think that you can just copy that rather than writing it yourself, and you'd be right, but it doesn't end there. You also need assembly for (at least):
Loading a new global descriptor table.
Handling interrupts.
Using non-memory-mapped I/O ports.
…and so on, not to mention that if you have to debug, you may not have a nice debugger; instead, you'll have to look at disassemblies, register values, and memory dumps. Even if your code is compiled from C, you'll have to know what the underlying assembly does or you won't be able to debug it.
In summary, your main problem is not knowing assembly. As stated before, assembly is essential for operating system development. Once you know assembly thoroughly, then you may be able to start writing an operating system.
First of all, I cannot use a debugger[1]. But I can access the Program Counter of a program, and can also compile the binary (written in C) with all the flags I need. And I can even change the code (although I prefer not to). Given a PC I want to be able to know which line it corresponds.
I'm sure there has to be an automated, practical, quick way to do this. But I haven't succeeded.
Edit: Forgot to mention: Linux system, binaries are PPC, host is i386. I do have access to PPC hardware.
[1] The application is being emulated, and it is cross compiled, I have a gdb in the host emulator. But I cannot connect a gdbserver on the emulated guest application. And real hardware is not an option, I'm trying to build a simulator based on the emulator.
If the binary is compiled with debugging information, then you can use the PC to find the right location in the source by groping through the ELF sections that contain the debug information. Automated, quick and practical aren't the terms that spring to mind for the process, though!