This is the mail archive of the gdb-patches@sourceware.org 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] Bare-metal register browsing


On 6/11/2015 11:56 AM, Yao Qi wrote:
On 09/06/15 21:49, Vladimir Prus wrote:
It's a bit more generic - it means that to obtain values of any register
in this group, GDB should perform qXfer of the specified target object
and annex, using register's offset. Memory is the most typical target
object,
but in our case, we had other sorts of registers, so I'd prefer the
design to
not lock us into memory-mapped registers.


I don't object to it.

Does "offset=0x4000e030" mean this register is mapped
at address 0x4000e030?  If the answers of both questions are yes, is
target-object="memory" still necessary?  Without it, we can still define
a group of memory-mapped registers like:

  <group name="io">
      <reg offset="0x4000e030" name="UART1_1">
      <reg offset="0x4000e034" name="UART1_2">
      <reg offset="0x4000e038" name="UART1_3">
  </group>

and we may even can define a group of normal registers and memory-mapped
registers, (even it is not likely in practise)

  <group name="io">
      <reg offset="0x4000e030" name="UART1_1">
      <reg offset="0x4000e034" name="UART1_2">
      <reg name="UART1_3">
  </group>

In this case, UART1_1 and UART1_2 are memory-mapped, while UART1_3 is
not.  IMO, memory-map-ness is an attribute of each register instead of a
group, so better to define such attribute on each register level.

It is possible in theory, but I think it has two drawbacks.

First, I think specifying target object is more explicit (and therefore
better
than implicit, especially for machine-oriented format) and more generic,
as it allows
us to use other target objects.

Second, implementing such mixed registers group is extra complexity, and
we did
not find any need for that in practice.

If such mixed registers group brings extra complexity in the
implementation, then I am inclined to start from a simple one.

Yes, I think it brings extra complexity.

Thanks for your comments; I plan to update the patch to:

- Use top-level group for register browsing, as opposed to <space> element
- Do some form of testing that does not require hardware.

Thanks,
Volodya



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