cancel
Showing results for 
Search instead for 
Did you mean: 

How to either load the symbol table or combine ELF files?

mreed
Associate III

Working on the bootloader, it successfully downloads the binary, verifies it, programs it and jumps to it. But in the loaded application is crashing. 

Using System Workbench (Eclipse)

I had a similar problem a few years ago and I recall I loaded the application's symbol table in the debugger console, but I don't remember the commands and I have not yet found them on line.

I was also thinking: it would be a lot easier if I could simply load the bootloader and the application together as one with both symbol tables. But everything I've found for combining them removes the symbol table. And Eclipse will only let you load one ELF file.

Anyone have any ideas? 🙂

10 REPLIES 10

I don't know the answer to your question, but do you need the bootloader's symbols to debug crash in the*application*?

JW

No, I need the applications symbol table to debug a crash in the application.

Then load the application into debugger, leaving the bootloader as binary in FLASH.

JW

mreed
Associate III

When the application runs by itself, it runs just fine. But when it is branched to from the debugger is crashes.

If I load the application while the bootloader is in memory the debugger removes the bootloader.

mreed
Associate III

Figured it out. Go to the Debugger Console and enter the command "add-symbol-file <filename> <.text address>"

The hard part was figuring out the .text address. It's not the code entry point, it's the address just after the vector table.

My load address is 0x8008000, the vector table is 0xC0, so the .text address is 0x80080C0.

Would really depend on the section definitions in the linker script. Generally if you don't have the .MAP file to review, you could use objcopy or FromELF to dump/disassemble the content of the object file.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Thanks! Your right. It wasn't 0x80080c0, it was 0x80080e8. Found by looking at the map file! Probably because I put an information header just after the vector table. Makes sense.

mreed
Associate III

Just as a follow up, the bug was that, while the bootloader was resetting the Vector Table Relocation register the application was resetting it back to the bootloaders vector table.

> Just as a follow up

Thanks for coming back with the solution, to both this and the symbols problem. It probably applies to gdb generally I suppose.

> If I load the application while the bootloader is in memory the debugger removes the bootloader.

Remove such a debugger. 😉

JW