Hi, Greg. Sorry to bother you again.
I checked python API and found a path: SBDebugger -> SBTarget -> SBModule -> SBSection to retrieve data and text sections which need to be uploaded onto remote platform. The problem is I failed to figure out any method to perform uploading.
There is a python class named SBCommunication which I guess represents remote debug connection, but I was not able to find an accessor to obtain this object. Any clue?
With a bare metal GDB server implementation, I am guessing you are just going to have some predefined areas of memory mapped on your remote system and you will be able to attach with GDB remote and then just write memory. Is that the case? If so, you just grab the section data and write it down into areas of memory that are already mapped, and then you can just set the PC to the entry point of the program and run the image?
And Since there are lots of kinds of debug operations (like memory write, ...) prohibitted without a valid process, and program image is needed to launch a process, what is proper time to upload a image in your opinion?
You can connect to the remote GDB server and then write memory. If you don't have an OS running on the remote system, just have it pretend to have a process ID of 1, and threads for each core that you have. Then you could do:
% lldb foo.elf --arch x86_64-unknown-unknown
(lldb) gdb-remote localhost:1234
... <now you are connected to process 1 on your bare metal board> ...
(lldb) load_elf foo.elf 0x1000000
This is where you would have written a "load_elf" python script that will open foo.elf and grab the section data and write it to 0x1000000 in memory. The python script can also probably modify the PC to change to the entry point address within your newly downloaded foo.elf, set up the SP and FP and all other registers to know initial values...
Now you would be running
(I have faked a process in debug server after process launch and before image uploading and I force it to ignore the first continue/step packet, thus it stops immediately when it lauches. I guess it will work, but lldb displays ugly information at its first stop because memoey is all null.)
That is fine. I would keep going with that, or just make your remote system pretend to have a valid PC of something that is on a line like:
Does that make sense? With a bare board, you usually connect, setup memory with a config file (in this case it will be the "load_elf" python function) and then modify the PC to point where your entry point is, reset all registers to know values (like 0 for SP, FP, GPR regs, etc) and then continue.
You would do all of the connecting and uploading silently in your python script, so it could be:
(lldb) command script import /tmp/loader.py
(lldb) run_elf --gdbserver localhost:1234 --arch x86_64-unknown-unknown --load-address 0x10000 foo.elf
Then the "run_elf" could connect to the remote server, upload the ELF file, set the PC, init all registers and stop with the PC set to the entry point in the ELF file, and you would be ready to debug.