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=-1.3 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,HEADER_FROM_DIFFERENT_DOMAINS,HK_RANDOM_FROM, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL 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 F0F4B225B3 for ; Thu, 4 Apr 2024 10:44:41 +0200 (CEST) Received: (qmail 22289 invoked by uid 550); 4 Apr 2024 08:44:35 -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 22236 invoked from network); 4 Apr 2024 08:44:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712220265; x=1712825065; darn=lists.openwall.com; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=C9HZZFn3LenIyuIwg9ebMW6PP4isqOymWi8wUrW0Hfk=; b=KHaqkBKyCoEd/0hKUDrJxb/6nN1xFU3gqX1wHS97MCVi3YfT1wJgXn3ocWyBhrycmK RHwTjU8Gg8ujAWHQGKNuMJvF395cTNmT5RvL7EfMaRcyRYKobvBLBAPKM0lTyQa/FqiT e+60KQ/gihJWe2s9O1YliMABp2QnHFrHTPzwyLJnp5WlnBkbg+hzzHXjzXNk4s+MH9zs GNHbMfWMn4fuZ5jI63vJnmdvSMOIOqxj9a2RCyRLIoYWYI39djau5aNcMwvZ4elXj3OW vtNmg5dBZy1oEViN81JX1YRH6EjL6U8diFBI2iCKsQhgKJoAbWgJw75WM/SctnEy1fdO izdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712220265; x=1712825065; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=C9HZZFn3LenIyuIwg9ebMW6PP4isqOymWi8wUrW0Hfk=; b=Z0amoBO3unYLywpVdQvdHCLx2fgxosrsm1zzCgfHExfiY9fyHunDeP4oQDX81qAmLI xQ/zATeFWkadE85Ja9OyAxjiEBw2gjGy8bJesNcYBU0WENM6TlJGcmy13ZreImdS5jmb GuPDvpEL/9ZmnG21qfQHb8rAW7DkPkOwk/rm+3Wpj2ElpRQKTQC8Mnh5bv3reNRqDKS9 r1+Dp7LehAPZ9SJ1oPbyjbWBCF/axV0jaD56YE1tIe4kkrVvR9dqjOOhbrGa581fxZtg peQZK0i1OAMc4i69MUN1tZ/Bj6AGumfLCCrTr9FLjXKVIcsy+hUAnJaX2QQSW44uSePA SZ8g== X-Gm-Message-State: AOJu0Ywg8567tO/21IvnEdxItOjLMPhf6ypwcmxj+mb9osBFCwKV2bCh eWEbHAnBrjUgPOJN5ySIwOBJxWJjtsHEn/1JWkyNUHVYdJZbGIJNpWhWq7Vwi2Je54PA3fxknIW cS0LZA2TP5GoUAGO8ACp7I5ffyvs= X-Google-Smtp-Source: AGHT+IFLmEzmopxFNQhMXOFYeqecdo/jWrYXahJ+5/ysbzzPn6I99kXTf7r26h9hSeI5Fe5/Oxn/1YS2ycB+oRfBsu4= X-Received: by 2002:a05:6300:8086:b0:1a3:e4fe:f6f1 with SMTP id ap6-20020a056300808600b001a3e4fef6f1mr1874316pzc.58.1712220264665; Thu, 04 Apr 2024 01:44:24 -0700 (PDT) MIME-Version: 1.0 References: <20240328200319.4016902-1-jcmvbkbc@gmail.com> <20240328230116.GM4163@brightrain.aerifal.cx> <20240329014824.GG32430@brightrain.aerifal.cx> <20240403205555.GO4163@brightrain.aerifal.cx> <20240403214555.GP4163@brightrain.aerifal.cx> In-Reply-To: <20240403214555.GP4163@brightrain.aerifal.cx> From: Max Filippov Date: Thu, 4 Apr 2024 01:44:13 -0700 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [RFC v2 0/2] xtensa FDPIC port On Wed, Apr 3, 2024 at 2:45=E2=80=AFPM Rich Felker wrote: > > On Wed, Apr 03, 2024 at 04:55:56PM -0400, Rich Felker wrote: > > On Tue, Apr 02, 2024 at 07:30:57PM -0700, Max Filippov wrote: > > > On Thu, Mar 28, 2024 at 6:48=E2=80=AFPM Rich Felker = wrote: > > > > On Thu, Mar 28, 2024 at 05:48:50PM -0700, Max Filippov wrote: > > > > > On Thu, Mar 28, 2024 at 4:00=E2=80=AFPM Rich Felker wrote: > > > > > > On Thu, Mar 28, 2024 at 01:03:17PM -0700, Max Filippov wrote: > > > > > > > functional/dlopen fails with the > > > > > > > src/functional/dlopen.c:39: dlsym main failed: (null) > > > > > > > There's no failure in the dlsym call, but the pointers don't = match. > > > > > > > > > > > > Is this something related to canonical function descriptors? Is= it > > > > > > musl's fault or a bug in the tooling? I suspect the latter. > > > > > > > > > > Yes, dlsym() returns the pointer into def.dso->funcdescs, > > > > > but (void *)main returns the pointer to the canonical function > > > > > descriptor. I understand that the linker must use the > > > > > R_XTENSA_FUNCDESC relocation for the locally defined > > > > > global symbol instead of the .rofixup entries. > > > > > > > > If the xtensa FDPIC ABI is going to be that the linker makes canoni= cal > > > > function descriptors, I think that's workable, but the dynamic link= er > > > > would need a way to find and usee them. I'm not sure how that would > > > > work. > > > > > > > > The simple (but probably less efficient) way is to copy what SH did > > > > and have the dynamic linker always be responsible for them (load > > > > descriptor address from GOT). > > > > > > I've built and tested SH FDPIC toolchain, it fails this test in exact= ly > > > the same way: pointer loaded directly does not match the pointer > > > returned by dlsym(). > > > > Yes, I've been able to reproduce this and it's a clear bug. There does > > not seem to be any way the dynamic linker could find these GOTFUNCDESC > > slots to use them as a canonical address for the function, and > > moreover, they're not even unique; there would be one per library. > > > > The code path for legitimize_pic_address in sh.c that emits > > GOTFUNCDESC has the wrong logic. A simple fix would be just making > > that path never be taken, but I'm not sure if that would break use of > > GOTFUNCDESC for pure-call purposes. > > > > The condition should probably be something like: if it's just used for > > a call (if this is even needed; pure call is probably handled > > elsewhere) or if the function is static or hidden, use GOTFUNCDESC; > > otherwise, use GOT. > > > > I might try patching it and see what happens. > > Attached patch seems to fix it. I'm not sure if this is the most > idiomatic way to write the predicate in gcc sources, but it should be > correct. It's not what I observe. On my side it doesn't change the result of the dlopen test, and it also breaks building of all statically-linked tests. There are no relocations against the symbol 'main' neither in the test built with the original gcc nor in the test built with the patched one. dlopen.o built with the original gcc had R_SH_GOTOFFFUNCDESC relocation against the symbol 'main', dlopen.o built with the patched gcc has R_SH_GOTOFF instead. The code generated with the patched gcc: if (dlsym(g, "main") !=3D (void*)main) { 28c: 50 d1 mov.l 3d0 ,r1 ! 0
28e: 8c 31 add r8,r1 290: 12 61 mov.l @r1,r1 292: 13 62 mov r1,r2 294: 8f 91 mov.w 3b6 ,r1 ! 1e0 296: ec 31 add r14,r1 298: 23 65 mov r2,r5 29a: 1c 54 mov.l @(48,r1),r4 29c: 83 6c mov r8,r12 29e: 4d d6 mov.l 3d4 ,r6 ! 130 2a0: 03 06 bsrf r6 2a2: 09 00 nop 2a4: 03 61 mov r0,r1 2a6: 4c d2 mov.l 3d8 ,r2 ! 0
2a8: 8c 32 add r8,r2 2aa: 20 31 cmp/eq r2,r1 2ac: 27 89 bt 2fe ... 3d8: 00 00 .word 0x0000 3d8: R_SH_GOTOFF main doesn't look right to me at all. Using R_SH_GOTOFF for the symbol in text doesn't make sense. Using R_SH_GOT (AFAIU that's what you meant it to be) doesn't make sense to me as well, as the value stored in the GOT would be the address of the main() entry point, not of its descriptor. I believe that gcc need to generate R_SH_GOTFUNCDESC instead of R_SH_GOTOFFFUNCDESC for this test to work correctly, and that the linker need to put R_SH_FUNCDESC relocation against that GOT entry, so that the dynamic linker could put there the address of the function descriptor associated with the symbol. --=20 Thanks. -- Max