* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net [071120 17:44]:
On 20.11.2007 14:14, Stefan Reinauer wrote:
include/post_code.h specifies (because _SHARED is defined)
void stage0_post_code(u8 value) ; void (*post_code)(u8 value) = stage0_post_code;
Of course these definitions do conflict.
This issue seems trivial. include/console.h must not define a prototype for post_code. I wonder how that double definition sneaked.
Because simply deleting it causes compilation problems somewhere else?
So including post_code.h instead does not work? (Except the multiple definitions problem)
This is interesting. I never had any of these problems and I have been testing that code quite a bit. What distribution and what toolchain are you using?
openSUSE 10.3 (i386) gcc (GCC) 4.2.1 (SUSE Linux) GNU ld (GNU Binutils) 2.17.50.20070726-14 (SUSE Linux)
I think I used the 10.2 toolchain back then.
I tried to compile v3 with
gcc version 4.3.0 20071016 (experimental) [trunk revision 129378] (SUSE Linux) GNU ld (GNU Binutils) 2.18.50.20071002-5 (SUSE Linux)
and I get lot and lots of errors in other pieces of the code. It's a pity that gcc's understanding of what code is valid and what is not is so volatile between the minor versions.
My point was: For a given bootblock, we can't build the rest of the ROM based on the bootblock alone because it has been stripped of symbols.
Which is why I suggested a function pointer array with defined function pointers at fixed, defined offsets. Yes. This means we have to define an interface, something the Linux guys really hate.
I see no way around a function pointer array. However, we could avoid the fixed offsets if we use the same technology the Linux kernel uses for its symbol tables.
What's the benefit? We don't have all the space available that Linux freely consumes these days. Especially not if people want to use LAP
The Amiga did a very similar thing. All functions in a shared library would be available through a function pointer array. The callable functions would be defined through the library version. So a program could always react on finding a too old or not-existing library sanely instead of just spitting out a linker error like our unix/elf based systems do these days.
That's probably overkill.
A lot simpler than what Linux does.
Suggestions for solving the problems mentioned above:
- Always wrap shared function definitions in SHARED macros.
yes. this is how it should be done.
Can you prepare a patch?
I'll try, but it will be a couple of days/weeks.
- Make sure the assignment "ret (*func)(args) attr= stage0_##func"
happens only once per final linked object.
That will get messy. Maybe move the assignment to a separate object which is linked to the final object?
Yes. the macro nature of that code should make that simple.
Isn't there something like extern inline?
Can we recreate an object file from the map file? Or can we avoid stripping all symbols from stage0/1?
Nope, and nope, unfortunately. The unstripped bootblock is an ELF file, but we need a binary blob there, so we have the reset vector and such in the right place...