[Pdbg] [RFC PATCH] libpdbg: Handle cooked/raw CFAM addressing modes

[Andrew Jeffery]

On Wed, 28 Aug 2019, at 13:17, Alistair Popple wrote:
>  
> > > This needs to happen in the client application (ie. pdbg). Otherwise an 
> > > application such as istep0 that is written assuming raw addresses will end 
> up 
> > > doing totally the wrong thing if cooked addresses are selected from the 
> > > environment variable, and it won't have any way of figuring that out.
> > 
> > Right, it's easy to wind up with addressing mode confusion and break things 
> -
> > that's a fair point. However we do have setenv() :trollface: (not seriously
> > suggesting that).
> 
> Ha. I thought of that when I wrote this, I was just waiting for you to suggest 
> it :-P
> 
> > On a bit of a tangent, I don't see how istep0 could currently be written 
> using
> > raw addresses as the cooked processing was unconditional?
> 
> Sorry, as you it's easy to confuse these. I should have said cooked/fsi 
> addresses.
> 
> Jeremy had a off handed idea that I think I kind of like though. Rather than 
> adding a command line option to change the addressing, why don't we make it 
> explicit to the address?
> 
> In other words we could keep 0x.... to mean cooked addresses and introduce 
> something like 0n.... to mean normal byte addressing. I like that it forces 
> users to think about what addressing they really want and removes to 
> possibility of forgetting about some alias without making it too much of a 
> pain to type everytime. Would appreciate other peoples thoughts though.
> 

Hmm, that is an interesting idea. Pity we wouldn't be able to swap the modes
without breaking things. The purist in me feels sketchy about hijacking the
base prefix, so what about doing suffixes? Addresses aren't floating point so
we can e.g. use '.' to terminate the value as it's not a digit in any base, and then
append e.g. 'c' or 'r' for cooked or raw respectively. From there we can use 
strtoul()'s endptr to capture the suffix while still using arbitrary bases. Some
examples:

# 1. Cooked address mode for compatibility, access the second word of peek
$ pdbg -a getcfam 0x401

# 2. Explicit cooked mode, same access as above
$ pdbg -a getcfam 0x401.c

# 3. Raw mode, same access as above, base 10 because we can
$ pdbg -a getcfam 1028.r

Maybe we could still do an option/env var for managing case 1? Could be
over-doing it though.

Andrew