[Bug 213937] stable/11 -r307797 on BPi-M3 (cortex-a7): ktrace misreports bad svc (SIGSYS) number

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213937

            Bug ID: 213937
           Summary: stable/11 -r307797 on BPi-M3 (cortex-a7): ktrace
                    misreports bad svc (SIGSYS) number
           Product: Base System
           Version: 11.0-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: arm
          Assignee: freebsd-arm at FreeBSD.org
          Reporter: markmi at dsl-only.net

A separately reported stable/11 -r307797 clang 3.8.0 code generation error for
armv6/cortex-a7 in bootstrapping lang/gcc6's xgcc's cc1 leads to the cc1
process sometimes executing:

0xbfbf6d20 in ?? ()
1: x/i $pc  0xbfbf6d20: svclt   0x00bf6ef0

(0xbfbf6d20 is a stack address before the problem occurs).

But the ktrace for this does not report the 24 bit value from that instruction
as the syscall number. It instead reports (from an example):

34629 cc1      CALL  [-17504]
34629 cc1      RET   [-17504] -1 errno 78 Function not implemented
34629 cc1      PSIG  SIGSYS SIG_DFL code=SI_KERNEL

-17504 == 0xff...fBBA0 (2's complement)

truss has eventual crash problems for handling this svclt in the cc1 process
but via gdb on truss there is:

(gdb) print t->cs.number
$5 = 580828064

FYI: 580828064 = 0x229EBBA0
which partially matches -17504's binary pattern.

It turns out that just prior page fault activity has addresses with the 0x229e
part of the above:

34629 cc1      CALL 
mmap(0,0x4000,0x3<PROT_READ|PROT_WRITE>,0x1002<MAP_PRIVATE|MAP_ANON>,0xffffffff,0x1c,0,0)
34629 cc1      RET   mmap 568225792/0x21de7000
34629 cc1      PFLT  0x21de7000 VM_PROT_WRITE
34629 cc1      PRET  KERN_SUCCESS
34629 cc1      PFLT  0x21de8000 VM_PROT_WRITE
34629 cc1      PRET  KERN_SUCCESS
34629 cc1      PFLT  0x21de9000 VM_PROT_WRITE
34629 cc1      PRET  KERN_SUCCESS
34629 cc1      PFLT  0x21dea000 VM_PROT_WRITE
34629 cc1      PRET  KERN_SUCCESS
34629 cc1      PFLT  0x229e8000 VM_PROT_WRITE
34629 cc1      PRET  KERN_SUCCESS
34629 cc1      PFLT  0x229e9000 VM_PROT_WRITE
34629 cc1      PRET  KERN_SUCCESS
34629 cc1      PFLT  0x229ea000 VM_PROT_WRITE
34629 cc1      PRET  KERN_SUCCESS
34629 cc1      CSW   stop user "ast"
34629 cc1      CSW   resume user "ast"
34629 cc1      PFLT  0x229eb000 VM_PROT_WRITE
34629 cc1      PRET  KERN_SUCCESS
34629 cc1      PFLT  0x229ec000 VM_PROT_WRITE
34629 cc1      PRET  KERN_SUCCESS
34629 cc1      CALL  [-17504]
34629 cc1      RET   [-17504] -1 errno 78 Function not implemented
34629 cc1      PSIG  SIGSYS SIG_DFL code=SI_KERNEL

But I've no clue if the 0x229e's in t->cs.number are actually from the PFLT's
or not.

There is a separate bugzilla submittal for the truss crash associated with
this. John Baldwin has worked some on fixing truss so that it does not crash
for this.

But that is a somewhat distinct issue from the syscall numbers not matching the
svclt's 24 bits of selection number:

svclt   0x00bf6ef0
vs.
0xff...fBBA0 and also 0x229EBBA0

So this is reporting the ktrace (and truss internal) inaccurate figures
compared to the instruction's actual pattern.

Note: I have made the assumption that the 24 bit number in the svclt
instruction is used and so is what should be reported. If not then the value
comparison needs to be based on whatever else is used.

-- 
You are receiving this mail because:
You are the assignee for the bug.