sys::getHostTriple failed to recognize ARM correctly

Hi, all

  It seems that rev. 131463 [1] makes LLVM failed to recognize ARM
correctly. My best guess is the variable LLVM_HOSTTRIPLE got
something like "armv7l-unknown-linux-gnueabi" when LLVM compiled
natively on ARM. Then the Arch (armv7l) is not recognized by LLVM.

  As you can see from attach (llvm-131463-gcc-4.4.1-native-arm2.log),
there are a lot failure while running test cases under ExecutionEngine/.
Those failure are disappeared when I cross compile LLVM. Maybe
LLVM_HOSTTRIPLE got the *right* value, i.e., arm-unknown-linux-gnueabi.

  Currently, I handcode "Arch = "arm"" to make native compiled LLVM
pass most test cases [2]. Is there a better way to make sys::getHostTriple
handle this situation?

  Thanks!

Regards,
chenwj

[1] http://llvm.org/viewvc/llvm-project?view=rev&revision=131463
[2] see attach llvm-131466-fix-gcc-4.4.1-native-arm2.log

llvm-131463-gcc-4.4.1-native-arm2.log (27.8 KB)

llvm-131466-fix-gcc-4.4.1-native-arm2.log (2.46 KB)

Two ways:

a) Add support for armv7l to llvm :slight_smile:
b) Pass --host=-… when you configure.

-eric

Hi, Eric

Two ways:

a) Add support for armv7l to llvm :slight_smile:
b) Pass --host=<arm arch you want>-… when you configure.

  Do you mean both way have to be done, or either way? I don't
understand if I ignore option a, which means LLVM does NOT
support armv7l right now, how can --host=<arm arch you want>
work? Or I misunderstood what you said?

Regards,
chenwj

Either way. But it sounds like you were ok with arm-linux-gnu so that's what I'd suggest you pass using --host.

And no, I don't see anything that says "v7l" in the arm backend as of yet.

-eric

>> b) Pass --host=<arm arch you want>-… when you configure.

Either way. But it sounds like you were ok with arm-linux-gnu so that's what I'd suggest you pass using --host.

  So what you suggest is passing arm-linux-gnu NOT armvX-linux-gnu,
right? I thought <arm arch you want> can be armvX-linux-gnu,
that confuse me.

Regards,
chenwj

It can be whatever you want, I'd suggest something that has some support in the backend :slight_smile:

-eric

Hi,

My patch, sent a few months back was meant to make this easier to update. Eric has discussed it internally in Apple I believe and has some ideas how the driver can be improved, but I haven't heard back further about a schedule for providing such a patch.

Eric - I'd be happy to engineer said patch if you have some sort of spec or guidelines on what you'd prefer done?

陳韋任:
While armv7l is not recognised, it is equivalent to "armv7", which should work. The "l" just means little endian which is default for ARM targets.

James

Hi,

My patch, sent a few months back was meant to make this easier to update. Eric has discussed it internally in Apple I believe and has some ideas how the driver can be improved, but I haven't heard back further about a schedule for providing such a patch.

You weren't the only one on vacation :wink:

Eric - I'd be happy to engineer said patch if you have some sort of spec or guidelines on what you'd prefer done?

I thought I sent a bunch of it, but we can easily take it to private email to work out more of it. I'm adding Chad to this since he's been doing a lot of toolchain stuff as well. :slight_smile:

-eric

To respond here I've sent this privately since we had the rest of the discussion on the list a while back :slight_smile:

-eric