Here is a proposal for supporting pic etc. without too much hardship.
we create a file, include/lib.h, and move all prototypes to that file. That file is included by non-pic code, and has declarations like this: int printk(int level, char *format, ...);
We create another file, call libpic.h, and it looks like this: int (*printk)(int level, char *format, ...) = stage0printk;
PIC programs include libpic.h. non-PIC programs include lib.h.
At build time, for PIC programs, we use that little trick I showed earlier to create a stag0_pic.o with symbols renamed, e.g. printk becomes stage0printk.
non-PIC programs (e.g. stage2) link against stage0.o as they do now. PIC programs link against stage0_pic.o.
This will work; is it acceptable?
ron
On Wed, Aug 29, 2007 at 02:36:31PM -0700, ron minnich wrote:
Here is a proposal for supporting pic etc. without too much hardship.
we create a file, include/lib.h, and move all prototypes to that file. That file is included by non-pic code, and has declarations like this: int printk(int level, char *format, ...);
We create another file, call libpic.h, and it looks like this: int (*printk)(int level, char *format, ...) = stage0printk;
Please don't use stage0 to tag the PIC code, use pic instead. stage0printk would become picprintk, or maybe pic_printk.
PIC programs include libpic.h. non-PIC programs include lib.h.
At build time, for PIC programs, we use that little trick I showed earlier to create a stag0_pic.o with symbols renamed, e.g. printk becomes stage0printk.
I would like that file to be called just pic.o and be unrelated to anything stage0 - except of course that stage0 calls the code in pic.o.
non-PIC programs (e.g. stage2) link against stage0.o as they do now. PIC programs link against stage0_pic.o.
This will work; is it acceptable?
I think the method is great but I want to choose all filenames carefully so it is really clear what is going on.
Btw - why couldn't everyone call the PIC functions?
//Peter
I am confusing you, maybe.
stage0 is not pic. stage0 is non-pic. initram is pic. initram, which is pic, needs to call stage0, which is not pic.
To add to the fun, stage0 does make one call to initram: it calls initram's main.
On 8/29/07, Peter Stuge peter@stuge.se wrote:
Please don't use stage0 to tag the PIC code, use pic instead. stage0printk would become picprintk, or maybe pic_printk.
this implies to me that the printk itself is pic, which it is not. Another name?
I would like that file to be called just pic.o and be unrelated to anything stage0 - except of course that stage0 calls the code in pic.o.
except that file IS stage0.o. It's stage0 with all the symbols renamed. What do we call them?
I think the method is great but I want to choose all filenames carefully so it is really clear what is going on.
Btw - why couldn't everyone call the PIC functions?
stage0 is not pic. If we make it pic, it ballons. When gcc generates PIC code, it still generates relative calls. Gcc is not tremendously good at generating PIC, what it really creates is "PIC assuming you use the GNU shared library techniques".
ron
On Wed, Aug 29, 2007 at 03:25:41PM -0700, ron minnich wrote:
I am confusing you, maybe.
Yeah. :)
stage0 is not pic. stage0 is non-pic. initram is pic. initram, which is pic, needs to call stage0, which is not pic.
Did you rule out the possibility of having the functions in stage0 that need to be called from initram in a separate file, making them all PIC and calling them from CAR, PIC and stage2+ alike?
Would that require the pointer trick for each function in all the files where they're called? :\
Please don't use stage0 to tag the PIC code, use pic instead. stage0printk would become picprintk, or maybe pic_printk.
this implies to me that the printk itself is pic, which it is not.
Good point.
Another name?
Can't come up with anything good right now.
Btw - why couldn't everyone call the PIC functions?
stage0 is not pic. If we make it pic, it ballons.
Sorry, balloons? You mean it grows huge or just blows up == doesn't work?
When gcc generates PIC code, it still generates relative calls.
Isn't that (part of) the definition of PIC?
Gcc is not tremendously good at generating PIC, what it really creates is "PIC assuming you use the GNU shared library techniques".
:(
//Peter
On 8/29/07, Peter Stuge peter@stuge.se wrote:
Did you rule out the possibility of having the functions in stage0 that need to be called from initram in a separate file, making them all PIC and calling them from CAR, PIC and stage2+ alike?
Would that require the pointer trick for each function in all the files where they're called? :\
yes. You CALLER would still need to use the pointer trick.
Another name?
Can't come up with anything good right now.
I'm counting on you :-)
stage0 is not pic. If we make it pic, it ballons.
Sorry, balloons? You mean it grows huge or just blows up == doesn't work?
grow from 4k to very large.
When gcc generates PIC code, it still generates relative calls.
Isn't that (part of) the definition of PIC?
Sort of. I need relative for initram, but I need abs calls to the stage0 code. How do I get this?
example: [rminnich@xcpu tmp]$ cat a.s .file "a.c" .text .globl a .type a, @function a: pushl %ebp movl %esp, %ebp pushl %ebx subl $4, %esp call __i686.get_pc_thunk.bx addl $_GLOBAL_OFFSET_TABLE_, %ebx call b@PLT addl $4, %esp popl %ebx popl %ebp ret .size a, .-a .ident "GCC: (GNU) 4.1.2 20070502 ( Red Hat 4.1.2-12)" .section .text.__i686.get_pc_ thunk.bx,"axG",@progbits,__i686.get_pc_thunk .bx,comdat .globl __i686.get_pc_thunk.bx .hidden __i686.get_pc_thunk.bx .type __i686.get_pc_thunk.bx, @fun ction __i686.get_pc_thunk.bx: movl (%esp), %ebx ret .section .note.GNU-stack,"",@ progbits [rminnich@xcpu tmp]$ cat a.c a(){ b(); } [rminnich@xcpu tmp]$
note the call to b. It ends up being relative jmp. We need it to be abs when calling stage0 ...
ron
Hi Ron,
maybe it would make sense to include your mail almost verbatim in newboot.lyx. IIRC newboot.lyx seemed to suggest a different code flow.
Carl-Daniel
On 30.08.2007 00:25, ron minnich wrote:
I am confusing you, maybe.
stage0 is not pic. stage0 is non-pic. initram is pic. initram, which is pic, needs to call stage0, which is not pic.
To add to the fun, stage0 does make one call to initram: it calls initram's main.
On 8/29/07, Peter Stuge peter@stuge.se wrote:
Please don't use stage0 to tag the PIC code, use pic instead. stage0printk would become picprintk, or maybe pic_printk.
this implies to me that the printk itself is pic, which it is not. Another name?
I would like that file to be called just pic.o and be unrelated to anything stage0 - except of course that stage0 calls the code in pic.o.
except that file IS stage0.o. It's stage0 with all the symbols renamed. What do we call them?
I think the method is great but I want to choose all filenames carefully so it is really clear what is going on.
Btw - why couldn't everyone call the PIC functions?
stage0 is not pic. If we make it pic, it ballons. When gcc generates PIC code, it still generates relative calls. Gcc is not tremendously good at generating PIC, what it really creates is "PIC assuming you use the GNU shared library techniques".
-
Carl-Daniel Hailfinger -
Peter Stuge -
ron minnich