On 02/09/2016 09:37 AM, Corey Minyard wrote: > I have been working on getting kernels on different architectures with > randomized > base operational. One problem I've run into is that kernel dumps > taken this way are > not debuggable with gdb, the symbols are, of course, all in the wrong > places. > > The way gdb handles relocation is to add an AT_ENTRY value in an auxv > note. It holds > the relocated start address and gdb uses that to figure out the > offsets. This is > easy enough to add if you have the information, I'm wondering the best > way to do > this looking at getting it into the mainstream kernel and the crash > dump tools. > > There is some handling of this on x86_64 with KERNELOFFSET, but it > doesn't work for > gdb. > > I can think of two ways to add this: > > * Add a vmcoreinfo value with the entry point and have the extraction > tool create > the elf note. > > * Put the entry point in sysfs and have kexec add the note like it > does for > vmcoreinfo. > I thought of a third possibility. You could have a downstream tool that looks at the value of a symbol (like _stext) in the vmcoreinfo and the vmlinux file and adds the auxv note to the core dump. That would require no changes to anything, but would require the downstream tool. -corey > I'd like to avoid any solution that requires putting vmlinux or any > other large file > on the target system, as this is not always possible for small > embedded systems. > > Thanks, > > -corey
