CODEWITHSUNDEEP
embeddedarmelfcoredump
s_o_c_r_e_t_e_z
s_o_c_r_e_t_e_z

Reputation: 53

Creating coredump for ARM based embedded system

I am basically following up on core dump note section. I didn't post that question but I am trying to do the same thing: write a program to create core dump file from scratch; except that I am trying to do that for a custom, single threaded firmware running on embedded ARM processor.

I am also referring to Google coredumper source to understand how corefiles are usually created. So far I have successfully created a core file with a PT_NOTE and a PT_LOAD program headers which is read by GDB.

Note that, I am trying to create this core file for a custom firmware and this is not Linux environment. My question is regarding PT_LOAD program headers. From what I understood, I just need to create as many PT_LOAD program headers as active threads (for which core needs to be created) with headers representing each thread's memory mappings. Since my firmware is single threaded, I created only one PT_LOAD program header with memory mapping being address values on stack.

When I load up ELF image of the firmware with this newly created core file, GDB prints registers accurately with "info reg". GDB also identifies PC (program counter) value and displays the symbol accurately. It, however, cannot display remaining frames from stack ("bt" doesn't work). It complains that it "Cannot access memory at address (SP+4)".

I've already provided firmware's stack mappings in the core file and GDB should have been able to read at address (SP+4). Note that, I can examine the value at (SP+4) with "x 0x(SP+4)".

Can anyone tell me what am I missing here?

Thanks

Upvotes: 3

Views: 3426

Answers (1)

s_o_c_r_e_t_e_z
s_o_c_r_e_t_e_z

Reputation: 53

I figured this out. Apparently, contents of the PT_LOAD program header - stack mappings - were not complete. The problem was that it needed entire mapping of the one thread that is running. After I included contents of entire CPU SRAM, GDB "bt" and all other commands worked just fine.

Also, from what I understood, the executable has address to all variables and core file has run-time values for those variables. So if any of the symbols are memory (RAM) resident then a separate PT_LOAD program header with RAM mapping should be added. After that GDB should be able to print runtime value of those variable accurately. Without the mapping, the value of the variable would be 0 (as shown by GDB).

Upvotes: 1

Related Questions