Help: address vs pointer

Help: address vs pointer

[Tristan Gingold]

Hi,

I have a problem with the address vs pointer circuitry in gdb for the  
AVR.

The AVR is a pure harvard architecture and furthermore the pc is an  
index to words (2 bytes).  Instruction
pointers are also index to words.
In the ELF world, addresses are bytes indexes (and data addresses have  
a 0x80000 offset).

So far so good.

In gdb world, instruction addresses should be in bytes and thus so are  
arch_unwind_pc and arch_read_pc.
But arch_pointer_to_adress will multiply by 2 pointers to instructions  
and will add an offset for pointer
to data.

So what should be the type of the pc register ?
If it is a pointer to instructions, 'print $pc' would be wrong as it  
would be multiplied by 4 (once by
read_pc and once during evaluation).
If it is not a pointer to instructions, 'disass $pc $pc+4' would be  
wrong because an offset would be added
like for any non-instruction pointer value.

What did I miss ?

Tristan.

Re: Help: address vs pointer

[Joel Brobecker]

> So what should be the type of the pc register ?  If it is a pointer to
> instructions, 'print $pc' would be wrong as it  would be multiplied by
> 4 (once by read_pc and once during evaluation).

My not-so-educated feeling on this issue is that PC should be a pointer
to instruction.  What seems strange is that the PC value gets doubled
twice.  I understand why during the read, but not why during the eval.
Perhaps there is something we can do there?

-- 
Joel

Re: Help: address vs pointer

[Tristan Gingold]

On Nov 2, 2009, at 4:48 PM, Joel Brobecker wrote:

>> So what should be the type of the pc register ?  If it is a pointer  
>> to
>> instructions, 'print $pc' would be wrong as it  would be multiplied  
>> by
>> 4 (once by read_pc and once during evaluation).
>
> My not-so-educated feeling on this issue is that PC should be a  
> pointer
> to instruction.  What seems strange is that the PC value gets doubled
> twice.  I understand why during the read, but not why during the eval.
> Perhaps there is something we can do there?

I was able to work-around this issue by creating a pseudo-register  
named 'pc'.  This pseudo register
is a pointer to instruction whose value is really the program counter  
(not multiplied by 2).

Using this pseudo-register, everything work well.  So I think this is  
the simplest solution!

However it is still difficult to set a breakpoint to a 'random' address:
break *0x1234 doesn't work because 0x1234 is interpreted as an integer  
which is converted to a pointer
in the data space.
Unfortunately, break *(void (*)())0x1234 works only when addresses are  
in the lower 64KW instruction
address space (because a pointer is 16 bits).  But some AVR have 128KW/ 
256KB of instructions...
But we can still use 'break *(&func + 0x1234)' !

Tristan.