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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, NICE_REPLY_A autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 31241 invoked from network); 3 Mar 2023 21:20:33 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 3 Mar 2023 21:20:33 -0000 Received: from mail.posixcafe.org ([45.76.19.58]) by 9front; Fri Mar 3 16:19:01 -0500 2023 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posixcafe.org; s=20200506; t=1677878659; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=unQ0mCv1zo7IZ5yTcVlHVPz3BDh9y3aBk8cqLmcQ4go=; b=IrHsnY4+7eoD2h2poCoi4nIoVt6DDea0p9J3T6n2nY5u42lJkcY0CPXXqkxczRy4eJkU2M NsWn0eAyzXJ6Bhn5QtN5L5QnGls7np4Hgqpq1yS3yyRVWN4LETlR7sSBoKMweAbsIKHAps caoAjGnFgu8USC7iYOGBYLKOkFeSJho= Received: from [192.168.168.200] (161-097-205-025.v4.mynextlight.net [161.97.205.25]) by mail.posixcafe.org (OpenSMTPD) with ESMTPSA id fc74631c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for <9front@9front.org>; Fri, 3 Mar 2023 15:24:19 -0600 (CST) Message-ID: Date: Fri, 3 Mar 2023 14:18:29 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Content-Language: en-US To: 9front@9front.org References: <859F297B22C45B7453E14CCF75E203C8@felloff.net> From: Jacob Moody In-Reply-To: <859F297B22C45B7453E14CCF75E203C8@felloff.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: extensible managed SOAP over AJAX proxy rich-client shader Subject: Re: [9front] Re: [PATCH] game boy advance header target for 5l Reply-To: 9front@9front.org Precedence: bulk On 3/3/23 13:59, cinap_lenrek@felloff.net wrote: >> I dont want to do relocation, I just want to know >> why external programs that only work under assumptions >> of how the a.out was linked are preferable to just >> having the linker output correct files. > > Sorry, then i must have misundersood you. > >> If everyone else is in agreement that this kind of header >> code should only be done in external programs, should that >> code also be moved to be external or deleted? > > I do not see a need to be dogmatic about this at all > or force a decision. > > I do not have any skin in this game nor do i have a gameboy. > > Was just pointing out why an external tool would only solve > half the problem in this case. But i think we agree here. > > A external tool made perfect sense for uimage as we want to > generate both an a.out (for debugger and /dev/reboot) and a > uimage for uboot. Linking is quite expensive compared to just > writing out a header and copying some data out of a file and > calculating a checksum. > > For the gameboy rom image problem, my first guess would be to > just generate the header using the assembler and pass that > as the first object to the linker and have the linker geneate > headerless image. I ended up writing an aout2gba that does work as intended. I think this may still be quite useful, I am considering teaching games/gba how to load a gba a.out file (for debug info), so being able to generate both may be useful. In porting a more complicated rom, I realized that plan9 specific init code is unavoidable anyway due to needing to setup R12: MOVW $setR12(SB), R12 /* load the SB */ Somehow I had missed that this preamble would be needed. Given that we need an l.s entrypoint for this anyway, I can just stuff the header in there and encode the entry point manually to just jump down after the header as we discussed. I am working on a /sys/src/cmd/mkone equivalent and some plumbing, I'll post another diff soon. Thanks, moody