SIGILL's on ARM32 while using valgrind

[igorsnunes]

Hi all,

I am currently debugging an application with valgrind in a raspberry pi and I came across some "Illegal Instructions" issues on "libcoreclr.so".

Not sure if these instructions are actually being executed, however, as they are being detected by valgrind, an "Illegal Instruction" signal is being raised.

See the messages below:

The first one concerns to sub.w instruction: SP is being used in Rd position and r8 in Rn (according to the ISA, if SP is being used as Rd, SP should also be in Rn, see http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BABFFEJF.html).

done.
0x04000a30 in _start () from /lib/ld-linux-armhf.so.3
(gdb) c
Continuing.
[New Thread 17257]

Thread 1 received signal SIGILL, Illegal instruction.
0x05f837fe in _DacGlobals::InitializeEntries(unsigned int) () from /home/pi/workspace-00032/edge/libcoreclr.so
(gdb) x/i $pc
0x5f837ff <_ZN11_DacGlobals17InitializeEntriesEj+3262>: sub.w sp, r8, #80 ; 0x50

I managed to bypass this SIGILL by patching valgrind, explicitly allowing this constraint (this probably shouldn`t be done). However, another SIGILL was raised, but this time it was located elsewhere.

(gdb) c
Continuing.
[New Thread 4291]

Thread 1 received signal SIGILL, Illegal instruction.
0x23f7d48e in ?? ()
(gdb) x/i $pc
0x23f7d48f: ldmia.w sp!, {lr}
(gdb)

Apparently, this one concerns to the use of only one register in the register list in instruction LDMIA. For more information, see: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489g/Cihcadda.html.

I wonder if these instructions are being emmited by the JIT compiler, or maybe this is a CLANG issue.

Thanks in advance!

PS:
more info about my environment:

First, I am running a container to publish my app. The app publishing process is located in build.sh.

docker run -v %ProductContainersFolder%:/product_containers --rm mcr.microsoft.com/dotnet/core/sdk:3.1 bash /product_containers/build.sh

The "dotnet publish" command is described below:

dotnet publish -c Release --framework netcoreapp3.1 -r linux-arm --self-contained yes --output .....

After publishing the app, I`m copying the whole environment (app+runtime+libs including libcoreclr.so) to my raspberry to run it there.

It's important to note that, if I don`t use valgrind, my application runs without problems on raspberry.

category:correctness
theme:codegen
skill-level:beginner
cost:small

[Dotnet-GitSync-Bot]

I couldn't add an area label to this Issue.

Checkout this page to find out which area owner to ping, or please add exactly one area label to help train me in the future.

[janvorli]

Apparently, this one concerns to the use of only one register in the register list in instruction LDMIA.

What's wrong with using one register there? The document you've pointed to says:

reglist
is a list of one or more registers to be loaded or stored, enclosed in braces. It can contain register ranges. It must be comma separated if it contains more than one register or register range.

As for the sub with SP

The first one concerns to sub.w instruction: SP is being used in Rd position and r8 in Rn (according to the ISA, if SP is being used as Rd, SP should also be in Rn, see

@dotnet/jit-contrib do we generate sub.w sp, r8, #80 form in JIT?

[igorsnunes]

Hi @janvorli ,

Thanks for your reply.

Concerning to the use of only one register, you are correct about that. But the documentation also points (in the restrictions section):

In 32-bit Thumb instructions:

• ...
• there must be two or more registers in the list.
  If you write an STM or LDM instruction with only one register in reglist, the assembler automatically substitutes the equivalent STR or LDR instruction. Be aware of this when comparing disassembly listings with source code.

So, this may lead to two possibilities:

• this is a valgrind issue: valgrind is expecting that the code was generated by a standard assembler, and it should accept only one argument on LDM/STM.
• this is a dotnet issue: it should do the assembler job (substituting the instruction).

Thanks.

[janvorli]

@igorsnunes ah, I've missed the restrictions section. I guess the case of LDMIA with one register in the list is something that works, but is not supported according to the doc, so we should not be emitting that.

[BruceForstall]

@dotnet/jit-contrib do we generate sub.w sp, r8, #80 form in JIT?

I can look into this, although in the case shown here it looks like that instruction is in native code (unless the symbols are incorrect).

[Spongman]

i'm seeing the same thing:

valgrind --tool=massif dotnet exec bin/Release/netcoreapp3.1/linux-arm/app.dll
==2241== Massif, a heap profiler
==2241== Copyright (C) 2003-2017, and GNU GPL'd, by Nicholas Nethercote
==2241== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==2241== Command: dotnet exec bin/Release/netcoreapp3.1/linux-arm/app.dll
==2241== 
--2241-- WARNING: unhandled arm-linux syscall: 389
--2241-- You may be able to write your own handler.
--2241-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--2241-- Nevertheless we consider this a bug.  Please report
--2241-- it at http://valgrind.org/support/bug_reports.html.
disInstr(thumb): unhandled instruction: 0xF1A4 0x0D50
==2241== valgrind: Unrecognised instruction at address 0x52444a5.
==2241==    at 0x52444A4: _DacGlobals::InitializeEntries(unsigned int) (in /home/me/app/bin/Release/netcoreapp3.1/linux-arm/libcoreclr.so)
==2241== Your program just tried to execute an instruction that Valgrind
==2241== did not recognise.  There are two possible reasons for this.
==2241== 1. Your program has a bug and erroneously jumped to a non-code
==2241==    location.  If you are running Memcheck and you just saw a
==2241==    warning about a bad jump, it's probably your program's fault.
==2241== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2241==    i.e. it's Valgrind's fault.  If you think this is the case or
==2241==    you are not sure, please let us know and we'll try to fix it.
==2241== Either way, Valgrind will now raise a SIGILL signal which will
==2241== probably kill your program.
disInstr(thumb): unhandled instruction: 0xF1A4 0x0D50
==2241== valgrind: Unrecognised instruction at address 0x52444a5.
==2241==    at 0x52444A4: _DacGlobals::InitializeEntries(unsigned int) (in /home/me/app/bin/Release/netcoreapp3.1/linux-arm/libcoreclr.so)
==2241== Your program just tried to execute an instruction that Valgrind
==2241== did not recognise.  There are two possible reasons for this.
==2241== 1. Your program has a bug and erroneously jumped to a non-code
==2241==    location.  If you are running Memcheck and you just saw a
==2241==    warning about a bad jump, it's probably your program's fault.
==2241== 2. The instruction is legitimate but Valgrind doesn't handle it,
==2241==    i.e. it's Valgrind's fault.  If you think this is the case or
==2241==    you are not sure, please let us know and we'll try to fix it.
==2241== Either way, Valgrind will now raise a SIGILL signal which will
==2241== probably kill your program.
==2241== 
==2241== Process terminating with default action of signal 4 (SIGILL)
==2241==  Illegal opcode at address 0x52444A5
==2241==    at 0x52444A4: _DacGlobals::InitializeEntries(unsigned int) (in /home/me/app/bin/Release/netcoreapp3.1/linux-arm/libcoreclr.so)
==2241== 
Illegal instruction

[BruceForstall]

@janvorli As far as I can tell, the JIT will never generate sub.w sp, r8, #80 form. Also, the jit never generates ldm form. From the info here, it looks like those must be coming from some kind of native code. I didn't see anywhere in the VM that would generate the ldm form.