From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) by sourceware.org (Postfix) with ESMTPS id E3AC3387090F for ; Fri, 12 Mar 2021 09:32:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E3AC3387090F Received: by mail-pj1-x1033.google.com with SMTP id lr1-20020a17090b4b81b02900ea0a3f38c1so3011581pjb.0 for ; Fri, 12 Mar 2021 01:32:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HSYLo7sBQnn/TUDS0dWnE6Rdaxae8IhWgjBYyFmLl80=; b=le/0eqgUAC8j4o/6WsSBJAfGD/o9/KXJRrFYLSpsHRXLgtY5vTiaJjmvQCWsNm5rVi ZICFEVSPyVmirTE84E1jXylN8gZO2f4oRCSqPFso+mNlo4diQ25aFzfMTQ+sTcnbx04x lQOL0o7TlG4aPJkxKzvexSuSYR9/x8/TPSqkcwcivqLs6hk+cnxMXwjuOC+upVOb8kBl JAxdP4S/XrwkaO1hJqYMRcUTUjbn9veYx/JGqQV9MYkFIc7MHvyOCx3VoKh9h2uPJK79 NwQH2GPllp9G3s+8NQJ0pZXDiSLkMozIc4qStW/o5FKP8NfYY/f6gEpZhm6wfAksMDfG MYOQ== X-Gm-Message-State: AOAM532V66CPxRCgKg8Mp2QsxmQqhx8pVS53bFo80rWOMMUTUMcavi6N fQTMY7U8w0xT5axus/4P6DWqJeZIWTMaZ28qibJ2SWu7qdA= X-Google-Smtp-Source: ABdhPJxTQZCl+4NKwDVlkmZDxe1p/CP/UVdDSOW4HlTvaFauXyzq7gCnOyG5lkQTYEm5d1bzUFap7oujd9jjP4ZPNyo= X-Received: by 2002:a17:90a:f403:: with SMTP id ch3mr13454765pjb.126.1615541529606; Fri, 12 Mar 2021 01:32:09 -0800 (PST) MIME-Version: 1.0 From: Alessandro Carminati Date: Fri, 12 Mar 2021 10:31:33 +0100 Message-ID: Subject: MIPSEL GLIBC sem_init() not shared To: libc-help@sourceware.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2021 09:32:12 -0000 I'm currently developing an application that is meant to run on Linux for MIPSEL platform. The application uses POSIX semaphores inside one of its DSO, and the attention in my case is for the sem_init() function used inside one DSO on which the app depends. The application is currently using the GLIBC_2.31, but I observed the same phenomenon also using the GLIBC_2_26. Now I'm going to explain the anomaly and the current status of the troubleshooting. All happened when I noticed a process waiting on a semaphore wouldn't wake when the semaphore incremented its value. Just for the records, I'm aware that for multiprocessing, the semaphore must sit in a memory area that is shared between the processes that use the semaphore. Now, investigating further using strace, I also noticed that the semaphore I initialized using sem_init(&semaphore, 1, 0) resulted in being private, despite I initialized it to be shared. futex(0x774ce0bc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, {tv_sec=1615204364, tv_nsec=515578961}, FUTEX_BITSET_MATCH_ANY) = -1 ETIMEDOUT (Connection timed out) The next step I performed on this issue has been to debug using gdb the semaphore initialization process. There I discovered that in this particular combination, MIPSEL - LINUX - GLIBC, the sem_init() exists in two versions: $ mipsel-linux-objdump -T libpthread.so.0 | grep sem_init 00012e30 g DF .text 00000040 (GLIBC_2.0) sem_init 00012dd0 g DF .text 00000060 GLIBC_2.2 sem_init For some reason, the linker decided to link my code against the older (not supporting shared semaphores) instead of the newer. Looking at the GLIBC code, particularly where the sem_init() is implemented (/nptl/sem_init.c), I realized that sem_init() is an alias and that two symbols identify the functions' implementation univocally. My next move then has been to call directly the function I needed __new_sem_init(), just to be sure any linker alchemy I'm not aware of would interfere with my intentions. Unfortunately, the symbol is not exported, and it can't be used. Looking at my library liba.so which uses sem_wait(), sem_init(), and sem_post() I noticed that these symbols are all exported by libpthread.so.0. $ mipsel-linux-nm -D libpthread.so.0 | grep sem_ 00014a10 T sem_clockwait 00013784 T sem_close 00012e70 T sem_destroy 00012e70 T sem_destroy 00013b14 T sem_getvalue 00013b00 T sem_getvalue 00012e30 T sem_init 00012dd0 T sem_init 000131b8 T sem_open 00014ab0 T sem_post 00014b90 T sem_post 00014508 T sem_timedwait 00013f40 T sem_trywait 00013fac T sem_trywait 00013920 T sem_unlink 00013eb0 T sem_wait 00014020 T sem_wait But looking at the liba.so dependencies, I've been surprised by the fact that the library depends only on the main libc library (libc.so.6) and has no dependency on libpthread.so.0 where the actual sem_* symbols are implemented. $ /lib/ld-2.31.so --list /usr/lib/liba.so linux-vdso.so.1 (0x7ffaa000) libc.so.6 => /lib/libc.so.6 (0x77ddc000) /lib/ld-2.31.so (0x77f8a000) I guess this might be related to my problem, but I have no clue how to link these two facts. How the liba.so could be compiled and linked using symbols its dependencies do not provide? $ mipsel-linux-objdump -T libc.so.6 | grep sem 000fab80 g DF .text 00000070 GLIBC_2.0 semget 000fabf0 g DF .text 000000b0 GLIBC_2.2 semctl 000faca0 w DF .text 00000074 GLIBC_2.3.3 semtimedop 000359d0 g DF .text 00000074 GLIBC_2.0 sigisemptyset 00149854 g DF .text 000000b0 (GLIBC_2.0) semctl 000fab60 g DF .text 00000018 GLIBC_2.0 semop $ How to force the GNU linker to link against sem_init@@GLIBC_2.2 instead of sem_init@GLIBC_2.0?