RE: romcc quesiton

[YhLu]

I met that too, and I have remove some un converted code in E7501 raminit.c

YH

-----Original Message-----
From: Ronald G. Minnich [mailto:[e-mail]] 
Sent: Tuesday, November 09, 2004 6:44 AM
To: [e-mail]
Subject: romcc quesiton

I'm seeing that with  the new built-in preprocessor the following types of 
things work incorrectly:

#if 0
blha blha
#endif

The #if 0 is ignored, the romcc tries to compile the code.

Is this the expected behavior?

ron
p.s. cvs update as of this morning.
_______________________________________________
Linuxbios mailing list
[e-mail]
http://www.clustermatic.org/mailman/listinfo/linuxbios

romcc quesiton

[Ronald G. Minnich]

On Tue, 9 Nov 2004, YhLu wrote:
> I met that too, and I have remove some un converted code in E7501
> raminit.c

it's hard to reproduce with simple cases -- I'm trying to create the 
simple case but romcc always gets those right.

I'll try to find more if I get time today.

ron

romcc quesiton

"Ronald G. Minnich"  writes:
> On Tue, 9 Nov 2004, YhLu wrote:
> > I met that too, and I have remove some un converted code in E7501
> > raminit.c
>
> it's hard to reproduce with simple cases -- I'm trying to create the 
> simple case but romcc always gets those right.
>
> I'll try to find more if I get time today.

A complex case would be fine.  With abuild.sh I'm not seeing any compile
failures.

Eric

romcc quesiton

[Stefan Reinauer]

* Eric W. Biederman  [041109 23:19]:
> > I'll try to find more if I get time today.
>
> A complex case would be fine.  With abuild.sh I'm not seeing any compile
> failures.

Something's wrong with the line numbers. I get
incoherent_ht.c:191.8: warning:  "FIXME handle multiple chains!"
which is 10 lines later..
Does it ignore the lines with include statements?

romcc quesiton

Stefan Reinauer  writes:
> Eric W. Biederman  [041109 23:19]:
> > > I'll try to find more if I get time today.
> >
> > A complex case would be fine.  With abuild.sh I'm not seeing any compile
> > failures.
>
> Something's wrong with the line numbers. I get
> incoherent_ht.c:191.8: warning:  "FIXME handle multiple chains!"
> which is 10 lines later..
> Does it ignore the lines with include statements?

It should not but I have touched that bit of code recently so there
may be a regression there.

I will take a look.

Eric

romcc quesiton

Stefan Reinauer  writes:
> Eric W. Biederman  [041109 23:19]:
> > > I'll try to find more if I get time today.
> >
> > A complex case would be fine.  With abuild.sh I'm not seeing any compile
> > failures.
>
> Something's wrong with the line numbers. I get
> incoherent_ht.c:191.8: warning:  "FIXME handle multiple chains!"
> which is 10 lines later..
> Does it ignore the lines with include statements?

It looks like it is multiline macros that are confusing things.
As the same construct in raminit.c gets the line numbers correct.

Now to see if I can track down why this is.

Eric

romcc quesiton

[e-mail] (Eric W. Biederman) writes:
> Stefan Reinauer  writes:
> > Eric W. Biederman  [041109 23:19]:
> > > > I'll try to find more if I get time today.
> > >
> > > A complex case would be fine.  With abuild.sh I'm not seeing any compile
> > > failures.
> >
> > Something's wrong with the line numbers. I get
> > incoherent_ht.c:191.8: warning:  "FIXME handle multiple chains!"
> > which is 10 lines later..
> > Does it ignore the lines with include statements?
>
> It looks like it is multiline macros that are confusing things.
> As the same construct in raminit.c gets the line numbers correct.
>
> Now to see if I can track down why this is.

Ok.  This is clearly an issue with \ at the end of lines to
splice them together.  So to a certain the reporting is correct.
But I agree in practice that is wrong.

Fixing this is a little tricky. Either splice_lines needs to
insert a #line directive or I need to cleanup macro parsing a little
more.

Since the only thing incorrect is the line number I would like to
reproduce and fix the mysterious #if 0 does not work bug, before I 
touch that bit of code.

Eric

romcc quesiton

[Ronald G. Minnich]

I think I fixed part of my problem by removing // comments.

interesting.

ron

romcc quesiton

Stefan Reinauer  writes:
> Eric W. Biederman  [041109 23:19]:
> > > I'll try to find more if I get time today.
> >
> > A complex case would be fine.  With abuild.sh I'm not seeing any compile
> > failures.
>
> Something's wrong with the line numbers. I get
> incoherent_ht.c:191.8: warning:  "FIXME handle multiple chains!"
> which is 10 lines later..
> Does it ignore the lines with include statements?

Ok.  I have this fixed as well as a few other glitches in the preprocessor.
Error messages could be a little more precise.  But reporting everything
immediately after the error causing construct is not bad.

I believe I even have fixed the:
#if 0
        random assembly code....
#endif
issues as well.  This was accomplished by putting the sanity check at
a slightly higher location in the stack.

It looks like I have most things building again as well.  So far so good..

Eric

romcc quesiton

[Ronald G. Minnich]

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 ...

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 :-(

ron

romcc quesiton

"Ronald G. Minnich"  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

romcc quesiton

[Ronald G. Minnich]

On Wed, 10 Nov 2004, Eric W. Biederman wrote:
> 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.

yes you are right. This port has new life and I want to get it back to 
"about as broken as it was" :)
> raminit.c for that port has the same issues as the e7501 did.  In particular
> it has unconverted assembly #if 0'd out.

gone.

I only left things there until I was sure I did not want them. that code 
is gone.
> Placing the unconverted assembly in strings, or simply commenting it out
> will avoid the issue for now.

Or removing it.
> 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.

There wasn't an error message at all. What happened is everything in #if 0 
went through and romcc doesn't much like trying to compile assembly code 
...

thanks

ron

romcc quesiton

"Ronald G. Minnich"  writes:
> On Wed, 10 Nov 2004, Eric W. Biederman wrote:
> > Placing the unconverted assembly in strings, or simply commenting it out
> > will avoid the issue for now.
>
> Or removing it.

True.
> > 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.
>
> There wasn't an error message at all. What happened is everything in #if 0 
> went through and romcc doesn't much like trying to compile assembly code 
> ...

I see the error now.  That is how I know it exists.

I just did a build of the old digitalligic code.  From the end of the make:
./romcc ......
raminit.c:133.8: warning:  RAM_MRS -- using BROKEN hard-wired CAS 2.0. FIX ME SOON
raminit.c:792.17: 
unknown token
make[1]: *** [auto.inc] Error 1
make[1]: Leaving directory `/home/eric/projects/linuxbios/checkin/abuild/linuxbios-builds/digitallogic_adl855pc/normal'
make: *** [normal/linuxbios.rom] Error 1

It does say "unknown token" in there.  But just a cut and paste of the failure
would have been nice.

Eric

romcc quesiton

YhLu  writes:
> I met that too, and I have remove some un converted code in E7501 raminit.c

Ok.  Checking out the old version I can reproduce this problem.

I would like to see Ron's case but YhLu I know what is causing the problem
for the old northbridge/e7501/raminit.c case.

The code is ignored but I am still attempting to convert the text
into C tokens.  Since C does nothing with a '$' character whenever
I hit one of those the tokenizer chokes.

While I am within my rights per the C standard it would be nice
to be more permissive when I am skipping code.

For unconverted assembly code I suggest enclosing it in multiple coments
or placing it in strings for the moment.

Eric

Bitworks e-mail DOS

[Richard Smith]

Bitworks.com is under a email DOS attack from bounced spam due to our 
forged address problem.

Our ISP had to disable e-mail for bitworks.com. As a result mail to 
Bitworks.com will fail.

I can send out but not receive.

You can reach me at [e-mail]

Spammers are the scum of the earth.