[ECOS] CDL define_proc: Unable to put "extern" in an include files

[ECOS] CDL define_proc: Unable to put "extern" in an include files

[Jim Seymour]

I have a desire to inject an "extern" statement into an include file
generated by one of our CDL files - so I added a "define_proc" block.

Worked like a champ - until the build got to the rule to create
"heapgeninc.tcl" out of heapgen.cpp.

This file is run through the preprocessor and the output is then fed to
Tcl.  My "extern" statement is passed through the preprocessor intact,
so when it gets to Tcl, I get this error:

    invalid command name "extern"

The same problem exists when the target.ld file is built.  My "extern"
statement gets stuffed into that file, so ld fails with a "parse error".

I fixed both problems with a horrible kludge: adding a #define to
heapgen.cpp and then bracketing my extern with a #ifndef.  However, I
hate changing standard eCos files unless it's absolutely necessary.

Anyone know how (or if) I can safely add an "extern" to the generated
include files?

Going back a step...

What I'm trying to do is allow for our system clock speed to be a
run-time variable, instead of a fixed constant.  This means that the
#define's that get generated for CYGNUM_RTC_PERIOD (and the like) will
refer to a global variable.  Without an "extern" statement, these
references will cause a compiler error.

-- 
Jim Seymour, Cipher Systems, Inc., http://www.cipher.com


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] CDL define_proc: Unable to put "extern" in an include files

[Andrew Lunn]

On Wed, May 30, 2007 at 10:58:29AM -0700, Jim Seymour wrote:
> I have a desire to inject an "extern" statement into an include file
> generated by one of our CDL files - so I added a "define_proc" block.
> 
> Worked like a champ - until the build got to the rule to create
> "heapgeninc.tcl" out of heapgen.cpp.
> 
> This file is run through the preprocessor and the output is then fed to
> Tcl.  My "extern" statement is passed through the preprocessor intact,
> so when it gets to Tcl, I get this error:
> 
>    invalid command name "extern"
> 
> The same problem exists when the target.ld file is built.  My "extern"
> statement gets stuffed into that file, so ld fails with a "parse error".
> 
> I fixed both problems with a horrible kludge: adding a #define to
> heapgen.cpp and then bracketing my extern with a #ifndef. 

Could you turn this around. I think cpp is used to generate the linker
file, heapgeninc.tcl and it is used when compiling C and C++
code. However each invocation is for different languages.

Take a  look at the output of:

gcc -v -E -dD empty.c
gcc -v -E -dD empty.cpp

and see if there is something defined when compiling real code which
is not defined when using CPP for building the .ld file etc. Then use
#ifdef so that the extern is only present for real code generation
compilation.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] CDL define_proc: Unable to put "extern" in an include files

[Jim Seymour]

Andrew Lunn wrote:
> On Wed, May 30, 2007 at 10:58:29AM -0700, Jim Seymour wrote:
>> I have a desire to inject an "extern" statement into an include file
>> generated by one of our CDL files - so I added a "define_proc" block.
>>
>> Worked like a champ - until the build got to the rule to create
>> "heapgeninc.tcl" out of heapgen.cpp.
>>
>> This file is run through the preprocessor and the output is then fed to
>> Tcl.  My "extern" statement is passed through the preprocessor intact,
>> so when it gets to Tcl, I get this error:
>>
>>    invalid command name "extern"
>>
>> The same problem exists when the target.ld file is built.  My "extern"
>> statement gets stuffed into that file, so ld fails with a "parse error".
>>
>> I fixed both problems with a horrible kludge: adding a #define to
>> heapgen.cpp and then bracketing my extern with a #ifndef. 
> 
> Could you turn this around. I think cpp is used to generate the linker
> file, heapgeninc.tcl and it is used when compiling C and C++
> code. However each invocation is for different languages.
> 
> Take a  look at the output of:
> 
> gcc -v -E -dD empty.c
> gcc -v -E -dD empty.cpp
> 
> and see if there is something defined when compiling real code which
> is not defined when using CPP for building the .ld file etc. Then use
> #ifdef so that the extern is only present for real code generation
> compilation.

If I'm understanding you here, it sounds like I want some way for the 
preprocessor to detect the presence of the -E option.

I'm not seeing any way to do this, though.  As far as I can see, the -E 
option behaves exactly like a normal compile - it just stops after the 
preprocessor.

I suppose a slightly less kludgy solution to my problem might be to add 
something like -DPREPROCESSOR_ONLY to the the "heapgeninc.tcl" and 
"target.ld" rules.

-- 
Jim Seymour, Cipher Systems, Inc., 503-617-7447, http://www.cipher.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] CDL define_proc: Unable to put "extern" in an include files

[Andrew Lunn]

> >Take a  look at the output of:
> >
> >gcc -v -E -dD empty.c
> >gcc -v -E -dD empty.cpp
> >
> >and see if there is something defined when compiling real code which
> >is not defined when using CPP for building the .ld file etc. Then use
> >#ifdef so that the extern is only present for real code generation
> >compilation.
> 
> If I'm understanding you here, it sounds like I want some way for the 
> preprocessor to detect the presence of the -E option.

No, that is not what i was meaning. However i did a little testing,
and what i was suggesting does not work:-(

When gcc calls cpp for a C++ file, the symbol __cplusplus is
defined. When gcc calls cpp for a C file the symbol __STDC__ is
defined. I was hoping that if you call cpp without telling which
language it is, it would not define/define some other symbol. You can
then #ifdef on that. Unfortunately, if not told otherwise cpp defaults
to plain old C.

May you are attacking the problem from the wrong end. Could the extern
be placed somewhere else? Code which is using the symbol
CYGNUM_HAL_RTC_PERIOD probably has include hal_platform_ints.h or
plf_io.h.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] CDL define_proc: Unable to put "extern" in an include files

[Jim Seymour]

Andrew Lunn wrote:
> May you are attacking the problem from the wrong end. Could the
> extern be placed somewhere else? Code which is using the symbol 
> CYGNUM_HAL_RTC_PERIOD probably has include hal_platform_ints.h or 
> plf_io.h.

We tried putting it in plf_arch.h - but that had the same problem.

My suspicion is that any .h we find will also get invoked while building 
"heapgeninc.tcl" and/or "target.ld".

However, I'll dig into that and see if I can find something...

-- 
Jim Seymour, Cipher Systems, Inc., 503-617-7447, http://www.cipher.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] CDL define_proc: Unable to put "extern" in an include files

[Nick Garnett]

Jim Seymour <ecosjim@cipher.com> writes:

> 
> What I'm trying to do is allow for our system clock speed to be a
> run-time variable, instead of a fixed constant.  This means that the
> #define's that get generated for CYGNUM_RTC_PERIOD (and the like) will
> refer to a global variable.  Without an "extern" statement, these
> references will cause a compiler error.

There are other ways to achieve this.

The way I have done this in the past is not to make CYGNUM_RTC_PERIOD
variable. Too much code assumes that this value is a constant; it uses
its value on startup to calculate some scaling factors, or whatever,
and then doesn't read it again. So even if CYGNUM_RTC_PERIOD were to
vary, the original derived values would still be used.

Instead, where I want to run the system at different clock speeds I
express CYGNUM_RTC_PERIOD is terms of a fictional fixed rate clock;
usually around 1MHz, but you can go as low as 1KHz if you want. Then,
in HAL_CLOCK_INITIALIZE(), I calculate the real clock period using the
current system clock rate. The selected period is saved in the HAL, so
when I change the system clock rate I can recalculate the real period
(just recalling HAL_CLOCK_INITIALIZE() does the trick usually).

Obviously HAL_CLOCK_READ() also needs to do some arithmetic to
translate system clock ticks back into ticks of the fictional clock.


-- 
Nick Garnett                                     eCos Kernel Architect
eCosCentric Limited     http://www.eCosCentric.com/   The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.    Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss