From nobody Sun May 10 01:41:50 2026 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4gCltz4W70z6KLHr for ; Sun, 10 May 2026 01:41:15 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "pelorus.zefox.org", Issuer "pelorus.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4gClty5b36z3ghQ for ; Sun, 10 May 2026 01:41:14 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Authentication-Results: mx1.freebsd.org; none Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.18.1/8.18.1) with ESMTPS id 64A1foT1085817 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 9 May 2026 18:41:51 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.18.1/8.18.1/Submit) id 64A1fojp085810; Sat, 9 May 2026 18:41:50 -0700 (PDT) (envelope-from fbsd) Date: Sat, 9 May 2026 18:41:50 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-current@freebsd.org Subject: Re: ar: error: libclang.a: 'ParseDecl.o': section header table goes past EOF [So far: unable to reproduce, even based on llvm19 involvement] Message-ID: References: <413d71d1-6e18-4c7f-8844-d85c304d0504@yahoo.com> <33436574-0b2b-4db8-a69f-85df46af12a6@yahoo.com> <7e29fc11-9fcc-4a71-97bb-b709862e35e1@yahoo.com> <9ff7855f-2b48-4cac-a82d-2cbd9912dc27@yahoo.com> <6ae013cb-2e90-4e08-bac4-001fc8bc051c@yahoo.com> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US] X-Rspamd-Queue-Id: 4gClty5b36z3ghQ X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated On Sat, May 09, 2026 at 04:43:29PM -0700, Mark Millard wrote: > On 5/7/26 17:50, Mark Millard wrote: > > On 5/7/26 16:46, bob prohaska wrote: > >> . . . > > > > > > I'm still no closer to having an idea what else to do for investigation. > > So far, you have the only known example failure context. > > > > > > I've only had one idea for a very limited test sequence, based on > referencing the Parse_ParseDecl.o.meta file: > > ) Start from a status of already having the bad Parse/ParseDecl.o in place. > > ) # cd /usr/obj/usr/src/arm.armv7/tmp/obj-tools/lib/clang/libclang > > ) # mv Parse/ParseDecl.o Parse/ParseDecl.o.bad > (Or analogous. Below presumes that name I listed.) > > ) Execute the: > > # c++ -O2 -pipe . . . -o Parse/ParseDecl.o > > command listed in the Parse_ParseDecl.o.meta file. > > That command is long enough that simple copy/paste might split the line > up into multiple lines. (I've run into such things in various contexts.) > So care to get the command right/complete may be needed. > > The questions for the results are largely based on comparison/contrast > with the original bad file: > > ) Does the command or the console report some sort of message that might > be relevant? If yes, what are the details, otherwise conintue. > > ) Are Parse/ParseDecl.o.bad and the new Parse/ParseDecl.o the same by by > size and (most?) content? If yes, you have replicated the problem and > report that. (There could be timestamps or uninitialized pad bytes or > such complicating the content judgment if the sizes are the same.) > > ) Is the new Parse/ParseDecl.o big enough compared to avoid the prior > error messages? A simple command that would report the too-small size > problem would be something like: > > # readelf Parse/ParseDecl.o > readelf: error: 'Parse/ParseDecl.o': unable to continue dumping, the > file is corrupt: section header table goes past the end of the file: > e_shoff = 0x131190 > > If it does not produce such an error message, then things are very > different. The file might even be correct to continue the build with. > Report the status. > > > At some point you will likely want to delete Parse/ParseDecl.o.bad . > It looks as if running make kernel-toolchain somehow worked around the failure. It completed successfully and is now running a normal buildworld, which is in the building libraries stage. Hopefully it'll finish within a day or two. Thanks for writing, apologies if I jumped the gun! bob prohaska