From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cyan.elm.relay.mailchannels.net (cyan.elm.relay.mailchannels.net [23.83.212.47]) by sourceware.org (Postfix) with ESMTPS id B5802386EC08 for ; Wed, 7 Jul 2021 15:18:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B5802386EC08 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nadler.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=nadler.com X-Sender-Id: dreamhost|x-authsender|drn@nadler.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C0787841A4C; Wed, 7 Jul 2021 15:18:36 +0000 (UTC) Received: from pdx1-sub0-mail-a34.g.dreamhost.com (100-96-13-112.trex-nlb.outbound.svc.cluster.local [100.96.13.112]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5A563841D3C; Wed, 7 Jul 2021 15:18:36 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|drn@nadler.com Received: from pdx1-sub0-mail-a34.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.13.112 (trex/6.3.3); Wed, 07 Jul 2021 15:18:36 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|drn@nadler.com X-MailChannels-Auth-Id: dreamhost X-Hook-Tank: 78252de06bbdbcfb_1625671116607_1333857059 X-MC-Loop-Signature: 1625671116607:2652064363 X-MC-Ingress-Time: 1625671116607 Received: from pdx1-sub0-mail-a34.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a34.g.dreamhost.com (Postfix) with ESMTP id 117BC7F6BD; Wed, 7 Jul 2021 08:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=nadler.com; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type; s=nadler.com; bh=Es2ON++NX1OfQe3bFmO2gef+Tuo=; b= fRXx3EQDIE64JOoTaukp0y2nyrf2kn23NMkcMdU42MQcHMKoApjDJc/PDC2+MeeL X9Pn1YXpHpzFrnXdr+qZVVWFBeuZOHtymskvHGh1yqnx03bMHrafzTHvYqdDDMxs lHXVa25gbLVrcYOIBMADFskoDpEgIquA/cXDOx9byjE= Received: from [192.168.1.7] (pool-72-74-171-157.bstnma.fios.verizon.net [72.74.171.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: drn@nadler.com) by pdx1-sub0-mail-a34.g.dreamhost.com (Postfix) with ESMTPSA id A00677ED50; Wed, 7 Jul 2021 08:18:35 -0700 (PDT) Subject: Re: Help porting newlib to a new CPU architecture (sorta) To: Orlando Arias , newlib@sourceware.org References: <02319db3-b410-18e8-ac8a-049c54e753b5@gmail.com> <87d0cba4-b71a-a79b-cff6-891c384c20d5@SystematicSw.ab.ca> <2bb2d181-36e4-1cc6-bdff-9eb0aea895ec@gmail.com> <54a6bb07-717c-ddf2-3e84-822c523b9035@SystematicSw.ab.ca> X-DH-BACKEND: pdx1-sub0-mail-a34 From: Dave Nadler Message-ID: Date: Wed, 7 Jul 2021 11:18:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2021 15:18:43 -0000 Lots of architectures have *really* different addressing. AVR needs 20 or more bits for (pointers to) flash over 64kb. 16-bit x6 needs 20 bits for far pointers. GCC mostly thinks the world is flat (and AVR __flash extension is only C, aarrggg...). Some of us still support applications on those architectures! This might give you some ideas: http://www.nadler.com/backups/20210703_PROGMEM_notes.md Have fun, Best Regards, Dave On 7/7/2021 9:58 AM, Orlando Arias wrote: > Greetings, > > On 7/7/21 1:45 AM, Brian Inglis wrote: >> Function and object pointer inter-conversions are UB - daemons fly out >> your nose! For example, when code and data model pointer sizes are >> different, pointers are physically incompatible. > Yes, such is with the case of AVR. Attempting to cast a function pointer > to a data pointer and dereferencing writes to that new pointer is a nice > way to bring about disaster. > >>> However, the implementations I have seen would treat this pointer as >>> something in data memory, rather than something in program memory. >>> Actually modifying what fn_ptr points to would require the use of an >>> extension to the language [which would be implied if the behavior was >>> indeed UB or implementation defined]. Please correct me on this one. >> Works on von Neumann architecture implementations, or where mapping >> registers map the same address ranges for code and data, perhaps with >> different access modes. >> Modifying what a function pointer object points to is fairly common in >> C, as long as when they are used, they are (cast to) a pointer to a >> function of the correct type; c.f. qsort pointer to comparison function >> in its last argument, and Unix system driver interfaces which are >> effectively arrays of function pointers. >> > I have done similar to this before: mapping a page as RWX, writing to > it, then jumping to it to execute code. It was done as a way to > demonstrate shellcode injection in AMD64. I also had a few students do > something similar on an MSP430 for a homework [gave them a binary with a > vulnerability, had them reverse engineer it, then exploit it to trigger > certain behaviors to get points in the assignment]. > >> If you look at e.g the PDP11 architecture, somewhat similar 6800 series >> models, or the like, it had a number of mainly orthogonal general >> register addressing modes, including PC relative, indirect PC relative, >> and either with autoinc-/decrement, so it could use many registers to >> access "program" memory, absolute "program" addresses, and move through >> that space like an IP for threaded code, or as a subroutine stack, or >> access RO data in the instruction space directly. >> For example, to copy RO instruction space data to RAM, the move source >> register uses autoincrement PC relative addressing and the destination >> register uses autoincrement relative addressing from a RAM base address. > Speaking of, this sounds a lot like the MSP430 ISA. I do recall reading > somewhere that the MSP430 ISA was rather similar to the PDP11's. I can > not recall where I found that bit though. I have never used a PDP11 > before, acquiring [and possibly restoring] one is in my to do list. > > Anyway, thank you for your time and insights. > > Cheers, > Orlando. -- Dave Nadler, USA East Coast voice (978) 263-0097, drn@nadler.com, Skype Dave.Nadler1