Martin Koegler wrote: > Placing variables in a specfic section is only a part of the problem.
I am aware of that. There are already many targets that have special handling for section attributes, that result in different code being generated when a section attribute is present. Mostly these have to do with generating different kinds of address and/or addressing modes though, and your case sounds more complicated. Handling different kinds of addresses can be done by setting SYMBOL_REF_FLAGS on a symbol_ref.
My prototype for the m68hc05 does currently the following (based on GCC 4.1):
It looks like a reasonable plan.
It relies on MEM_EXPR always being set, which may not be true. But if there are places creating MEMs from decls without setting MEM_EXPR, then they probably should be fixed. MEMs created for things like spills to stack slots may not have MEM_EXPR set, but then they can't possibly have the eeprom attribute either, so that is OK.
This could be a maintenance problem if other developers make changes and forget to keep the MEM_EXPR fields accurate. The more we use the MEM_EXPR fields, the less of a problem this will be.
+ if (expr == NULL_TREE) + expr = t;
This is setting MEM_EXPR to a type.
I see that this does work by accident, because MEM_EXPR can be either a decl or a COMPONENT_REF, and all of the code that excludes COMPONENT_REFs will also happen to excludes types.
I don't think it is a good idea in general though. Overloading a field to have either an expression or a type may result in confusion later.
Presumably this is only a problem because some MEMs don't have the MEM_EXPR field set, in which case a better solution is to find the places that forget to set it and fix them.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
