romcc quesiton

Eric W. Biederman ebiederman at lnxi.com
Wed Nov 10 12:46:01 CET 2004


"Ronald G. Minnich" <rminnich at lanl.gov> writes:

> On Tue, 9 Nov 2004, Eric W. Biederman wrote:
> 
> > A complex case would be fine.  With abuild.sh I'm not seeing any compile
> > failures.
> 
> weird! The digitallogic adl855pc won't build for me at all ...

I meant I was not seeing any new build failures.

My memory has it that the i855pm was one of the few ports that were never
completed, and had never built so I had filtered that one out.
 
> well, it will today. 
> 
> I deleted much lines of code and at some point it started to at least not 
> get errors, although I don't even get a POST code when it starts up :-(

raminit.c for that port has the same issues as the e7501 did.  In particular
it has unconverted assembly #if 0'd out.

Placing the unconverted assembly in strings, or simply commenting it out
will avoid the issue for now.

Next time can you an least give the me error message?
Having the string "unknown token" would at least have put me much closer
to knowing where to look.

Parsing but not compiling code inside an #if 0 is a totally different from simply
ignoring an #if 0.  Although I can see how it might not look differently.
If I had the error message at least I would have known where to look.

So currently we have found 3 quality of implementation issues
with romcc.
1) romcc tokenizes code inside an #if 0 and chokes on dollar signs '$'
2) romcc gets the line numbers wrong if you splice lines together with '\'
3) noninline functions don't always compile.

I will take a good hard look at the front end issues and see what I can
do.  It should be possible to fix those without making radical changes
to the rest of the code.

Eric



More information about the coreboot mailing list