On Wednesday, 10 January 2018 at 14:17:53 UTC, Radu wrote:
> On Wednesday, 10 January 2018 at 11:13:17 UTC, David Nadlinger wrote:
>>  [...]
>
> David, indeed sem_post works correctly, I guess gdb interpreted the sequence in the wrong order.
>
> [...]

Have you ported much of druntime to Uclibc?  It currently assumes Glibc on linux by default, so if there are differences between the way the two handle such signals, it can cause problems.  For example, the Android Java Runtime intercepts SIGUSR1/SIGUSR2 and doesn't run their signal handlers, so I had to work around that issue:

https://github.com/dlang/druntime/pull/1851#discussion_r123886260

You may be running across a similar incompatibility, so I suggest you port all the version-dependent blocks of that module and its dependent modules first.

On Wednesday, 10 January 2018 at 15:56:52 UTC, Joakim wrote:
> On Wednesday, 10 January 2018 at 14:17:53 UTC, Radu wrote:
>> On Wednesday, 10 January 2018 at 11:13:17 UTC, David Nadlinger wrote:
>>>  [...]
>>
>> David, indeed sem_post works correctly, I guess gdb interpreted the sequence in the wrong order.
>>
>> [...]
>
> Have you ported much of druntime to Uclibc?  It currently assumes Glibc on linux by default, so if there are differences between the way the two handle such signals, it can cause problems.  For example, the Android Java Runtime intercepts SIGUSR1/SIGUSR2 and doesn't run their signal handlers, so I had to work around that issue:
>
> https://github.com/dlang/druntime/pull/1851#discussion_r123886260
>
> You may be running across a similar incompatibility, so I suggest you port all the version-dependent blocks of that module and its dependent modules first.

I missed a bunch of details that where killing the signal handling, thanks for the guidance!, various size differences on structs. Fixed now.

druntime tests are passing in release mode now.

The debug build fails with:

core.exception.AssertError@rt/sections_elf_shared.d(116): Assertion failure,

Code looks like:

    invariant()
    {
        assert(_moduleGroup.modules.length);
        static if (SharedELF)
        {
            assert(_tlsMod || !_tlsSize); // <-- fails
        }
    }

Stack trace:

#0  rt.sections_elf_shared.DSO.__invariant1() const (this=...) at sections_elf_shared.d:116
#1  0x0029e490 in rt.sections_elf_shared.DSO.__invariant() const (this=<error reading variable: Cannot access memory at address 0xe9>) at sections_elf_shared.d:67
#2  0x0029e4d8 in rt.sections_elf_shared.DSO.gcRanges() inout (this=...) at sections_elf_shared.d:104
#3  0x00293e14 in _D2rt6memory16initStaticDataGCFZ14__foreachbody1MFKSQBy19sections_elf_shared3DSOZi (sg=...) at memory.d:23
#4  0x0029e350 in _D2rt19sections_elf_shared3DSO7opApplyFMDFKSQBqQBqQyZiZi (dg=...) at sections_elf_shared.d:73
#5  0x00293de4 in rt.memory.initStaticDataGC() () at memory.d:21
#6  0x00284984 in rt_init () at dmain2.d:184
#7  0x002851d4 in rt.dmain2._d_run_main(int, char**, extern(C) int(char[][]) function).runAll() () at dmain2.d:478
#8  0x00285138 in rt.dmain2._d_run_main(int, char**, extern(C) int(char[][]) function).tryExec(scope void() delegate) (dg=...) at dmain2.d:454
#9  0x00285030 in _d_run_main (argc=1, argv=0xbefffd54, mainFunc=0xc5210 <D main>) at dmain2.d:487
#10 0x000c5394 in main (argc=1, argv=0xbefffd54) at __entrypoint.d:8
#11 0xb6e88a84 in __uClibc_main () from target:/lib/libc.so.1
#12 0x00000000 in ?? ()

I don't really understand that invariant, I see that those vars are initialized way before in the init part and have values, for example:

_tlsMod  = 0 and _tlsSize = 388


Stack trace:

#0  _D2rt19sections_elf_shared12scanSegmentsFNbNiKxS4core3sys5linux4link12dl_phdr_infoPSQDeQDe3DSOZv (info=..., pdso=0x307150) at sections_elf_shared.d:871
#1  0x0029ef18 in _d_dso_registry (arg=0xbefffbc8 "\001") at sections_elf_shared.d:455
#2  0x000c530c in ldc.register_dso ()
#3  0x000c5344 in ldc.dso_ctor.11test_runner ()
#4  0xb6fea548 in _dl_run_init_array () from target:/lib/ld-uClibc.so.0
#5  0xb6e889e4 in __uClibc_main () from target:/lib/libc.so.1
#6  0x00000000 in ?? ()

Any idea why this fails and how to fix?

On Sunday, 14 January 2018 at 21:33:28 UTC, Radu wrote:
> On Wednesday, 10 January 2018 at 15:56:52 UTC, Joakim wrote:
>> [...]
>
> I missed a bunch of details that where killing the signal handling, thanks for the guidance!, various size differences on structs. Fixed now.

Figured that was it, that's why I asked you a couple times how much you had ported druntime.

> druntime tests are passing in release mode now.
>
> [...]

_tlsMod and _tlsSize are extracted from shared libraries and then passed to __tls_get_addr to initialize thread-local storage for each library.  That invariant makes sure the TLS index _tlsMod isn't 0 along with a non-zero size, not sure why David checks for that.  It could be he doesn't expect the index 0 for a shared library whereas uClibc is okay with that?

I don't use this module or arbitrary shared libraries on Android/ARM, so I haven't had to mess with it.

On 15 Jan 2018, at 10:05, Joakim via digitalmars-d-ldc wrote:
> _tlsMod and _tlsSize are extracted from shared libraries and then passed to __tls_get_addr to initialize thread-local storage for each library.  That invariant makes sure the TLS index _tlsMod isn't 0 along with a non-zero size, not sure why David checks for that.  It could be he doesn't expect the index 0 for a shared library whereas uClibc is okay with that?

We inherited that from Martin's code – presumably, it's just never the case on glibc. If all the tests work with shared libraries (DMD test suite and runtime unit tests, plus druntime/test, as run by ctest), there is nothing to worry about.

 — David