Re: [WIP] Bare-metal register browsing

[Yao Qi <qiyaoltc at gmail dot com>]

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.

> May I suggest we start from a simple use case, where an alternative
> access mechanism
> can only be specified for a top-level group, and it's explicitly
> specified by
> target-object attribute? Should the need arise for mixing
> differently-accessed
> registers inside one group, that can be implemented later with extra code.
>
> > > Two questions:
> > >
> > > - Is 'group' ok, or 'register-group' would be more clear? We found
> > > that the size of these XML
> > > files can be sometimes a problem
> >
> > I don't have preference here.
> >
> > > - I'd propose that 'target-object' and 'annex' attribute are only
> > > allowed for top-level 'group' element,
> > >    and not for top-level 'reg' or nested 'group' element, to make
> > > implementation simpler. Is that fine?
> >
> > You have to explain the meaning of target-object and annex first and
> > what are the possible values of them.
> >
> > My last concern is about the testing of these new things in target
> > description.  We need some test cases that people can run in their own
> > dev env, without involving setting up OpenOCD/JTAG probe/embedded boards.
>
> That's a valid concern. I was using a particular board with USB
> interface, so did not need a probe,
> but even that is not trivial to setup or automate.
>
> If we were to test on a regular computer, I suppose the only way is to
> have some variables in a C program,
> determine their addresses after debug session start, and generate target
> XML dynamically from that?

Yes, that is what I want to suggest too.

--
Yao (éå)