[cfe-dev] TextDiagnosticPrinter::HandleDiagnostic() question

[Andrew Fish]

>> 
>> Seems to me that LangOpts->Microsoft implies code construction and not OS version that the system is running on? 
> 
> I agree;  this should be triggered by the target, not LangOptions.Microsoft.  On the other hand...
> 
>> So how could we make normal clang diagnostics appear for for the 86_64-pc-win32-macho triple?
> 
> ...I would think that this triple suggests a Microsoft target.
> 

Our target is really EFI  system firmware (http://www.uefi.org/) so all we need is the win32 ABI and not any of the system stuff. The edk2 (http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK2) is an open source EFI code base  that supports lots of flavors of compilers like Visual Studio 2003 - 2010, Intel, gcc, clang, and others for ARMv7, i386, 86_64, and Itanium processors, and you can build on Windows, Linux, or Mac OS X systems. The edk2 code base is C and there is zero dependency on any system libraries, not even for compiler intrinsics. Also there is a cctools command line tool, mtoc, that will convert a Mach-0 to an EFI PE/COFF executable (not a Windows PE/COFF executable!). We need the Mach-O for source level debugging. 

So the 86_64-pc-win32-macho triple really means build and run a debugger for 86_64 EFI firmware on Mac OS X.  The EFI 86_64 binaries can run on any 86_64 EFI system or emulator. 

The edk2 code base was size optimized using Visual Studio link-time code gen. This means if the edk2 is compiled with gcc you get a much larger executable size. In the firmware world NOR FLASH cost real money so size is more important than raw performance from the compiler. Since clang also does link time optimization it is the obvious choice for a non Windows based compiler for the edk2 EFI code base. 

> This was introduced in r90642, which refers to <rdar://problem/6309338>, if you want to figure out what the right trigger for this is.

Sorry I'm an EFI expert, but my clang knowledge is not very good. We were hoping to get some one with the clang "big picture" to suggest the best way to fix this. We kind of hacked around in the back end using our crazy triple.... Of course we are happy to do testing and make a localized change, but I'd be very apprehensive about making a more global change.

Andrew