[LinuxBIOS] printk()/post_code(): Compile failure for all hardware targets in v3

[Stefan Reinauer]

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at 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...

 

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866