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

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.