From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 29068 invoked from network); 14 Jun 2023 11:52:12 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 14 Jun 2023 11:52:12 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 61EA34147A; Wed, 14 Jun 2023 21:52:07 +1000 (AEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by minnie.tuhs.org (Postfix) with ESMTPS id 002054127B for ; Wed, 14 Jun 2023 21:51:53 +1000 (AEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id A702F5C00D9 for ; Wed, 14 Jun 2023 07:51:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 14 Jun 2023 07:51:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=papnet.eu; h=cc :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1686743512; x=1686829912; bh=eb C1mQITEHNOAMg4UoZTWfznNs+H+dQq/WJkstGCMFw=; b=iwHxEHDYKcjjS8hnbM QsJIpsfCnS/a9iXr64duu8YaDVTN2bBH4BOQ4BxNB+RfplgW6Vv65zk4e+XKOgeh yZGMESkzU/hA+TFcgEHC/NK9+Zn2S9Z+th7gHveogqkpq1iEJb+tPXFuo52lvbMf idB+dBvbsMK3GunbZotHrNWSOZc+G1zQ/tah+LT8eyJJ1nKjPlxlxi+BFQunnA9a kHM6QyL6oocn38yZkvVEPwzXHHkt8vLv8H3LEgFVFb8OEIujFSjdqq3+OQJuiGZJ iz61iYitPhzEWe/MRKb3sNSBBadRQuPw23kz9AJrNTtG6cdiyvxJ9JsllnpwzN8r 7y2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1686743512; x=1686829912; bh=ebC1mQITEHNOA Mg4UoZTWfznNs+H+dQq/WJkstGCMFw=; b=lrapIrQsssmL2ZmdA8zKcwNCOJiYe lQcoHjuHPI+viV7sKQ0Ul/PuzbwPdbjUTt1yZJf7i6iXc8fH5ot5yhzNuZq5xcKx 1+2ya7apbjmcEjKiryzPBADhqL1/GcfH5HljwJJ4t5gETuvG0Ej/l4PK5q63krBp AVDkgKFFqZGbgvAx0Nf31iaiakadvzgBWsweQJrSICTtMmMMhSP/HykmnNR3w8n8 K1NUmhVacMOwmyrRLsx7QyitlZ0oM6UPOgUIIxyZKYTR5pKM1V/Uf/5tcPXDCF0u RU+eEZk515kcCJ9fa2XyhAB9c+0D94abdFo+h9Px4w7oR/76a1g7/A6wQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedvtddggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesthdtre dttddtvdenucfhrhhomheptehnghgvlhhoucfrrghpvghnhhhofhhfuceorggrphesphgr phhnvghtrdgvuheqnecuggftrfgrthhtvghrnhepudeglefghefhfeegfeettefgkedthf elleettdfhieehjeffffeghffgleetvdeunecuffhomhgrihhnpehsqhhuohiivgdrnhgv thenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrg hpsehprghpnhgvthdrvghu X-ME-Proxy: Feedback-ID: i47c14439:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 14 Jun 2023 07:51:51 -0400 (EDT) Date: Wed, 14 Jun 2023 13:51:47 +0200 From: Angelo Papenhoff To: tuhs@tuhs.org Message-ID: References: <1e651370-3ada-e211-c277-409d6563500d@f4grx.net> <202306080331.3583Vrw7057546@ultimate.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Message-ID-Hash: QQOAG34XFU73ABZ6ZPJG5QERAGXFFESK X-Message-ID-Hash: QQOAG34XFU73ABZ6ZPJG5QERAGXFFESK X-MailFrom: aap@papnet.eu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Software written in B List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Thank you two for finding this! I did some disassembling yesterday and have uploaded brt1.s and brt2.s to my site now: http://squoze.net/B/brt/ (I haven't actually assembled them yet, there may be mistakes) Some observations: - The 'chain' format is actually a linked list and not a list of addresses. Phil and I both got this wrong. - The "Init" string is an error message if for some reason the B init chain didn't run or main doesn't look like a function - The cmdline arguments overwrite part of the init code. There's about 80 bytes of space for them before it overwrites the code that builds the argv vector - brt2.s is only to mark the beginning of the stack I also saw some differences in the bilib code but haven't really analyzed that part (yet?) Would be really great if we could get all the files disassembled and decompiled and restore the source code for everything :) Best, Angelo On 08/06/23, segaloco via TUHS wrote: > > The signature I would expect from binary B code of this era would be > > that the generated code from each source file starts with a branch (or > > jmp) around the contents of the file, to a "jsr r5, chain" followed by > > a zero terminated list of addresses (which I guessed were addresses of > > address words that needed to be fixed up). > > Looking a little closer I think that is what this is, because each file is an a.out header, then a jmp, followed by what I presume is B object code, then the destination of the jmp at that jsr r5 that passes into a routine that I think is then what handles that 0-terminated table of address words. All of the files have a similar bit up to the data word this opening process increments, so I suspect those are the bounds of brt1, from the opening vector (that the header of the B object jumps to) to the data flag that gets set by the inc operation. > > My assumption is that the B objects were stamped with a jmp that simply jumped to whatever the first address past the end was, so then brt1 had to be physically right there to accept flow. After that point the remaining bits in the B files aren't as similar, but what I can say is I don't see anything on the tail end of these binaries that is consistent enough between them to peg as a brt2. Instead each seems to be a slightly different jumble of interpreter routines themselves. At least I think, this is a very high level assessment though, I haven't fully broken any of these into individual parts yet. > > By the way, one characteristic of this supposed brt1 code is that it checks that the first word after the jump in the B object is 40022(8) (which is the in-core address of the next word in the B object btw). If it is not present, or the B runtime did not set the data flag indicated above as the end of brt1, then it simply prints "Init\n" on stdout and exits. Only if both this B "magic number" and the flag indicating proper entry are set does it seem to proceed rather than just printing Init and exiting. > > Not sure what this means, or what the reasoning behind this behavior is, but that explains the "Init" string in each binary, it is also part of the B runtime. > > - Matt G.