From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id E98982B13B for ; Sat, 17 Feb 2024 02:40:54 +0100 (CET) Received: (qmail 11419 invoked by uid 550); 17 Feb 2024 01:37:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 11384 invoked from network); 17 Feb 2024 01:37:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landley-net.20230601.gappssmtp.com; s=20230601; t=1708134040; x=1708738840; darn=lists.openwall.com; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=k7OU9y8VH5u3Ee0N70XdZKj7qpfUVAnpyge3Dki8SQ0=; b=gXaMJmslXnqs9wYdRl0GDkxF2RjUReVPiQYqVN4b+KPF9ASQcsF0mT8uCfS4LdP5W+ k9BqL6soSBeEePpNj8tRDEJRAfOdiGOChTHUlgdTjtDcHKhkqg7i7TH1r65/8QkSlNeq kCUdEiGbYUCQ/LdnVrNh5jukxvlxsIOcz7vivh/PVPcErCIXX4ykSms5miEpknRQQZho zI0S6R0H7KlVSdWA7G5HdzEmxzEZCIvdxJ6m2Cc3oasH8MfwqWGNs9Zj9q6WDKC0vlua dSM2dAczGXGAzEqCL7XpfXxz6OXZZe+BlRSN/u56QDVwi1qXGpoUKA8Z4RpCg8Rpqu60 tevg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708134040; x=1708738840; h=content-transfer-encoding:subject:from:to:content-language :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=k7OU9y8VH5u3Ee0N70XdZKj7qpfUVAnpyge3Dki8SQ0=; b=iPHWNPoalCoNXEio9+ITyNi8WVOqGBY5d974d/yK1cbLDfFwIAnIu7ejMckOZOcF1F x2+ATlLbvCtPjquLFrHbNJV5E+v5gmLxhY0qD2VZy31xX1GhITKk0k2FvA2jLL1vsPcb QAgn0I8y29+fZ+/ww/XBwUQnwIVIAIg16WxZ4I3C24pNPptj/E+QDaE4ziNmP/7b95az 6h3GK6cDv2owuFEwsSQAdhQP/ZsZB4l96ouWsyZNSHJPGa2uvlUcWAArEIGEveRHsN9H EX4B8fKVwqVH/prboap869t1j9xfoyp/3L24yX8DLAKSfZO459kYlcGCLeeh1t4PG436 eIxA== X-Forwarded-Encrypted: i=1; AJvYcCUqqXffHEQCZg9l9MxH2Aae25Pwq+6/I19fL3OOzKpjgLKnagjvlTnLScVERryXDzjciu4NpVM22lsrXrnaSvYFJ6eFa2NIqw== X-Gm-Message-State: AOJu0YzyxhT729rp/PQ7SyHZQch6TpNW+qlqTnzIAg9kgCj97xpgkJQV JaYxaH+kjI/nI1CR00UmIriz5yKnurxF9KK0d21zaAD3IE4Sy1oCXkuEZmiFOj7dXNkOxxOpJUo CUdiwRA== X-Google-Smtp-Source: AGHT+IHNyEkVwciKzAq1z7oq8h3rGhH7APt2W+PsIG9AFcjtGFMSrxptgPpIHuYVDWUVYxLV4C0qJQ== X-Received: by 2002:a05:6808:1646:b0:3be:494e:9379 with SMTP id az6-20020a056808164600b003be494e9379mr6843968oib.16.1708134040006; Fri, 16 Feb 2024 17:40:40 -0800 (PST) Message-ID: <349f4e17-8027-c521-eeb3-aa69e8f2b5a4@landley.net> Date: Fri, 16 Feb 2024 19:48:27 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US To: toybox , musl From: Rob Landley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [musl] Not sure how to debug this one. While grinding away at release prep, I hit a WEIRD one. The qemu-system-sh4 target got broken by commit 3e0e8c687eee (PID 1 exits trying to run the init script), which is the commit that changed the stdout buffering type. It's not the kernel, if I use the last release kernel with the new root filesystem I see the problem, and newly built kernel from today's git with last release's initramfs.cpio.gz boots to a shell prompt. The actual _problem_ is that sigsetjmp() is faulting (in sh.c function run_command()), for NO OBVIOUS REASON. Calling memset() to zero the struct before the sigsetjmp() works fine, but the sigsetjmp() call (built against musl-libc) never returns. Not siglongjmp, _sigsetjmp_. Which means it's failing somewhere in: https://git.musl-libc.org/cgit/musl/tree/src/signal/sh/sigsetjmp.s And I dunno how to stick a printf into superh assembly code. The sigjmp_buf lives on the stack, but I confirmed it's 8 byte aligned, and not even straddling a page boundary. I can access variables I stick before and after it, so it can't be some kind of "fault due to guard page" weirdness? (I suppose the optimizer may be invalidating that test, I could try adding "volatile"...) While debugging I made the problem GO AWAY more than once by sticking printfs() and similar into the code, but that's not FIXING it. Adding another sigjmp_buf declaration and call to sigsetjmp() right at the start of the function works fine (although the other one in the place it's in now still fails). I confirmed that sigsetjmp() is annotated returns_twice in musl (but even if it _wasn't_ problems would show up when you did a longjmp, it wouldn't manifest as the first call to setjmp never returning. This isn't making it to the line after the function on the first pass through, even if I move it outside the if(). I confirmed it happens with both gcc 11.2 (musl 1.2.4?) and the older gcc 9.4 toolchain (musl 1.2.3? I think? It would be nice if musl actually had a way to identify the version of installed library binaries). I do not currently have a superh build of gdbserver and corresponding host gdb that understands foreign binaries, and the last time I built gdb as part of a cross compiler was many moons ago. I'm open to suggestions, this one's funky. (The problem with trying to configure the kernel to produce core dumps and compare against the readelf -d output is it's running as PID 1. Um... maybe kgdb? Still think I need to build a host cross-gdb to connect to it though...) It would be really nice if somebody who understood the assembly could spot something... Rob