This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [wip/cagney_regbuf-20020515-branch] Introduce regcache_move()



> Hmm, so each pseudo would allocate a unique address even though there was 
> no real regbuf space for it; something like
> 
>   0         4               4*(n-1)   4*n       4*(n+1)   ...
>   +---------+---------+     +---------+---------+---------+
>   | Phys r0 | Phys r1 | ... | Phys rn | Pseu r0 | Pseu r1 |
>   +---------+---------+     +---------+---------+---------+
>   |     REGBUF          ...           |
>   +--------------------     ----------+
> 
> Then each reg would have a unique address.  Provided we always call 
> through the correct interfaces, and never use
> 
>  memcpy (grub_around...registers() + REGISTER_BYTE(PseudoN), ...)
> 
> then this would work.

Yes (saving diagram for doco).  (Just renaming grub_ to legacy_grub_ ....)

>> Rock warning: GDB uses the above to handle (with limited success) values 
>> that cross two registers.  For instance a long long in two adjacent long 
>> registers.  See value_from_register().
> 
> 
> I've been told ARM's own C compiler can put long longs in non-adjacent 
> register pairs.  At some point I will need to support that... it will 
> probably mean being able to read from some ordered list of registers, or 
> some such.

Yep, for GCC, dwarf2 location expressions let you scatter a value across 
memory and registers.  I think GDB's `struct value' will need an upgrade 
- somebody elses problem.

Andrew



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]