[LLVMdev] Win32 COFF Support patch 5 (the final patch in the saga!)

[Michael Spencer]

On Fri, Jul 30, 2010 at 1:28 PM, Daniel Dunbar <daniel at zuster.org> wrote:
> On Mon, Jul 26, 2010 at 7:25 PM, Michael Spencer <bigcheesegs at gmail.com> wrote:
>> Daniel somehow replied to one of my previous commits on llvm-commits
>> instead of this thread.
>>
>> On Mon, Jul 26, 2010 at 12:41 AM, Daniel Dunbar <daniel at zuster.org> wrote:
>>> Hi Michael,
>>>
>>> Two minor notes:
>>> --
>>>> diff --git a/lib/Target/X86/X86AsmBackend.cpp b/lib/Target/X86/X86AsmBackend.cpp
>>>> index 2cf65c1..02ac2be 100644
>>>> --- a/lib/Target/X86/X86AsmBackend.cpp
>>>> +++ b/lib/Target/X86/X86AsmBackend.cpp
>>>> @@ -14,6 +14,7 @@
>>>>  #include "llvm/MC/MCAssembler.h"
>>>>  #include "llvm/MC/MCExpr.h"
>>>>  #include "llvm/MC/MCObjectWriter.h"
>>>> +#include "llvm/MC/MCSectionCOFF.h"
>>>>  #include "llvm/MC/MCSectionELF.h"
>>>>  #include "llvm/MC/MCSectionMachO.h"
>>>>  #include "llvm/MC/MachObjectWriter.h"
>>>> @@ -212,6 +213,24 @@ public:
>>>>      : ELFX86AsmBackend(T) {}
>>>>  };
>>>>
>>>> +class WindowsX86AsmBackend : public X86AsmBackend {
>>>> +public:
>>>> +  WindowsX86AsmBackend(const Target &T)
>>>> +    : X86AsmBackend(T) {
>>>> +    HasAbsolutizedSet = true;
>>>> +    HasScatteredSymbols = true;
>>>
>>> These probably should be false for Win32.
>>
>> What do they do?
>
> You don't really want to know, but:
> (1) The Darwin tools conspire to allow the linker to reorder code, do
> dead code stripping, etc. What this means is that any two "atoms" in
> an assembly file might be moved in the final linked image. Therefore,
> you can't expect that things like 'A - B' are constants.
>
> (2) "Absolutized set" is something where Darwin 'as' will take a
> directive like '.set foo, A - B', and make foo be the current absolute
> expression for A - B, ignoring the fact that A and B might move. In
> practice, this is because the assembler wasn't smart enough to figure
> out which situations it could reliably compute A - B. This is related
> to (1).
>
> These two things end up impacting relaxation and the assembler
> backend, which is why they unfortunately get exposed at this level.

I tried setting these to false, but the resulting executable (made
with link.exe) crashed. I looked at the differences in the object
file, but couldn't figure out what was causing it. I'm guessing
there's a bug in the path when these are false.

Now that I know what these flags do, I'll try and figure out exactly
what the problem is.

- Michael Spencer

>>>> diff --git a/test/MC/COFF/dg.exp b/test/MC/COFF/dg.exp
>>>> new file mode 100644
>>>> index 0000000..7b7bd4e
>>>> --- /dev/null
>>>> +++ b/test/MC/COFF/dg.exp
>>>> @@ -0,0 +1,5 @@
>>>> +load_lib llvm.exp
>>>> +
>>>> +if { [llvm_supports_target X86] } {
>>>> +  RunLLVMTests [lsort [glob -nocomplain $srcdir/$subdir/*.{ll}]]
>>>> +}
>>>
>>> This should be *.{s}.
>>
>> This has to be *.{ll} for now because llvm-mc cannot parse COFF .s files.
>
> Oh, right.
>
>  - Daniel
>
>>
>>> --
>>>
>>> Otherwise looks good to me!
>>>
>>>  - Daniel
>>
>> - Michael Spencer
>>
>