search for: privateglobalprefix

...e-C where CFStrings will get these labels, thus preventing the linker from coalescing them. [/tmp]> nm -s __DATA __cfstring -m foo.o 00000000000244d0 (__DATA,__cfstring) non-external __unnamed_1_0 00000000000244b0 (__DATA,__cfstring) non-external __unnamed_1_1 ... I think that prepending the PrivateGlobalPrefix to these names would be the way to go. My question is whether getValueName() should do the prepending or should the individual back-end do it? I think that getValueName() should do it so that it's consistent, but then the prefix needs to be passed in (as the mangler doesn't know abo...

...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-spe...

...e mistake that I just verified is still in the tree: Index: lib/Target/ARM/ARMTargetAsmInfo.cpp =================================================================== --- lib/Target/ARM/ARMTargetAsmInfo.cpp (revision 48700) +++ lib/Target/ARM/ARMTargetAsmInfo.cpp (working copy) @@ -49,7 +49,7 @@ PrivateGlobalPrefix = "L"; BSSSection = 0; // no BSS section. ZeroFillDirective = "\t.zerofill\t"; // Uses .zerofill - SetDirective = "\t.set"; + SetDirective = "\t.set\t"; WeakRefDirective = "\t.weak_reference\t"; Hidde...

...abels, > thus preventing the linker from coalescing them. > > [/tmp]> nm -s __DATA __cfstring -m foo.o > 00000000000244d0 (__DATA,__cfstring) non-external __unnamed_1_0 > 00000000000244b0 (__DATA,__cfstring) non-external __unnamed_1_1 > ... > > I think that prepending the PrivateGlobalPrefix to these names would > be the way to go. My question is whether getValueName() should do the > prepending or should the individual back-end do it? I think that > getValueName() should do it so that it's consistent, but then the > prefix needs to be passed in (as the mangler doesn...

...ormation 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 sup...

...the linker from coalescing them. >> >> [/tmp]> nm -s __DATA __cfstring -m foo.o >> 00000000000244d0 (__DATA,__cfstring) non-external __unnamed_1_0 >> 00000000000244b0 (__DATA,__cfstring) non-external __unnamed_1_1 >> ... >> >> I think that prepending the PrivateGlobalPrefix to these names would >> be the way to go. My question is whether getValueName() should do the >> prepending or should the individual back-end do it? I think that >> getValueName() should do it so that it's consistent, but then the >> prefix needs to be passed in (as the...

...= 0; // .xword is only supported by V9. ZeroDirective = "\t.skip\t"; CommentString = "!"; HasLEB128 = true; SupportsDebugInformation = true; SunStyleELFSectionSwitchSyntax = true; UsesELFSectionDirectiveForBSS = true; WeakRefDirective = "\t.weak\t"; PrivateGlobalPrefix = ".L"; } But I can not find in Sparc, or any other backend code to set ConstantPoolSection. I tried in my backend deriving MCAsmInfo, but it seems, that ConstantPoolSection is not member of MCAsmInfo. I really need in my backend value for this section, distinct from default. Where can...

With the MIPS compiler, when we have static constants, in the .s file we get something like: .type $.str33, at object # @.str33 .section .rodata.str1.1,"aMS", at progbits,1 $.str33: .asciz "//" .size $.str33, 3 Currently when we create direct object code we are referencing the symbol as an offset in .rodata and not directly using

I'm working on an LLVM back end with output to assembly file (.s). I'm using the ARM assembly printer. The generated labels (e.g. for a while statement) start with '.' like .LBB0_1 I would like to change the '.' to something else (specifically $$ if it matters). I see a lot of customizability in targetinfo.cpp but not that particular item. Where should I be looking?

...ize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el * MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel woul...

...ize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el * MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel woul...

...ize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el * MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel woul...

...e is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) o MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el o MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel woul...

...ize is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) * MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el * MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel woul...

...e is incorrect for the N32 ABI (should be 4 but gets 8 since it checks for Triple::mips64/mips64el) o MipsMCAsmInfo::CalleeSaveStackSlotSize is incorrect for mips-linux-gnu –mips64 –mabi=64. Since it too checks for Triple::mips64/mips64el o MipsMCAsmInfo::PrivateLabelPrefix and MipsMCAsmInfo::PrivateGlobalPrefix are wrong (currently "$", should be ".L") for N32/N64 but it's possible to fix this. However, O32 should permit "$" in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel woul...

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because