Re: [cdt-dev] Extending the C language recognized by the parser

[John Camelon <jcamelon@xxxxxxxxxx>]

I would just try to work around it by
adding a macro to your project so along the lines of 

#define __at(x) 

so that it would just get skipped over
by the parser.  

Enabling a full variant/target model
will require significant systemic change in CDT that we have not committed
to doing in CDT 3.0.  

JohnC
www.eclipse.org/cdt

cdt-dev-admin@xxxxxxxxxxx wrote on 02/15/2005 04:59:28
PM:

> > Your question is definitely outside of the scope of the Managed
Build
> > System.  I've given it a different "subject" that
may get a response.
> 
> Well, the proposal also declared a change of the whole toolchain per
> project. I think there should also be some kind of change of the
> indexer/parser per toolchain. The main problem I currently encounter
is
> C-language extensions, GCC does not know of or expects it in different
> matter. Using the TASKING C-compiler, there are extensions like __at()
which
> also can provide information and/or need information from the toolchain.
> 
> * __at(0xC000000) for example puts a variable/structure at a certain
place
> in memory. The toolchain needs to setup the sections anyway, though
one can
> check, if this memory exists anyway and require the developer to think
about
> its declaration if this memory area is missing in the linker script.
> But GCC can't handle this, and currently GCC language is hardcoded/included
> in the main core/parser plugin. Maybe a toolchain could also automatically
> can create linker sections if it encounters #pragmas e.g. for locating
> specific sections in Code-RAM instead of default ROM/FLASH, with
> automatically enabling startup assembler fragments.
> 
> * Another example is the __asm() in TASKING, which seems to be a little
> different than GCC, at least the indexer is complaining about it in
my code.
> Also a toolcain can introduce a new ASM-dialect in the ASM-editor,
if it
> handles multiple processor/controller types.
> 
> * Also a toolchain could add/remove intrinsic functions to the indexer
on
> project basis and the current project toolchain selection.
> 
> * pragmas are something really toolchain specific feature and should
be
> enabled/disabled by the current toolchain.
> 
> But in all three examples, no toolchain-specific extension to C-language
> extension should interfere with other toolchains, when switching,
meaning
> that if one toolchain doesn't know of an extension, it should mark
it as
> wrong, but the other toolchain not.
> 
> 
>  
> > Leo
> > 
> > -----Original Message-----
> > From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx]
On
> > Behalf Of kesselhaus@xxxxxxx
> > Sent: Friday, February 11, 2005 7:46 AM
> > To: cdt-dev@xxxxxxxxxxx
> > Subject: RE: [cdt-dev] MBS Plan items for CDT 3.0 (proposed)
> > 
> > Is the C-language extension out of this scope?
> > I mean, if compiler understand some Non-ANSI-C extensions, like
> > __at(...)
> > and the like, though, Parser and Indexer don't yell on such statements,
> > because one toolchain supports this and the other something else.
> > 
> > > Here are the MBS proposed tasks in the requested format.
The bugzilla
> > > entry number will change as we complete individual designs.
> > > 
> > ...
> > > 
> > > _______________________________________________
> > > cdt-dev mailing list
> > > cdt-dev@xxxxxxxxxxx
> > > http://dev.eclipse.org/mailman/listinfo/cdt-dev
> > > 
> > 
> > -- 
> > Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS
> > GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/cdt-dev
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/cdt-dev
> > 
> 
> -- 
> DSL Komplett von GMX +++ Supergünstig und stressfrei einsteigen!
> AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/cdt-dev