Question on 'set tdesc filename <path>'.

Question on 'set tdesc filename <path>'.

[Anmol P. Paralkar]

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.

Re: Question on 'set tdesc filename <path>'.

[Daniel Jacobowitz]

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

Re: Question on 'set tdesc filename <path>'.

[Anmol P. Paralkar]

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
>

Re: Question on 'set tdesc filename <path>'.

[Daniel Jacobowitz]

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