[PATCH] kdump: relocatable kernel

[magnus.damm at gmail.com (Magnus Damm)]

Hi Jan,

On 7/6/06, Jan Kratochvil <lace at jankratochvil.net> wrote:
> On Thu, 06 Jul 2006 08:49:14 +0200, Magnus Damm wrote:
> > On 7/6/06, Eric W. Biederman <ebiederm at xmission.com> wrote:
> > > "Magnus Damm" <magnus.damm at gmail.com> writes:
> ...
> > > > I understand that it is possible to create a symbol that points to a
> > > > fixed address say mapping some hardware resource, but is that a
> > > > strategy currently used by Linux?
> > >
> > > Nope absolute symbols should not be changed in particular you will
> > > mess up the linux-gate.so and the like.
> >
> > I did some more research and it looks like I'm wrong. So absolute
> > symbols should be handled in a different way - I'll modify patches to
> > get that working.
>
> It is true some addresses must not be relocated. In 2.6.9 days it were the
> addresses detected by SAFE_FIXED_ADDRESS() in:
>         http://mkdump.cvs.sourceforge.net/mkdump/linux/scripts/reltab.c?view=markup&pathrev=linux-2_6-minik

Thanks for clarifying. I saw that you used the external utility
pointed out above to postprocess the relocations. I guess there were
several reasons behind that, but by performing the linking in the
kexec binary I was hoping to keep the kernel code as simple as
possible.

> > The absolute symbols we are talking about are the ones that could be
> > extracted from vmlinux with the following line, right?
> >
> > readelf -s vmlinux | grep ABS | grep -v FILE
>
> It would be the right way. Unfortunately in those 2.6.9 days this "flag" was
> broken in "vmlinux.lds.S" so Eric W. Biederman fixed it in the patch noted
> below so that your "grep ABS" would work properly:

Yeah, I've played around with Erics patch a bit and it seems to be the
right way to go. I tried extending it to x86_64 too, but binutils-2.17
seems b0rk somehow and it looks lite it reports relative symbols as
absolute sometimes.

> > > > > Eric had posted a patch in the past which made some the absolute symbols
> > > > > section relative.
> > > > >
> > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=112266670613361&w=2
>
> I did not fix it and workarounded it instead in my
>         http://mkdump.cvs.sourceforge.net/mkdump/linux/scripts/reltab.c?view=markup&pathrev=linux-2_6-minik
>
> just due to the project management issues - I just checked the referenced
> address range not looking at whether such reference was marked as being
> pointing to fixed or relocatable address.  I agree that technically speaking
> the right way is fixing "vmlinux.lds.S" as Eric W. Biederman did.
>
> (did not check which patches did / did-not get imported into which
> version/maintainer/vendor of Linux kernel)

Erics patch is not in mainline, that's for sure anyhow.

>
> Extracted some old mail explaining the fixed vs. relative addresses and the
> type ("PC-relative?") of relocation (according to the used instruction type):
>
> On Thu, 14 Jul 2005 03:12:10 +0200, lace wrote:
> ...
> > source        destination     PC-relative?    resolving
> > kernel-image  kernel-image    no              ADDITION
> > kernel-image  kernel-image    yes             none
> > kernel-image  fixed           no              none
> > kernel-image  fixed           yes             SUBTRACTION
> > fixed         kernel-image    no              ADDITION
> > fixed         kernel-image    yes             *** ADDITION *** (NOT SUBTRACTION!)
> > fixed         fixed           no              none
> > fixed         fixed           yes             none
> >
> > always: "kernel-image" address < "fixed" address
> >
> > fixed         kernel-image    yes             *** ADDITION *** (NOT SUBTRACTION!)
> > Although the referenced distance decreases, the negative relative address in
> > code is in binary complement and thus the relocation must be ADDITION to
> > decrease the distance (as in absolute value).
> >
> > Fortunately this type of relocation is not being used anywhere now.
> ...

Thanks for the information, it may become handy!

/ magnus