From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) by sourceware.org (Postfix) with ESMTPS id A33F53858D35 for ; Fri, 20 Sep 2024 02:53:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A33F53858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A33F53858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::1132 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1726800788; cv=none; b=jZ/uBYVuo2Jv8UCSpy80Yz+51qite/ZzhGylTgReirQ5c3qwf/2OswphsUwHNYuwynEjB4EnjN9A74tzL1L8tuk3thh8gZinmA9SzKihNZiEEBze8ZPP+Wp4Kmd4qkpXfK7vAseLuqeo0gC5MuaK1HPdpzdYYjnrt3GmtmTEKgI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1726800788; c=relaxed/simple; bh=z7t91mWLW0ckBRa7Xkc4QXqGL+/k3XpsT0v1wpa8BzA=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=JAOT6Xxhi4lLPwUoXPwPj64SNzdATPQ18/ObFH6I2wZE9pcRN+XQMFT/AI3TdC+cytlJgD0SR+QpA3eafUUYhQ0o7+g7+HUMicFIY8wGE6b+hPGMGD4KB3bvpjgJlHaolFry55Gdqe7gwB/z7z/5YWmTKGl5FaWo6/XWrkEIznE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-6de15eefdd3so9463127b3.0 for ; Thu, 19 Sep 2024 19:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726800785; x=1727405585; darn=sourceware.org; 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=aZ0KVP+aI48P8l1uks1dxMQNgb0tGeTNrxMRgBNv0k4=; b=OeUnlExDBu8PjJZt1G5BrpYu+Iil2zg+AbJuussPgiyxe1i7m1774sYwos6iXCqdIa xkFEXPToybMW38cFehkiY4RCnRPioJMNIQ2Erj86lKBWFfqQXulaKpr/dyKnN+wI+v9J DJNYrBXIaP8sSW6VKpoEBRceHnJyqha/zAQkWw7WBQ+hd7fANUI0LWn5043WYHZterTb WR/vraIV3Iy6CNjH42uzo7hxgxVwSgVrhx/FSZKQgSQ4AQ+7h6X7+ewrteUlBXAcx8ND mqwnHDInNKKOpBEfJKromdhTob6KfpWHIC1nRFXNVxRcB62xDt7hCDhceGILjy1eD9v9 DQtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726800785; x=1727405585; 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=aZ0KVP+aI48P8l1uks1dxMQNgb0tGeTNrxMRgBNv0k4=; b=IANc6xCYYGrhv/kzhAC7+V4mRuqJlyuBj501GdXHx9/uDbaLglvGOOnEO8xqs2P82X 8+xdlnAlp/M4+a3vgdS0GdetM+25ak/lZkPUcEcFouCTlbebIXkVq7CKRHLSfjrr0RqS ylXURt9ekF4CJWrkr96AE81ys3yWyZEElLEfUaDFrSCkgaQP1V5N//o4GRCGq9jbfPjw ScCyigLqqXTONM+2My9hTzyUx9js9mBC+A9jyqsrhQgccA+mZDgP48IlE4RFfOQ8piCy HzOUxm2pBHlSJRg9LsOOjySygk8+v0fKmwHvLVLt/GJxqnYFKc87WiD9rDtiWgxqFSmW TxrQ== X-Forwarded-Encrypted: i=1; AJvYcCUaLZqUVS/jmWzt7OooRLeBO4mSea7hokI/SWM8Ai+DCEQ6k2wefgmMITcT0fvZaRzkfsxTeHitAg==@sourceware.org X-Gm-Message-State: AOJu0Yzjaaorirej652WvLjnYqh0pCPEVKP6iyM1YbWZLek41vLvqjQX JFE4PL4DtOZQk/3hvXoI6Gs7MHuTCDJ3dpRYo9DuUkoZUvtzWFcZOqGSrtwQf1I2E92Q9bkW+SS 5HINhFZ6of7ciauVZfnu/C+0qGqA= X-Google-Smtp-Source: AGHT+IFJVuTwx2MjxsLxAX3AVznCDaAJgiDS0i2BSyXNpxlqk43r/zkYjdcelm+4s2uSgYGVluH616qVqaVrzy1sq+M= X-Received: by 2002:a05:690c:250f:b0:6db:d5e8:d612 with SMTP id 00721157ae682-6dff2868f55mr6509377b3.23.1726800784852; Thu, 19 Sep 2024 19:53:04 -0700 (PDT) MIME-Version: 1.0 References: <298bc306-38e3-4010-80fe-90bd12a2a522@redhat.com> <87v7yrbc10.fsf@gentoo.org> In-Reply-To: <87v7yrbc10.fsf@gentoo.org> From: "H.J. Lu" Date: Fri, 20 Sep 2024 10:52:28 +0800 Message-ID: Subject: Re: [PATCH] ld: ensure build-id is placed near ELF headers To: Sam James Cc: Nick Clifton , Andrew Burgess , binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3011.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Sep 20, 2024 at 4:54=E2=80=AFAM Sam James wrote: > > Nick Clifton writes: > > > Hi Andrew, > > > > [Sorry for being so late in responding to your email] > > > >> When an executable is built with the --rosegment option GDB is no > >> longer able to find the build-id of the executable from a core file. > > > > For problems like this it really helps if you create a bug report > > using the Sourceware bugzilla system. This allows us to track the > > problem and any discussion surrounding it. It also means that we > > can refer to the bug ID in comments in the code. > > > > In order to save you time however, I have gone ahead and created > > a bug report for you: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=3D32100 > > > >> This patch aims to fix this by placing the build-id first. The > >> build-id will then be included within the same LOAD-able segment as > >> the executable content, just as the ELF headers are. With this patch > >> in place GDB is once again able to find the build-id from a core > >> file. > > > > Unfortunately that patch breaks the intention of the --rosegment > > option by restoring two loadable, read-only segments to the executable. > > > > Here is an example: > > > > $ cat hello.c > > > > extern int printf (const char *, ...); > > int i =3D 42; > > const int * j =3D & i; > > int main (void) { return printf ("hello world %d\n", * j); } > > > > $ gcc -fPIC -Wl,-z,noseparate-code hello.c > > $ readelf -lW a.out | grep LOAD > > > > LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x0006d= 4 0x0006d4 R E 0x1000 > > LOAD 0x000df8 0x0000000000401df8 0x0000000000401df8 0x00022= 8 0x000230 RW 0x1000 > > > > $ gcc -fPIX -Wl,-z,separate-code hello.c > > $ readelf -lW a.out | grep LOAD > > > > LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x00051= 0 0x000510 R 0x1000 > > LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x00015= 5 0x000155 R E 0x1000 > > LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x0000d= c 0x0000dc R 0x1000 > > LOAD 0x002df8 0x0000000000403df8 0x0000000000403df8 0x00022= 8 0x000230 RW 0x1000 > > > > $ gcc -fPIX -Wl,-z,separate-code -Wl,--rosegment hello.c > > $ readelf -lW a.out | grep LOAD > > > > LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x00115= d 0x00115d R E 0x1000 > > LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x0002d= 4 0x0002d4 R 0x1000 > > LOAD 0x002df8 0x0000000000403df8 0x0000000000403df8 0x00022= 0 0x000228 RW 0x1000 > > > > $ gcc -fPIX -Wl,-z,separate-code -Wl,--rosegment hello.c -fuse-ld=3Dp= atched-linker > > $ readelf -lW a.out | grep LOAD > > > > LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x00039= c 0x00039c R 0x1000 > > LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x00015= d 0x00015d R E 0x1000 > > LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x00024= c 0x00024c R 0x1000 > > LOAD 0x002df8 0x0000000000403df8 0x0000000000403df8 0x00022= 0 0x000228 RW 0x1000 > > > > (I invented the "-fuse-ld=3Dpatched-linker" option to keep the presen= tation simple. In > > reality I used a full path to a linker built with your proposed patch= applied). > > > > The section to segment mapping is changed by using --rosegment, but wit= h your patch > > applied we still get an early read-only segment containing the note sec= tions. > > > > I think that what is needed is a patch to move all of the read-only seg= ments to > > before the read-execute segment. But this weill need testing. > > I'm reading over the rest of the thread, so apologies if this got > addressed later, but did we add a testcase like this? Hi Andrew, Why does GDB need the build-id to be placed close to the ELF header? Can't GDB read the program header and search for the build-id in PT_NOTE segment? If GDB needs help, we can add a PT_BUILD_ID segment. --=20 H.J.