From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) by sourceware.org (Postfix) with ESMTPS id E42D23855024 for ; Wed, 7 Jul 2021 13:57:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E42D23855024 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qv1-xf34.google.com with SMTP id c5so1039579qvu.11 for ; Wed, 07 Jul 2021 06:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:references:from:subject:cc:message-id:date:user-agent :mime-version:in-reply-to; bh=3WLlgdfqOsfnbyakpDifa4ARaz1FLQOTf4zT0WIqxgc=; b=T7Nw/Pu8RajGLaQptJ0eP88BcN49n5u+JKtC8F0V8wm0yteDle8fW+/qJrmDENH0wI tv3cbT/T1pUu8mghjgwWvrme01u4nzdRhFZ7prb60dd6cDhNWTD7J0ICCge7xhLSEr3A h9iLpIseynobkqikTklODJaILqvt5FPiFIPelJExuR7X4lKWlKc/ejv+HgL4+M/R6bDT zQOACEJDKnrF8U/PG6EiQ/raOOJn9q35YSa3cjq2NZFcYRFAVhYSE8Z8RtreN2VEy3sw qUdo9XyQbZ6kwGRFtY8z5ZEjGbNOC+hS0m9WF2pvIPoobkL01FXuuehSlMuvdbBmfdKg VXUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:subject:cc:message-id:date :user-agent:mime-version:in-reply-to; bh=3WLlgdfqOsfnbyakpDifa4ARaz1FLQOTf4zT0WIqxgc=; b=id/oLe1wA+l5lvlwDrDLOScOym6SraDjbe2hyW26QX/mOCDRV79ubFnrnOLv0UYXC0 v4uStYVJjZ04DYJwiuVhAGi051sHWv81apRtorA6CLDE9TtsJC0BwqFYva5NDHwSs/Wd repAC0hBStRSnxj6S2mb9exjIAXEfb4zOLSlg3tzksCl06QMFb1yMZhZXus3Z5NkhXbk 2S0nJYCyelKwRMoEDb9mFfYEXY4UZcnIFM39OWYe4EtD/6H74vojsZQ+y5wbXS+BIB82 vCTBh70J36k80mUnIdqkw29eLe0AVnd6+wbbuBUFNEtEDs5Ap/LvDj9jf2A06KZD/gB/ K4YA== X-Gm-Message-State: AOAM532oGIZBiNWkp3q7Qk8p3nv35tdfa2P/W10qiBWacnSGcOyjdkR0 eKF4YB+luPy6TGtTGzT5vN4= X-Google-Smtp-Source: ABdhPJwaNqLJ+NVpKMkykONwOpRWdSV6IVGbB6wtttR7D7/CvoPCafv354CsyJWuVhJiTbj7kY9Nog== X-Received: by 2002:a0c:a9d9:: with SMTP id c25mr23870667qvb.0.1625666240530; Wed, 07 Jul 2021 06:57:20 -0700 (PDT) Received: from [192.168.1.155] (097-102-108-016.res.spectrum.com. [97.102.108.16]) by smtp.googlemail.com with ESMTPSA id s81sm8390656qka.82.2021.07.07.06.57.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 07 Jul 2021 06:57:19 -0700 (PDT) To: 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> From: Orlando Arias Subject: Re: Help porting newlib to a new CPU architecture (sorta) Message-ID: Date: Wed, 7 Jul 2021 09:58:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <54a6bb07-717c-ddf2-3e84-822c523b9035@SystematicSw.ab.ca> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7TCgUwNGcizZUonkOZTRtVF18TLmU852K" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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 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 13:57:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7TCgUwNGcizZUonkOZTRtVF18TLmU852K Content-Type: multipart/mixed; boundary="JYrDOi8yBKcUxkx57vUxpcdrjRtTmX6ZK"; protected-headers="v1" From: Orlando Arias To: newlib@sourceware.org Cc: Brian Inglis Message-ID: Subject: Re: Help porting newlib to a new CPU architecture (sorta) 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> In-Reply-To: <54a6bb07-717c-ddf2-3e84-822c523b9035@SystematicSw.ab.ca> --JYrDOi8yBKcUxkx57vUxpcdrjRtTmX6ZK Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 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= =2E 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. --JYrDOi8yBKcUxkx57vUxpcdrjRtTmX6ZK-- --7TCgUwNGcizZUonkOZTRtVF18TLmU852K Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iF0EAREKAB0WIQQNWDJzd34+k5noE3NTFb9QFn4uoQUCYOWzDAAKCRBTFb9QFn4u obUzAJ46i5cpuTTb7f4tjFsNWMnY+tlT6gCfbmeNtQvsqmEj74Dl9eeDxWodHE0= =w7dU -----END PGP SIGNATURE----- --7TCgUwNGcizZUonkOZTRtVF18TLmU852K--