ARM thumb-2 instruction used for non-thumb2 CPUs

Thanks, Damjan. That's good information.

Crash #1 is an assembly source file. It's running into something it doesn't understand on the line indicated. The assertion failure is a secondary problem, and definitely shouldn't happen. As mentioned, though, the asm parser isn't ready for prime time yet, so I suspect this may be just the tip of the iceberg as far as the problems that (and similar) files would encounter.

Crash #2 is a C file, but is also asserting in the assembly parser, which indicates that there's inline assembly in the file somewhere that the parser doesn't know how to handle yet.

Some Makefile magic should be able to take care of issues of the sort encountered in #1 (don't pass -integrated-as when compiling .S files).

Inline assembly is a bit trickier. Temporarily, if those files compile/assemble OK with the system assembler (i.e., don't have the rrx instruction mnemonic in them), we could work around by not using -integrated-as for them. That's pretty fugly, though, and would just be a quick workaround to allow you to keep making progress while the real issues get fixed.

How much inline asm is there in that file that's causing issues? if it's not too much, it might not be too bad to get at least that much of the asm parsing working. That would be general goodness and would help move you forward.

-Jim

Hi Renato,

We are *very* interested in getting ARM MC in shape. It's the core for an ARM assembler, disassembler, and MC JIT. To me, there are three main tasks:

1. Get all of the tests (which are not using inline asm) passing with -integrated-as.
2. Finish up ARM asm parser so integrated-as can support inline asm and to use it to build a standalone assembler.
3. Rewrite the ARM disassembler. We don't think the current implementation is good enough for production usage.

For Darwin, we believe #1 is very close. We'll soon find some time start large scale testing. For ELF, it's less clear. You guys should definitely try it out and report bugs.

We also plan on tackling #2 in the not too distant future. It's a big chunk of work so we'd appreciate any assistance on this. #3 is less urgent, but we'd like to gut the existing one and replace it with something that's more auto-generated than what's currently there.

Evan

To get -integrated-as working so that we don't need to go through the assembler at all should be mostly a matter of bug fixing, modulo inline assembly support. For non-trivial inline assembly, and to get a system assembler replacement based on the MC assembler, it'll be a bigger task. The ARM asm parser is currently in need of some tender loving care. That's coming soon, but it's a non-trivial task.

For -integrated-as, I would suggest giving it a try. I'm not completely sure how complete the support is for ELF, but I think it's in somewhat OK shape, at least. Worth trying. That would neatly avoid the problem if it works. If it doesn't, we should fix the bugs so it does. :wink:

I tried with FreeBSD kernel. Outcome is 2 different crashes. Output is here:

http://web.me.com/dmarion/FreeBSD/integrated-as_crash.txt

I can provide more details if needed.

Thanks, Damjan. That's good information.

Crash #1 is an assembly source file. It's running into something it doesn't understand on the line indicated. The assertion failure is a secondary problem, and definitely shouldn't happen. As mentioned, though, the asm parser isn't ready for prime time yet, so I suspect this may be just the tip of the iceberg as far as the problems that (and similar) files would encounter.

Crash #2 is a C file, but is also asserting in the assembly parser, which indicates that there's inline assembly in the file somewhere that the parser doesn't know how to handle yet.

Seems that it fails even on simply inline asm. Here is test function:

void case2(unsigned int x)
{
__asm volatile( "mov %0, %0, ror #8\n" : "+r" (x));
}

Some Makefile magic should be able to take care of issues of the sort encountered in #1 (don't pass -integrated-as when compiling .S files).

Inline assembly is a bit trickier. Temporarily, if those files compile/assemble OK with the system assembler (i.e., don't have the rrx instruction mnemonic in them), we could work around by not using -integrated-as for them. That's pretty fugly, though, and would just be a quick workaround to allow you to keep making progress while the real issues get fixed.

How much inline asm is there in that file that's causing issues? if it's not too much, it might not be too bad to get at least that much of the asm parsing working. That would be general goodness and would help move you forward.

I tried to compile FreeBSD kernel using -integrated-asm and except ~30 files containing inline asm everything else went smoothly in compiling phase.
I removed -integrated-as for files with inline assembly and now linker fails:

error: Source object ata_all.o has EABI version 0, but target kernel.debug has EABI version 5

Seems that -integrated-as is producing EABI v5 files, while my binutils is producing EABI v0.

Is there any way to force EABI version 0?

Thanks,

To get -integrated-as working so that we don't need to go through the assembler at all should be mostly a matter of bug fixing, modulo inline assembly support. For non-trivial inline assembly, and to get a system assembler replacement based on the MC assembler, it'll be a bigger task. The ARM asm parser is currently in need of some tender loving care. That's coming soon, but it's a non-trivial task.

For -integrated-as, I would suggest giving it a try. I'm not completely sure how complete the support is for ELF, but I think it's in somewhat OK shape, at least. Worth trying. That would neatly avoid the problem if it works. If it doesn't, we should fix the bugs so it does. :wink:

I tried with FreeBSD kernel. Outcome is 2 different crashes. Output is here:

http://web.me.com/dmarion/FreeBSD/integrated-as_crash.txt

I can provide more details if needed.

Thanks, Damjan. That's good information.

Crash #1 is an assembly source file. It's running into something it doesn't understand on the line indicated. The assertion failure is a secondary problem, and definitely shouldn't happen. As mentioned, though, the asm parser isn't ready for prime time yet, so I suspect this may be just the tip of the iceberg as far as the problems that (and similar) files would encounter.

Crash #2 is a C file, but is also asserting in the assembly parser, which indicates that there's inline assembly in the file somewhere that the parser doesn't know how to handle yet.

Seems that it fails even on simply inline asm. Here is test function:

void case2(unsigned int x)
{
__asm volatile( "mov %0, %0, ror #8\n" : "+r" (x));
}

IIRC, this fails because the support for optional args isn't yet
supported for every instruction, only for the cases that people cared!
Please file bugs!

Hi Evan,

That's a good roadmap. We can definitely start testing with
integrated-as as of now. Last time I tried, all of them passed with MC
ELF, but we found some bugs on other tests when using our front-end,
which could be many things (I couldn't test with Clang). I have to get
back to it soon.

We're setting up a nightly test for LLVM, it's already running on
Linux (and I believe Windows), but we need OSX and native ARM-Linux
too. We should multiply that by three with integrated-as and MC ELF,
to get a good coverage. We'll report any bug along the way, hopefully
in the form of a patch+test. :wink:

The asm parser/disassembler could take a while, though, but that's
feasible in the long run, and I agree it's the right path.

cheers,
--renato