[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1odv3vhaz.fsf@ebiederm.dsl.xmission.com>
Date: Tue, 01 Aug 2006 23:27:00 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Andi Kleen <ak@...e.de>
Cc: linux-kernel@...r.kernel.org, Horms <horms@...ge.net.au>,
Jan Kratochvil <lace@...kratochvil.net>,
"H. Peter Anvin" <hpa@...or.com>,
Magnus Damm <magnus.damm@...il.com>,
Vivek Goyal <vgoyal@...ibm.com>, Linda Wang <lwang@...hat.com>
Subject: Re: [PATCH 9/33] i386 boot: Add serial output support to the decompressor
Andi Kleen <ak@...e.de> writes:
>> > /* WARNING!!
>> > * This code is compiled with -fPIC and it is relocated dynamically
>> > * at run time, but no relocation processing is performed.
>> > * This means that it is not safe to place pointers in static structures.
>> > */
>
> iirc the only static relocation in early_printk is the one to initialize
> the console pointers - that could certainly be moved to be at run
> time.
The function pointers in the console structure are also a problem.
static struct console simnow_console = {
.name = "simnow",
.write = simnow_write,
.flags = CON_PRINTBUFFER,
.index = -1,
};
>> lib/string.c might be useful. The fact that the functions are not
>> static slightly concerns me. I have a vague memory of non-static
>> functions generating relocations for no good reason.
>
> Would surprise me.
The context where it bit me was memtest86, if I recall correctly.
The problem there was I did process relocations and I discovered simply
by making functions static or at least non-exported I had many fewer
relocations to process.
Since I am relying on a very clever trick to generate code that
doesn't have relocations at run time I have to be careful.
So if I want to continue not processing relocations.
I need to be careful not to use constructs that will generate
a procedure linkage table, which I think only kicks in with
external functions and multiple files.
I need to be careful not to put pointers in statically allocated
data structures.
Ideally the code would be setup so you can compile out consoles
the user finds uninteresting.
It is annoying to have to call strlen on all of the strings
you want to print..
So there are plenty of mismatches, there.
But we may be able to harmonized them, and reuse early_printk.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists