Re: Help porting newlib to a new CPU architecture (sorta)

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 
<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, [email protected], Skype
  Dave.Nadler1