* Handling an elf kernel dump with a randomized base
@ 2016-02-09 15:37 Corey Minyard
2016-02-09 17:39 ` Corey Minyard
0 siblings, 1 reply; 2+ messages in thread
From: Corey Minyard @ 2016-02-09 15:37 UTC (permalink / raw)
To: Kexec Mailing List
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'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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Handling an elf kernel dump with a randomized base
2016-02-09 15:37 Handling an elf kernel dump with a randomized base Corey Minyard
@ 2016-02-09 17:39 ` Corey Minyard
0 siblings, 0 replies; 2+ messages in thread
From: Corey Minyard @ 2016-02-09 17:39 UTC (permalink / raw)
To: Kexec Mailing List
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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2016-02-09 17:40 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-09 15:37 Handling an elf kernel dump with a randomized base Corey Minyard
2016-02-09 17:39 ` Corey Minyard
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.