* Carl-Daniel Hailfinger <[EMAIL PROTECTED]> [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...
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: [EMAIL PROTECTED] • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
