From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-20807-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	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 C2D0D200E3
	for <ml@inbox.vuxu.org>; Sat,  6 Apr 2024 05:00:47 +0200 (CEST)
Received: (qmail 25953 invoked by uid 550); 6 Apr 2024 03:00:40 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 25891 invoked from network); 6 Apr 2024 03:00:39 -0000
Date: Fri, 5 Apr 2024 23:00:51 -0400
From: Rich Felker <dalias@libc.org>
To: Thorsten Glaser <tg@mirbsd.de>
Cc: musl@lists.openwall.com, 1068350@bugs.debian.org,
	debian-glibc@lists.debian.org, doko@debian.org
Message-ID: <20240406030050.GT4163@brightrain.aerifal.cx>
References: <Pine.BSM.4.64L.2404032356000.11666@herc.mirbsd.org>
 <20240404104428.GA3766212@port70.net>
 <20240404105408.GB3766212@port70.net>
 <Pine.BSM.4.64L.2404041942130.18654@herc.mirbsd.org>
 <20240404202641.GS4163@brightrain.aerifal.cx>
 <Pine.BSM.4.64L.2404042035130.18654@herc.mirbsd.org>
 <Pine.BSM.4.64L.2404042102310.18654@herc.mirbsd.org>
 <Pine.BSM.4.64L.2404050019190.18654@herc.mirbsd.org>
 <Zg956D6oPYIOTz15@voyager>
 <Pine.BSM.4.64L.2404050501580.18654@herc.mirbsd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Pine.BSM.4.64L.2404050501580.18654@herc.mirbsd.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] Re: Bug#1068350: =?utf-8?Q?musl?=
 =?utf-8?Q?=3A_miscompiles_=28runtime_problems=29_on_riscv64_and_s390x_wit?=
 =?utf-8?Q?h_static-pie_=E2=86=92_seem?= =?utf-8?Q?s?= to be a toolchain bug
 after all, it does too hit glibc

On Fri, Apr 05, 2024 at 05:04:37AM +0000, Thorsten Glaser wrote:
> Markus Wichmann dixit:
> 
> >can check with readelf -r what the relocation types are. If they are not
> >relative, they will not be processed.
> 
> Gotcha! They are all R_390_RELATIVE except for:
> 
> 000000045ff0  001100000016 R_390_64          0000000000042c58 u_ops + 70
> 000000045ff8  001100000016 R_390_64          0000000000042c58 u_ops + 0
> 000000047020  001100000016 R_390_64          0000000000042c58 u_ops + 80
> 000000047088  001100000016 R_390_64          0000000000042c58 u_ops + 80
> 0000000470a8  001100000016 R_390_64          0000000000042c58 u_ops + b8
> 000000047220  001100000016 R_390_64          0000000000042c58 u_ops + 80
> 000000046900  002600000016 R_390_64          0000000000015af8 c_command + 0
> 000000046940  000700000016 R_390_64          0000000000017238 c_exec + 0
> 000000046ab0  002000000016 R_390_64          0000000000016a80 c_trap + 0
> 000000047090  002500000016 R_390_64          00000000000430ac initvsn + 0
> 000000047278  005500000016 R_390_64          0000000000047438 null_string + 2
> 
> That’s our missing strings.

Is there anything weird about how these objects were declared that
might have caused ld not to resolve them statically like it should? It
seems odd that these data symbols, but not any other ones, would be
left as symbolic relocations.

Rich