[LLVMdev] Mod for using GAS with MS VC++
Chris Lattner
sabre at nondot.org
Mon Jul 11 17:21:11 PDT 2005
On Tue, 12 Jul 2005, Aaron Gray wrote:
>>
>> 1. Please send patches instead of full files. The best way to do this is
>> to use CVS like this: 'cvs diff -u' in the directory that you care
>> about. You can also specify specific files to diff as well.
>
> Okay, I will do this in future, our posts crossed so I have not done
> that for the MASM backend. I will do this in future. If you want me to
> redo the MASM Printer as diff's I can do so tommorow as it is late now.
Sounds good, thanks and sorry for the trouble.
>> 2. Please update to the latest CVS bits.
>
> Okay I may have been behind but am still not used to using CVS and how to
> reintegrate changes that go cross purpose with stuff I already have written
> but do not want to release yet. So I may have gotten out of sync here.
Ok
>> 3. You need to invent a target triple for your new configuration. You'll
>> notice that the forCygwin/forDarwin variables are set based on the
>> target triple of the module... as you coded it, forWindows is only
>> ever set if the t-t is empty.
>
> Right, presumably Wndows does not set the TT. Should Windows or MSVC++
> have one ? If so how do I go about it. Maybe Jeff should be involved ?
It should/will. Currently there is no C/C++ front-end that works on
native windows, but that doesn't really matter. In the future, we want to
key off the target triple that makes sense.
Cygwin uses: i686-pc-cygwin and mingw uses i686-pc-mingw32, so I think
that using i686-pc-masm and i686-pc-nasm make sense.
>> 4. The name forWindows isn't very specific, as there are multiple dev
>> systems available on windows (including cygwin, mingw, masm, nasm,
>> etc). Please use something more specific.
>
> Maybe it should be MSVC specific then ?
Sure, but presumably you want to differentiate between nasm and masm (if
they are not compatible) right?
>> 5. I notice that the stuff you are controlling enables/disables the exact
>> same stuff as needed for cygwin. Will this change in the future?
>
> Same as Cygwin, so MSVC++ build, gas generated code, can be run on gas.
I don't understand.
>>> This may prompt thurther normalization, on the otherhand it may not :)
>>
>> Yes, I think it will. :) In particular, instead of a bunch of checks
>> based on the target, what we really want is something like this:
...
> Yes that would be much better and more normalized.
Nate said he might take a stab at this, which is the first step towards
real subtarget support.
-Chris
--
http://nondot.org/sabre/
http://llvm.org/
More information about the llvm-dev
mailing list