Openwrt Linux Uclibc ARM GC issue

[Radu]

On Wednesday, 10 January 2018 at 11:13:17 UTC, David Nadlinger 
wrote:
> On 10 Jan 2018, at 0:27, Radu via digitalmars-d-ldc wrote:
>> From what I can see in gdb 'thread_resumeHandler' is to blame, 
>> it looks like 'sem_post( &suspendCount )' will immediately 
>> trigger the resumeSignal and the call for 'sigsuspend( &sigres 
>> )' is never made.
>
> You mean thread_suspendHandler? Perhaps single-stepping through 
> the code and having a look where the stack is corrupted would 
> yield some insight? Is there possibly some ABI incompatibility 
> caused by callWithStackShell?
>
> sem_post shouldn't cause anything to happen on the calling 
> thread itself; and it is explicitly documented to be re-entrant 
> w.r.t. signals.
>
>  —David

David, indeed sem_post works correctly, I guess gdb interpreted 
the sequence in the wrong order.

Moving the break point to the thread_resumeHandler I can see that 
the handler gets called, but I think you are right about the ABI, 
observe:

Thread 2 "druntime-test-r" received signal SIGUSR2, User defined 
signal 2.
0xb6e88648 in ?? () from target:/lib/libc.so.1
(gdb) bt
#0  0xb6e88648 in ?? () from target:/lib/libc.so.1
#1  0xb6e50dd0 in sigsuspend () from target:/lib/libc.so.1
#2  0x001b46e8 in 
core.thread.thread_suspendHandler(int).op(void*) (sp=0xb572f900 
"$F\033") at thread.d:467
#3  0x001b483c in core.thread.callWithStackShell(scope 
void(void*) nothrow delegate) (fn=...) at thread.d:2600
#4  0x001b45f8 in thread_suspendHandler (sig=10) at thread.d:487
#5  0xfffffffe in ?? ()
(gdb) c
Thread 2 "druntime-test-r" hit Breakpoint 1, thread_resumeHandler 
(sig=12) at thread.d:494
warning: Source file is more recent than executable.
494                 assert( sig == resumeSignalNumber );
(gdb) i f
Stack level 0, frame at 0xb572f4d8:
  pc = 0x1b487c in thread_resumeHandler (thread.d:494); saved pc = 
0xfffffffe
  called by frame at 0xb572f4d8
  source language d.
  Arglist at 0xb572f4c8, args: sig=12
  Locals at 0xb572f4c8, Previous frame's sp is 0xb572f4d8
  Saved registers:
   r11 at 0xb572f4d0, lr at 0xb572f4d4
.......
(gdb) disas
(gdb) disas
Dump of assembler code for function thread_resumeHandler:
    0x001b4864 <+0>:     push    {r11, lr}
    0x001b4868 <+4>:     mov     r11, sp
    0x001b486c <+8>:     sub     sp, sp, #8
    0x001b4870 <+12>:    ldr     r1, [pc, #52]   ; 0x1b48ac 
<thread_resumeHandler+72>
    0x001b4874 <+16>:    ldr     r1, [pc, r1]
    0x001b4878 <+20>:    str     r0, [sp, #4]
    0x001b487c <+24>:    ldr     r0, [sp, #4]
    0x001b4880 <+28>:    ldr     r1, [r1]
    0x001b4884 <+32>:    cmp     r0, r1
    0x001b4888 <+36>:    bne     0x1b4894 <thread_resumeHandler+48>
    0x001b488c <+40>:    mov     sp, r11
=> 0x001b4890 <+44>:    pop     {r11, pc}
    0x001b4894 <+48>:    ldr     r0, [pc, #20]   ; 0x1b48b0 
<thread_resumeHandler+76>
    0x001b4898 <+52>:    add     r1, pc, r0
    0x001b489c <+56>:    mov     r0, #13
    0x001b48a0 <+60>:    mov     r2, #238        ; 0xee
    0x001b48a4 <+64>:    orr     r2, r2, #256    ; 0x100
    0x001b48a8 <+68>:    bl      0xf00c8 <_d_assert>
    0x001b48ac <+72>:    mulseq  r4, r8, r5
    0x001b48b0 <+76>:                    ; <UNDEFINED> 
instruction: 0x00117bd1

(gdb) ni
0x001b4890 in thread_resumeHandler (sig=-2) at thread.d:499
499             }
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0xfffffffe

It looks that PC is invalid causing the segmentation fault.