[llvm-commits] [llvm] r44258 - in /llvm/trunk/lib: CodeGen/DwarfWriter.cpp Target/PowerPC/PPCAsmPrinter.cpp Target/PowerPC/PPCTargetAsmInfo.cpp Target/TargetAsmInfo.cpp Target/X86/X86ATTAsmPrinter.cpp Target/X86/X86AsmPrinter.cpp Target/X86/X86TargetAsmInfo.cpp

[Dale Johannesen]

On Nov 20, 2007, at 3:24 PM, Dale Johannesen wrote:

> Fix .eh table linkage issues on Darwin.

To explain what this is doing a bit:
On Darwin .eh tables are not magically associated with the  
corresponding function; they are separately relocatable entities in  
the linker, with no particular attachment to the function, and need  
relocation similar to the function.

When the EH stuff was done originally, part of this problem was  
handled by adding

     /// GlobalDirective - This is the directive used to declare a  
global entity.
     ///
     const char *GlobalDirective;          // Defaults to NULL.

in TargetAsmInfo.h.  However, that's not really what it meant; the  
only place this was used was in DwarfWriter,
where it was used to emit linkage for .eh tables, if it existed; and  
the only target that defined it was PPC Darwin.  Defining it for  
Linux would likely lead to linkage problems.  In the meantime, the  
Mips target has innocently defined and used GlobalDirective as  
documented, for emission of variables and functions and things like  
that, so now we have Confusion.

I have cloned the original GlobalDirective to GlobalEHDirective in an  
attempt to make it clearer what's going on.  GlobalDirective remains,  
with the documented meaning, and is now used only by the Mips target.

This changes the behavior of the Mips target regarding .eh tables for  
global and static functions; they used to get .global directives and  
now they do not.  I am not familiar with this target; my guess is  
this is the right thing to do (follows Linux).  If it is not,  
defining GlobalEHDirective for that target is probably right (I think  
it likely that emitting .globl for tables associated with static  
functions was always a bug).