This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
symbol encoding cleanup plan
On Sat, Aug 31, 2002 at 08:28:51AM -0400, Kaveh R. Ghazi wrote:
> Ok I'll bite. Let's hear them.
SYMBOL_REF needs to be extended to three arguments. The second
argument would be an XINT set of flag bits, the third argument
would be the DECL, if available.
We would define a common set of flag bits that represent what
many ports use encode_section_info for:
/* A function, or function alternate entry. */
#define SYMBOL_CODE 1
/* In the small data area. */
#define SYMBOL_SMALL 2
/* Bound within this module. */
#define SYMBOL_LOCAL 4
/* Defined within this unit of translation. */
#define SYMBOL_THIS_UOT 8
/* A TLS symbol. */
#define SYMBOL_TLS 16
/* First bit available to the target. */
#define SYMBOL_MACH_DEP 32
The encode_section_info hook would still be available to
targets to do target-specific stuff, but the vast majority
of them wouldn't need to do anything now. In the worst
case (running out of mach_dep bits), the DECL would still
be available, so the target could re-derive whatever it
needed instead of caching the data.
The "*" leader is, imo, stupid. We should simply apply the
user_label_prefix immediately when creating the symbol_ref.
There's some bizzare transformations that happen for darwin
arc, arm-aof, i370; if these can't be done with encode_section_info,
then perhaps a new hook is required; the default would simply
add user_label_prefix.
The hope, however, is that ASM_OUTPUT_LABELREF is exactly
fputs for all targets. The only kink I see might be ia64
and its desire to add '#' after label uses. Oh, not sure
what mmix is doing here either.
r~