[llvm-dev] MSP430 code generation from LLVM IR

[Luís Marques via llvm-dev]

I'll provide a pull request. Since MSP430 code is always cross-compiled we
can assume that 'gcc' is always wrong. The only names I've ever seen used
are 'msp430-gcc' (nearly all I've seen) and 'msp430-elf-gcc' (TI's prebuilt
toolchain). So, for now, we can avoid the "complicated logic" that clang
uses without hardcoding it too much.

On Thu, Jul 6, 2017 at 2:29 AM, Nicholas Wilson <
iamthewilsonator at hotmail.com> wrote:

> If you want to hack it straight away
>
> make changes to
> https://github.com/ldc-developers/ldc/blob/master/driver/toobj.cpp#L136
> in particular change the getGcc in line 186
> int R = executeToolAndWait(getGcc(), args, global.params.verbose);
>
> to wherever you assembler is located.
> You may have to change the arguments passed to the assembler as well.
>
> On 6 Jul 2017, at 9:24 am, Luís Marques <luis at luismarques.eu> wrote:
>
> On Thu, Jul 6, 2017 at 2:19 AM, Tim Northover <t.p.northover at gmail.com>
> wrote:
>
>> On 5 July 2017 at 17:51, Luís Marques via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > Cool. When I did that on macOS, LDC generated a lot of complaints,
>> possibly
>> > because it is assuming mach-o files. I tried changing from
>> -mtriple=msp430
>> > to -mtriple=msp430-unknown-elf, to no avail. E.g.:
>>
>> Clang has a bunch of complicated logic to find the correct assembler
>> if it's installed (in this case I'd expect "msp430-unknown-elf-as").
>> It's quite possible LDC doesn't have this since its main targets use
>> the integrated-assembler. Your errors certainly look consistent with
>> the macOS system "as" being called on ELF MSP430 output.
>>
>
> Yup, it's using /usr/bin/gcc as the assembler driver.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170706/850b68d8/attachment.html>