From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp78.iad3a.emailsrvr.com (smtp78.iad3a.emailsrvr.com [173.203.187.78]) by sourceware.org (Postfix) with ESMTPS id B82783858019 for ; Tue, 18 Jan 2022 04:02:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B82783858019 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gc.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gc.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gc.org; s=20170911-w9iv0wsm; t=1642478572; bh=QaiRcmhlJA63vv0OrYAvV9j6f6seavj9xc05f1jWcnY=; h=From:Subject:Date:To:From; b=qB7pWEDwfbuu/faZnB0/s2CxSjOVXipDhp0JZKiccGV2nP70bzB5lMMD6+FlBMkY6 euYYDVUqz1b7hRNJdquSaInE+mJdk5sxMw+Kz0O7soLb92TfukXzYFJJJca+y+92HN 97kQlTZyhE3At97xZa/IO1d8DmAiSgfEUqCMLGLM= X-Auth-ID: mbox1@gc.org Received: by smtp34.relay.iad3a.emailsrvr.com (Authenticated sender: mbox1-AT-gc.org) with ESMTPSA id 0E3EC211A3 for ; Mon, 17 Jan 2022 23:02:51 -0500 (EST) From: Gilbert Coville Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: ns32k status Message-Id: Date: Mon, 17 Jan 2022 20:02:49 -0800 To: binutils@sourceware.org X-Mailer: Apple Mail (2.3273) X-Classification-ID: 9058575d-aa15-4987-a225-38f0195fae24-1-1 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, JMQ_SPF_NEUTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2022 04:02:54 -0000 I see that ns32k is on the chopping block once again. As I understand it, ns32k isn=E2=80=99t the last arch to use a.out, but = it is the last arch to use only a.out. With its removal, it would then = be possible to remove a.out completely. However, I do think that dropping ns32k from binutils would be a shame. = Although only a handful of people use it in its current form, it does = actually work quite well. Obviously, it=E2=80=99s no longer being used = for netbsd, but it is still useful for hobby embedded or bare metal-type = environments. I have started investigating what it would take to create an ns32k-elf = target. My initial thought was something like =E2=80=9CThere=E2=80=99s = already a working example of ns32k a.out, plus plenty of other elf = targets. It should be straightforward.=E2=80=9D Perhaps it is to = someone with years of binutils experience. However, the more I dig into = it, the more daunting it becomes. Adding to the problem is that there = isn=E2=80=99t a ns32k ELF addendum. We=E2=80=99ve looked pretty hard = and only found a reference to it in National=E2=80=99s documentation. = Most likely the document was vaporware. All we=E2=80=99re left with is = a value for e_machine. I had hoped to have some code to show by the = upcoming branch date, but that is clearly not going to happen. My primary request is that the removal of ns32k targets be postponed for = a release (or two). I don=E2=80=99t mind if ns32k-*-netbsd remains in = the obsolete list, but if the ns32k code and files are removed, it will = make the task significantly more difficult. I am open to any advice, or ridicule if necessary. Thoughts? Gilbert