From nobody Mon Jul 22 16:41:40 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4WSQzC18lQz5RFph; Mon, 22 Jul 2024 16:41:43 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WSQzB6SZVz45lZ; Mon, 22 Jul 2024 16:41:42 +0000 (UTC) (envelope-from melounmichal@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-52f025ab3a7so2094174e87.2; Mon, 22 Jul 2024 09:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721666500; x=1722271300; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:reply-to:user-agent:mime-version:date:message-id:from :sender:from:to:cc:subject:date:message-id:reply-to; bh=qU9ryzyvFC2Rkw9YhZxE0lEBoF2scWHKmmjwv6I5dLQ=; b=nRAoz3vqauEjd8srcLtB3q70zgL5FbinltR1NtKJcG/23/ZgtslL3mhtuoAERDLL61 OR+YBvQWsWRT/W08R8FzwygVyg7olPsmpcwrp7bMO1VYWd5TynhCv6Sw4ZLqOKDqxsgM bqtFQ+sQ5SFe/jNqK78av1tZOpSme4cm2lQfkAw39dsWEPO+j9jBb6mkQ2KMmC6tqdm7 m7U0x+ZYxVzla9hokFKXVKedcLJxIpD0W0WxJNFAqL7TeaBIbDpOGbeJfT5oOqhKqLin JKrEzNKyoq4BlnevN91na+CMETknSF+ecVpeL29JwEH8hEZecdQDTVgJxUW0Lw145hKK g4Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721666500; x=1722271300; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:reply-to:user-agent:mime-version:date:message-id:from :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qU9ryzyvFC2Rkw9YhZxE0lEBoF2scWHKmmjwv6I5dLQ=; b=gGWMuTRHOESn1UgJoWqedfAO3rEiVng69KqM6VwVma8MpBD3QVCTNOEq3EG/CLGHSZ jVBJflFkHSGinxsD5Q1IixjRsYBKwZcT269DE05Hk0ml0STrSbb1dIg5ciCvz6SBOeam gCiFEnPY+7Z09KJfChUBiOYlwQOccy09CbqwNUhxLuSZsWau1ielOBo/Nxetj6NuZpGg N4UjJ5P802FKb5A5luvMwMPowd1BtDUlODYFhGxOP711tazoXe+9d4GzhluZXEJK94al SdHEXK8Jkxn/XYuBELvkcInBQF5SKgPA3DK+ULq0HwguQ/6uaVPN3UxnJW3nHZ7je3st 25jQ== X-Forwarded-Encrypted: i=1; AJvYcCXUo1bdBTD3qRXy2A2/zU2LpNiV4BeNu3doDQid94QM4yJLeMG0vSqlDdXIBgeZFLYSwekXDTt0kpsd+j9Qtk8J0+2eZdy01B7XPGA8F5ufRXXDrVFhGTrq X-Gm-Message-State: AOJu0YylFrXWZu7QY4PeJ6l0eeJcUIfBAQBJd2qiRBnwqPilcAHtsdtR v2AD2hKAbsNl4TBBiK3X5Z/tPl9DxK8wDYGDIMnggI9HEwBr5Oer X-Google-Smtp-Source: AGHT+IF+u2UPryo9qY5q46iAOkZ7x9k8Kgje/0w15Kfgmm6QT6vLI8bOHLrHrFf5XFh2x+zB8t5zeg== X-Received: by 2002:a05:6512:1056:b0:52c:dea0:dd55 with SMTP id 2adb3069b0e04-52ef8d96526mr5295883e87.24.1721666499765; Mon, 22 Jul 2024 09:41:39 -0700 (PDT) Received: from ?IPV6:2001:67c:14a0:5fe0:45a9:3330:c09f:56e8? ([2001:67c:14a0:5fe0:45a9:3330:c09f:56e8]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a7a3c7b6e92sm442046766b.57.2024.07.22.09.41.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jul 2024 09:41:39 -0700 (PDT) From: meloun.michal@gmail.com X-Google-Original-From: mmel@freebsd.org Message-ID: Date: Mon, 22 Jul 2024 18:41:40 +0200 List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: mmel@freebsd.org Subject: Re: armv7-on-aarch64 stuck at urdlck To: Mark Millard Cc: FreeBSD Current , "freebsd-arm@freebsd.org" , "kib@freebsd.org >> Konstantin Belousov" References: <724db42b-5550-4381-8277-2971e6b3e8f1@freebsd.org> <86185657-e521-466b-89e2-f291aaac10a6@freebsd.org> <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> Content-Language: cs, en-US In-Reply-To: <0EF18174-8735-46A4-BD71-FFA3472B319F@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Queue-Id: 4WSQzB6SZVz45lZ On 22.07.2024 18:26, Mark Millard wrote: > On Jul 22, 2024, at 06:40, Michal Meloun wrote: > >> On 22.07.2024 13:46, Mark Millard wrote: >>> On Jul 21, 2024, at 22:59, Michal Meloun wrote: >>>> I don't want to hijack the original thread, so I'm replying in a new one. >>>> >>>> My tegra track current, has been running 24/7 by building kernel/world and kde5 in a loop for a few years now. But I have never encountered the aforementioned lockup in native armv7. >>>> >>>> I have seen usermode mutex lockup in arm32 jail on aarch64, but only very rarely (once a month or so) and all my attempts to reproduce it in a more deterministic way have failed. Also, I don't think I've ever seen this with the debug version of libc. >>>> >>>> Unfortunately I also failed to reproduce given lockup using dlopen_test.c, neither on native armv7 or arm32 jail. >>>> >>>> Michal Meloun >>> What is the output of: >>> # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ 0-9]|.*_rtld_get_stack_prot)" >>> in your armv7 context(s)? Does it include for likes of: >>> QUOTE >>> Symbol table '.symtab' contains 911 entries: >>> 903: 000000000001b9ac 16 FUNC GLOBAL DEFAULT 11 _rtld_get_stack_prot >>> END QUOTE >>> ` >>> vs. not? >>> Note that the "debug version of libc" being involved likely means that >>> DEBUG_FLAGS was defined. That in turn likely means that strip is not >>> being used. In such a case, I expect that the .symtab entry for >>> _rtld_get_stack_prot (and more) exists for such a context. >> At tis time, I have standard (thus stripped, non-debug) version of runtime linker library installed. Thus it have only dynamic relocation record for _rtld_get_stack_prot: >> >> root@tegra124:~/dlopen_test # readelf -a /libexec/ld-elf.so.1 | grep -E "(^[^ 0-9]|.*_rtld_get_stack_prot)" >> ELF Header: >> Elf file type is DYN (Shared object file) >> Entry point 0x1449c >> There are 10 program headers, starting at offset 52 >> Program Headers: >> There are 23 section headers, starting at offset 0x1a448: >> Section Headers: >> Key to Flags: >> Dynamic section at offset 0x19fa4 contains 15 entries: >> Relocation section (.rel.dyn): >> r_offset r_info r_type st_value st_name >> Symbol table '.dynsym' contains 27 entries: >> 5: 000000000001ba0c 16 FUNC GLOBAL DEFAULT 12 _rtld_get_stack_prot@@FBSDprivate_1.0 (11) >> Notes at offset 0x00000174 with length 0x00000018: >> Histogram for bucket list length (total of 6 buckets): >> Histogram for bucket list length (total of 27 buckets): >> Version symbol section (.gnu.version): >> Version definition section (.gnu.version_d): >> Attribute Section: aeabi >> >> ------ >> >> root@tegra124:~/dlopen_test # ./dlopen_test >> root@tegra124:~/dlopen_test # > > Just to be sure . . . > > Did you at some point "pkg install cairo" (or analogous) so that > the following (or some vintage) were in place? > > # ls -lodT /usr/local/lib/libcairo.so* > lrwxr-xr-x 1 root wheel - 21 Apr 29 19:45:15 2024 /usr/local/lib/libcairo.so -> libcairo.so.2.11704.0 > lrwxr-xr-x 1 root wheel - 21 Apr 29 19:45:15 2024 /usr/local/lib/libcairo.so.2 -> libcairo.so.2.11704.0 > -rwxr-xr-x 1 root wheel - 1118272 Apr 29 19:45:15 2024 /usr/local/lib/libcairo.so.2.11704.0 > > # file /usr/local/lib/libcairo.so.2.11704.0 > /usr/local/lib/libcairo.so.2.11704.0: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (FreeBSD), dynamically linked, for FreeBSD 15.0 (1500018), stripped > > (Installing cairo would also install other things it needs.) > > For the failing contexts, the a.out from dlopen_test.c will only > hang if the library (and what it requires) is actually there to > load. > Yep, i have cairo installed (but compiled from sources, not installed by pkg). And i have verified that dlopen() return success. In the meantime I tried all combinations (debud/stripped) of ld_elf and libthr. All combinations work without problems on the native system and in arm323 jail. Btw, gdb has long had problems with stepping inside ld_elf. It's better to run the test program without it and connect to the test program to get the "correct" stack trace. Michal Meloun