I don't personally like this patch. It seems, that emitted data encoding
is linker (=subtarget) specific. For example, gcc uses three different
data encodings to emit dwarf data on darwin.
I think we should introduce subtarget hooks for encoding selection of
data being emitted (there is already one: needSet / *AbsoluteOffsets
etc). Also "generic" function for emission of data in specified format
should be written (it should take care about decoration also).
This will allow to describe target-specific stuff in one place instead
of introducing / tweaking bunch of magic knobs.
I don't personally like this patch. It seems, that emitted data encoding
is linker (=subtarget) specific. For example, gcc uses three different
data encodings to emit dwarf data on darwin.
But that's why I put the "decoration" in the TargetAsmInfo object, and then handled the printing of the global stubs separately at the subtarget level. Or do you mean that emitting the personality information should be done completely in the back-end?
I think we should introduce subtarget hooks for encoding selection of
data being emitted (there is already one: needSet / *AbsoluteOffsets
etc). Also "generic" function for emission of data in specified format
should be written (it should take care about decoration also).
I agree with you in general. We should have good abstractions for emitting ASM code. How would you modify the structure of the codegen stuff to make the personality function emission be the same?
This will allow to describe target-specific stuff in one place instead
of introducing / tweaking bunch of magic knobs.
It's not exactly tweaking magic knobs. It's doing something that's already done -- putting the information in the TAI object, and allowing the specific back-end to set the appropriate strings.
Comments? Ideas?
If I understand you correctly, this seems like a bigger project than simply getting the personality function to work for Darwin.
It's not exactly tweaking magic knobs. It's doing something that's
already done -- putting the information in the TAI object, and
allowing the specific back-end to set the appropriate strings.
It seems to me, that simple strings / bools there are not enough
"$non_lazy_ptr" emission is already in asm printers (in 2 places!). The
"L" prefix is PrivateGlobalPrefix (so PersonalityPrefix is really
duplicate). That's why I thought about factoring such stuff into
separate hooks. I'm really worrying, that number of such strings / bools
can be increased, if somebody will try to make other targets (e.g. ppc /
arm) fully support things, which are now x86-specific (I even don't
know, whether current settings are enough to representing 64-bit
specific information)
If I understand you correctly, this seems like a bigger project than
simply getting the personality function to work for Darwin.
I'm happy for this fix in short-term. But yes, it is pretty non-small
project
It's not exactly tweaking magic knobs. It's doing something that's
already done -- putting the information in the TAI object, and
allowing the specific back-end to set the appropriate strings.
It seems to me, that simple strings / bools there are not enough
"$non_lazy_ptr" emission is already in asm printers (in 2 places!). The
"L" prefix is PrivateGlobalPrefix (so PersonalityPrefix is really
duplicate). That's why I thought about factoring such stuff into
separate hooks. I'm really worrying, that number of such strings / bools
can be increased, if somebody will try to make other targets (e.g. ppc /
arm) fully support things, which are now x86-specific (I even don't
know, whether current settings are enough to representing 64-bit
specific information)
If I understand you correctly, this seems like a bigger project than
simply getting the personality function to work for Darwin.
I'm happy for this fix in short-term. But yes, it is pretty non-small
project
Okay. I think we're on the same page then. I'll go ahead and commit this for the short term, and then we can hash out a better long term solution. Sound good?
Please make sure the suffix is correct when compiling for static relocation model.
The way the Darwin asm printer handles $non_lazy_ptr is pretty hacky. Perhaps we need to add some target specific information onto GV's. This is definitely a stop gap solution. Hopefully it's won't be a permanent one.
