[LLVMdev] llvm cross compilation and simplescalar simulation for ARM

Tim Northover t.p.northover at gmail.com
Wed May 6 19:46:46 PDT 2015


> For this purpose, clang(3.2) + arm-gcc + simplescalar-arm(and panalyzer)
> seems to be a good choice.

3.2 is a very old release in LLVM terms. I doubt anyone here really
knows all the details about it any more. You'd be much better off
using the most recent stable release (3.6) or even trunk.

> but I encounter the problem about ‘uclibc’. There is no ‘_IO_getc’ in libc.a of uclibc, but clang&llc compile ‘getc’ in C source to ‘_IO_getc’ in assembler.

The current source doesn't seem to randomly create calls to _IO_getc.
My best guess here would be you're including headers from your host
platform (due to a misunderstood --sysroot), rather than the uclibc
ones.

> someone says OABI rather EABI is necessary if want the executable run on simplescalar. So I don’t know how to solve this issue.

This is really worrying too: no-one uses OABI any more. It's virtually
untested on linux, as far as I know (though probably kept from
complete bit-rot by the fact that iOS uses a similar ABI).

> However, I get a fatal error when I run susan.out on simplescalar-arm:
> fatal: non-specultative fault (2) detected @ XXXXXXX

This could well happen if your simplescalar program isn't expecting
gnueabi (or any eabi) code.

> arm-gcc-2.95.3 recommended by simplescalar-arm official

That's a massive red flag. GCC 2.95 was released in 1999 (2.95.3 in
2001). Those versions are truly ancient; they were obsolete before
Clang was even a glint in Reid Spencer's eye (unfairly picking the
first clang commit -- it's all Reid's fault, QED).

> 1. If I do compiler related low power experiment via llvm(3.2) + arm-gcc + simplescalar-arm(and panalyzer), how could I setup the environment?? Does anyone has  the experience and can give some instructions?

I suspect you're in for a world of pain. Both simplescalar and
LLVM-3.2 appear to be too old to be viable these days, which means
you're probably going to have to hack on one or both code-bases to
have a hope of producing anything functional.

Tim.




More information about the llvm-dev mailing list