Question on 'set tdesc filename '.

Hello,

  Is there actually a scenario when the user would ask that
the target description be
  read from /<path> (locally, host-side) rather then
relying on the default behaviour
  to have GDB read the description from the target? What is
the rationale for
  'set tdesc filename <path>'? I would imagine that
since ultimately, the target (stub)
  defines the order in which it will send back the register
values in response to a
  g-packet, the target description should /always/ come from
the target side - as is
  the default behaviour. (So my understanding is that the
XML descriptions provided
  in the GDB sources are purely as reference for bare-metal
application writers to use
  in their remote-stub implementations).

  But, perhaps I am missing something here; please could
somebody tell me?

Thanks,
Anmol.

On Fri, May 09, 2008 at 11:50:27AM -0500, Anmol P. Paralkar
wrote:
> Hello,
>
>  Is there actually a scenario when the user would ask
that the target description be
>  read from /<path> (locally, host-side) rather
then relying on the default behaviour
>  to have GDB read the description from the target?

Yes: if a deployed target does not support supplying the
description
automatically.  One possible reason might be space
constraints on the
target system.  Another might be that the target stub is
simply old.

It's also useful for testing.

>  the default behaviour. (So my understanding is that
the XML descriptions provided
>  in the GDB sources are purely as reference for
bare-metal application writers to use
>  in their remote-stub implementations).

They are provided as reference, but also built-in to both
GDB and
gdbserver for internal use.

-- 
Daniel Jacobowitz
CodeSourcery

On Fri, 9 May 2008, Daniel Jacobowitz wrote:

> On Fri, May 09, 2008 at 11:50:27AM -0500, Anmol P.
Paralkar wrote:
>> Hello,
>>
>>  Is there actually a scenario when the user would
ask that the target description be
>>  read from /<path> (locally, host-side)
rather then relying on the default behaviour
>>  to have GDB read the description from the target?
>
> Yes: if a deployed target does not support supplying
the description
> automatically.  One possible reason might be space
constraints on the
> target system.  Another might be that the target stub
is simply old.
>
> It's also useful for testing.

  Oh, OK. So in these cases, the register ordering in the
description had better match-up
  what the remote-stub (implements and) sends - I mean,
since in the case where the remote
  side sends the description, this is automatically ensured
as GDB parses in the XML.
  I follow why the command is needed, thanks.

>
>>  the default behaviour. (So my understanding is
that the XML descriptions provided
>>  in the GDB sources are purely as reference for
bare-metal application writers to use
>>  in their remote-stub implementations).
>
> They are provided as reference, but also built-in to
both GDB and
> gdbserver for internal use.

  So, in the case of PowerPC, the [pu]trace interface would
only provide the standard 71
  registers; what if we want to contribute back a
description that defines more than those?
  Is it OK for a description to have more than what the
[pu]trace interface provides, since
  you say that this gets built-in to GDB & gdbserver?

Thanks,
Anmol.

>
> -- 
> Daniel Jacobowitz
> CodeSourcery
>

On Fri, May 09, 2008 at 12:18:21PM -0500, Anmol P. Paralkar
wrote:
>  Oh, OK. So in these cases, the register ordering in
the description
>  had better match-up what the remote-stub (implements
and) sends - I
>  mean, since in the case where the remote side sends
the
>  description, this is automatically ensured as GDB
parses in the
>  XML.  I follow why the command is needed, thanks.

Right.

>> They are provided as reference, but also built-in
to both GDB and
>> gdbserver for internal use.
>
>  So, in the case of PowerPC, the [pu]trace interface
would only provide the standard 71
>  registers; what if we want to contribute back a
description that defines more than those?
>  Is it OK for a description to have more than what the
[pu]trace interface provides, since
>  you say that this gets built-in to GDB &
gdbserver?

Specific descriptions are built in when GDB or gdbserver
needs them.
Not every description is.  If you have new components to
describe,
they won't go in the same descriptions that gdbserver is
currently using.

-- 
Daniel Jacobowitz
CodeSourcery