All of lore.kernel.org
 help / color / mirror / Atom feed
* 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.