PowerPC kernels are fully relocatable and may be loaded at any memory address.
In order to resolve symbols properly, GDB must load the kernel symbol file relative to the base offset where it was loaded in memory.
Details
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 28078 Build 26223: arc lint + arc unit
Event Timeline
The relocation needs to be done a different way to support, e.g. remote debugging (e.g. attaching gdb to qemu's debug stub). Also, kgdb_main.c is just a simpler wrapper, and 'target vmcore /path/to/vmcore' in plain gdb should also work. I'll have to think about how this might be doable, but this approach is rather hacky. It also won't work for cross-debugging (examining a ppc vmcore on a non-ppc host which kgdb generally supports for other architectures). For PIE executables gdb relies on using the ELF auxv values to find the relocated binary.
Ok, I'm currently investigating how something similar to how gdb handles PIE files could be done.
So far I've found out that for both PIE and PPC kernel svr4_solib_create_inferior_hook() is called.
By forcing svr4_exec_displacement() to return the correct displacement of the kernel I was debugging, I've noticed that symbol resolution worked correctly.
So, it seems there are 2 main points to consider here:
- Find the most appropriate way to insert code that would make svr4_relocate_main_executable() work with FreeBSD PPC kernels
- Find a way to discover the load address of the kernel being debugged, even for remote targets
For remote targets, symbol resolution can be fixed by implementing qOffsets packet handling (D22767).