AsmPrinter::EmitLinkage

I have been looking over AsmPrinter::EmitLinkage (around line 195 of lib\CodeGen\AsmPrinter\AsmPrinter.cpp) and it seems that its implementation will vary quite a bit depending on what object file format is in use (MachO, ELF, or COFF).

Would it make sense to delegate the implementation to a specialized object from current the object file format?

I am tempted to make it the MCAsmInfo implementation for the specific target. Currently MCAsmInfo looks just to hold useful information about the target, and not any target specific code.

TargetLoweringObjectFile looks to perform a similar function as MCAsmInfo, though this doesn’t look to be responsible for directing the AsmPrinter, its only responsibility appears to be providing section assignment logic.

Another candidate I considered what TargetAsmBackend, but that appears to be meant to sit behind MCStreamer.

Another approach would be to further subdivide X86AsmPrinter to have object file format specific variants that could implement the required logic. The problems I am trying to solve are processor independent so I don’t think this would be the right approach, but it could potentially be useful in other situations.

Finally, a new object could be created that is specialized by the different object file formats. There are already a number of specialized objects, and seems like at would make things confusing.

I think there are other places that could benefit from a similar transformation. On example would be the handling of the X86AsmPrinter::EmitEndOfAsmFile which has three separate blocks of code dedicated to the different object file formats. At least in the case of COFF, the operations being performed are not specific to X86.

-Nathan

I have been looking over AsmPrinter::EmitLinkage (around line 195 of lib\CodeGen\AsmPrinter\AsmPrinter.cpp) and it seems that its implementation will vary quite a bit depending on what object file format is in use (MachO, ELF, or COFF).
Would it make sense to delegate the implementation to a specialized object from current the object file format?

Why? It is AsmPrinter's job to handle the lowering of MachineInstrs and LLVM IR (for globals etc) to the MC level primitives. AsmPrinter should really be renamed MCLowering at some point.

I am tempted to make it the MCAsmInfo implementation for the specific target. Currently MCAsmInfo looks just to hold useful information about the target, and not any target specific code.

Right. MCAsmInfo has been designed to be filled in by targets but not subclassed. This implies that it can't have virtual methods.

TargetLoweringObjectFile looks to perform a similar function as MCAsmInfo, though this doesn't look to be responsible for directing the AsmPrinter, its only responsibility appears to be providing section assignment logic.

TLOF is designed to be specific to the object file, but ideally not target specific. This means we should have TLOFMacho but not TLOFX86Macho.

Another candidate I considered what TargetAsmBackend, but that appears to be meant to sit behind MCStreamer.

Right, that is the actual implementation of the object writer for a specific target.

Another approach would be to further subdivide X86AsmPrinter to have object file format specific variants that could implement the required logic. The problems I am trying to solve are processor independent so I don't think this would be the right approach, but it could potentially be useful in other situations.

Finally, a new object could be created that is specialized by the different object file formats. There are already a number of specialized objects, and seems like at would make things confusing.

I think there are other places that could benefit from a similar transformation. On example would be the handling of the X86AsmPrinter::EmitEndOfAsmFile which has three separate blocks of code dedicated to the different object file formats. At least in the case of COFF, the operations being performed are not specific to X86.

What problem are you trying to solve here? I'm pretty sure that AsmPrinter is emitting valid COFF output already, no?

-Chris

I have been looking over AsmPrinter::EmitLinkage (around line 195 of lib\CodeGen\AsmPrinter\AsmPrinter.cpp) and it seems that its implementation will vary quite a bit depending on what object file format is in use (MachO, ELF, or COFF).
Would it make sense to delegate the implementation to a specialized object from current the object file format?

Why? It is AsmPrinter’s job to handle the lowering of MachineInstrs and LLVM IR (for globals etc) to the MC level primitives. AsmPrinter should really be renamed MCLowering at some point.

I am tempted to make it the MCAsmInfo implementation for the specific target. Currently MCAsmInfo looks just to hold useful information about the target, and not any target specific code.

Right. MCAsmInfo has been designed to be filled in by targets but not subclassed. This implies that it can’t have virtual methods.

TargetLoweringObjectFile looks to perform a similar function as MCAsmInfo, though this doesn’t look to be responsible for directing the AsmPrinter, its only responsibility appears to be providing section assignment logic.

TLOF is designed to be specific to the object file, but ideally not target specific. This means we should have TLOFMacho but not TLOFX86Macho.

In the context I am looking at, it would be specific to the object file. I was just pointing out that as it stands, it appears to only be responsible for section assignment, and not any logic that would affect the AsmPrinter’s decision on what to emit. I don’t know what the exact intent of this object is other that the functionality it already implements, but it seems it would make a good candidate to work with AsmPrinter (MCLower) to produce ouput for a specific object file.

Another candidate I considered what TargetAsmBackend, but that appears to be meant to sit behind MCStreamer.

Right, that is the actual implementation of the object writer for a specific target.

Another approach would be to further subdivide X86AsmPrinter to have object file format specific variants that could implement the required logic. The problems I am trying to solve are processor independent so I don’t think this would be the right approach, but it could potentially be useful in other situations.

Finally, a new object could be created that is specialized by the different object file formats. There are already a number of specialized objects, and seems like at would make things confusing.

I think there are other places that could benefit from a similar transformation. On example would be the handling of the X86AsmPrinter::EmitEndOfAsmFile which has three separate blocks of code dedicated to the different object file formats. At least in the case of COFF, the operations being performed are not specific to X86.

What problem are you trying to solve here? I’m pretty sure that AsmPrinter is emitting valid COFF output already, no?

I think it emits valid output, but I don’t think it handles weak symbols correctly, as COFF supports true weak symbols, but this code appears to turn them into a linkonce section which is not quite the same thing.

In my opinion, the body of this function should be different for each object file type (at least for COFF). It could be handled in place as a large if-then-else block, but when I see that type of code, which is the same in the X86AsmPrinter::EmitEndOfAsmFile it seems to me that they should be encapsulated somehow.

Perhaps, AsmPrinter itself could be specialized for the object file format in use?

I think it emits valid output, but I don't think it handles weak symbols
correctly, as COFF supports true weak symbols, but this code appears to turn
them into a linkonce section which is not quite the same thing.

Yes. This was intentional, since:
1. At the time of writing the code binutils did not support weak stuff
2. It was my feeling, that weak (especially external weak stuff) on
COFF differs in some details from e.g. weak on MachO/ELF. I might be
wrong, however...

It is my understanding that weak symbols are symbols that can be overridden (i.e. library provides a default implementation, and the application may override it). Whereas linkonce (or COMDAT) is for symbol that might show up in multiple object file but are effectively the same so its not particularly important which one is selected. According to Microsoft’s COFF documentation, weak linkage is supported. From what I can gather from the documentation, only one symbol may be defined as weak, and the overriding symbol if present would be define normally. Perhaps this is the difference in detail you speak of.

-Nathan

Hello, Nathan

It is my understanding that weak symbols are symbols that can be overridden
(i.e. library provides a default implementation, and the application may
override it).

Right

documentation, weak linkage is supported. From what I can gather from the
documentation, only one symbol may be defined as weak, and the overriding
symbol if present would be define normally. Perhaps this is the difference
in detail you speak of.

What if there will be two weak symbols?

For the windows sub-target is it safe to assume Microsoft's linker is the being targeted?

I'd really appreciate if both ms link and gnu ld will be tested, if
this is possible.

I have done some tests with Cygwin, and most things seem okay, e.g. Static Constructors…Virtual Destructors.

I did try building llvm-gcc on Cygwin with some hacks, but llvm-gcc requires some inline assembly, I may try and hack that through as assembly code.

This involved linking and xgcc ran okay, so things are looking good :slight_smile:

Aaron

For dllexport support, there are differences between GNU’s and Microsoft’s linkers. I thought the the subtarget was their to differentiate what tool-set was being targeted. I used that assumption on my patch to update the support for dllexport.

-Nathan

For dllexport support, there are differences between GNU's and Microsoft's
linkers. I thought the the subtarget was their to differentiate what
tool-set was being targeted. I used that assumption on my patch to update
the support for dllexport.

Yes, surely, since dllexport support is just adding extra stuff to
linker cmdline.