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=-5.3 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, 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 7370B27375 for ; Mon, 19 Feb 2024 14:04:39 +0100 (CET) Received: (qmail 3074 invoked by uid 550); 19 Feb 2024 13:01:21 -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 2018 invoked from network); 19 Feb 2024 13:01:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=landley-net.20230601.gappssmtp.com; s=20230601; t=1708347864; x=1708952664; darn=lists.openwall.com; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=eDBetmNvuJWF4mJnWV09pCyCGoQrh40Viy7pgz7sbyM=; b=tXKl8yhARGa8fl541LmFJfcXx7DWVDc3KQPiryzdK5QBXgKopCJuEOBweGG64YvVCs oj5ijQBQWNqQH5EgZ8LHew3CtTWwUpbvbT7UPpaBuKZ6zhWi4WGUWhv67JxNQOMmP3EC xFjMfujP5d9to8JH+iZUuW0bQ4pgIeBZjU4OkUSlzFTJW7zoYPzOn4RzW9getC4N3a6U nIkbmo28bxmv0G6iA9R2pwzGLFzCyMNzg1nh+//9Pxi07cdReJHVUcDdj09NP6fVFOv5 Nlc5MZhl/0PWxltorYv8r3CCPDuknRb0J6qFUc9wyOKqy8qurtPIB+5zvaJHmRd4Yzn5 7hrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708347864; x=1708952664; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=eDBetmNvuJWF4mJnWV09pCyCGoQrh40Viy7pgz7sbyM=; b=M203Zx1IYTFHUUrfbbl0o45AUBwLaUO3As8XvG0iq6HcXyDW4pGATJ8FGTMmaBUTsa tnejlhwu0dqpkrsHo3NTe22EBmp64luQgKIS+K7iitX940ShVkdl4N0J73o3Bts9ooxX K9UrK6DcOWjyz9aTzQVZu2Up3gpBLk9sU0agmkG8TgLIuUJ+MfmC7e4l60qyUcUOFLNF d5c7AvNZLlmRm7jsYhq7IOSSOCMh2N9ch64D+kJtmfczXKtAPghE0jG7968iKiVu0Lfx cbz3lZwu5iNYlVqWAPmXxnVhUlNtN5F+nD0dVRCcwmbVVwpnRZe/xBPcSHzBbBYKaqd9 ZnUA== X-Gm-Message-State: AOJu0Yw6GSjt3TAlkuREUFhq8hWSiKtPp7yuA/K3ntY/9aIBngWwWVLy kKYM2cefCrX6yNWWzb0F3zO1pOKgqBfdFugTYFsWvBDpP5ihyY0EgKoOeQwf6RU= X-Google-Smtp-Source: AGHT+IHylU1hVR5apmFCBRkFma6YZbXa66nkrTGZRqV1566cdBlYb2Ghrpty9Oa7zCVwqKamBAWMtw== X-Received: by 2002:a05:6870:206:b0:21e:5008:cf5b with SMTP id j6-20020a056870020600b0021e5008cf5bmr4562910oad.7.1708347864182; Mon, 19 Feb 2024 05:04:24 -0800 (PST) Message-ID: <4a8eb6c6-b6bf-2841-e56b-c435ee80e86d@landley.net> Date: Mon, 19 Feb 2024 07:12:16 -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: Rich Felker , Valery Ushakov Cc: musl@lists.openwall.com, toybox References: <349f4e17-8027-c521-eeb3-aa69e8f2b5a4@landley.net> <20240218013428.GJ4163@brightrain.aerifal.cx> From: Rob Landley In-Reply-To: <20240218013428.GJ4163@brightrain.aerifal.cx> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [musl] Re: Not sure how to debug this one. On 2/17/24 19:34, Rich Felker wrote: > On Sun, Feb 18, 2024 at 12:45:35AM +0300, Valery Ushakov wrote: >> On Fri, Feb 16, 2024 at 19:48:27 -0600, Rob Landley wrote: >> >> > https://git.musl-libc.org/cgit/musl/tree/src/signal/sh/sigsetjmp.s FYI the next round of debugging I had queued up was cutting and pasting the sigsetjmp+setjmp assembly blob inline in the code (either as a C asm { } directive or my own .s->.o nailed to the side of the link) and removing one instruction from the end of the testfunc() at a time until the crash went away. (Doesn't matter if it _works_, the point is does it _return_. Find the instruction that poked the bear.) I was just AFK most of the weekend... > The only problem with the sh implementation is that, due to limited > displacement range for load/store instructions, we have to add 60 to > the sigjmp_buf base address to get the base register for accessing the > saved return address and r8. This takes place in a temp register r6. > However, the last line of this code path, the delay slot after the > tail call to __sigsetjmp_tail, erroneously uses r4 (the base > sigjmp_buf pointer) as the base for restoring r8: > > mov.l @(4+8,r4), r8 > > This corrupts the caller's saved register file. If I'm not mistaken, > it overwrites the caller's r8 with the caller's r11. > > Presumably Rob didn't actually hit a crash in sigsetjmp, but just > inferred the crash was there via printf debugging. The actual crash > must be in the caller once it gets back control with the wrong value > in r8. I saw that the printf after the sigsetjmp did not trigger, yes. Why was the pending question... > This has been an area I've wanted to have testing for for a long time, > but I don't have a really good idea for how to implement the test. We > would want the compiler to generate code that puts lots of > intermediates in as many call-saved registers as possible, calls > setjmp, then calls another function that *also* puts pressure on the > register allocation and then calls longjmp. If it's okay for the test > to be arch-specific, this could just work via __asm__ register > constraints and a call to setjmp from asm, but I'm not sure if that > would be a good way to do things in libc-test... > > In any case, thanks to everyone who participated in this. This is a > rather bad bug and a nice one to get fixed up in the release window! Very much so. Thank you. I pulled musl-git but didn't see a commit yet, lemme know when I can build a new test toolchain to confirm the fix. > Rich Thanks, Rob