Remote protocol: undocumented return value for 'p'

Remote protocol: undocumented return value for 'p'

[Raphael Zulliger]

Hi

During the development of a GDB stub, I encountered a "hidden feature": 
the 'p n' command (reading the value of a register) accepts an 
undocumented return value, which is not mentioned in the official GDB 
documentation: 'x'. the source code looks like this:

   /* If this register is unfetchable, tell the regcache.  */
   if (buf[0] == 'x')
     {
       regcache_raw_supply (regcache, reg->regnum, NULL);
       return 1;
     }


At some point during the development of my stub it was important for me 
to have this 'hidden feature'. Unfortunately, I can't remember why it 
was important - and now it seems that I don't rely on that anymore... 
However, at that time, it would have helped me to save some time if I 
could just read it from the PDF instead of searching it in the code.

The final question is: Is this feature missing in the documentation by 
'intention' or by 'mistake'? If it's the latter case, I would suggest 
adding it. Let me know if I should create an according patch.

Raphael

Re: Remote protocol: undocumented return value for 'p'

[Pedro Alves]

On Friday 17 December 2010 16:10:23, Raphael Zulliger wrote:
> Hi
> 
> During the development of a GDB stub, I encountered a "hidden feature": 
> the 'p n' command (reading the value of a register) accepts an 
> undocumented return value, which is not mentioned in the official GDB 
> documentation: 'x'. the source code looks like this:
> 
>    /* If this register is unfetchable, tell the regcache.  */
>    if (buf[0] == 'x')
>      {
>        regcache_raw_supply (regcache, reg->regnum, NULL);
>        return 1;
>      }
> 
> 
> At some point during the development of my stub it was important for me 
> to have this 'hidden feature'. Unfortunately, I can't remember why it 
> was important - and now it seems that I don't rely on that anymore... 
> However, at that time, it would have helped me to save some time if I 
> could just read it from the PDF instead of searching it in the code.
> 
> The final question is: Is this feature missing in the documentation by 
> 'intention' or by 'mistake'? If it's the latter case, I would suggest 
> adding it. Let me know if I should create an according patch.

By mistake.   It was added here:

Thu Oct 29 10:04:20 1998  Michael Snyder  <msnyder@cleaver.cygnus.com>

	[Support for trace debugging: registers that were not collected.]
	* remote.c (remote_fetch_registers): accept 'xxxx' in the register
	packet, with the meaning "register value is not available".
	Set register_valid to -1, which will connote "no value available".
	* findvar.c (read_relative_register_raw_bytes): return failure if
	register_valid == -1.  (value_of_register): return failure if 
	register_valid == -1.  (read_var_value): return error if 
	value_of_register fails for a register variable.
	(value_from_register): return failure if register_valid == -1.
	* eval.c (evaluate_subexp_standard): return error if 
	value_of_register fails for a register used in an expression.
	* infcmd.c (do_registers_info): display "value not available"
	for registers for which register_valid == -1.

	* tracepoint.c (set_raw_tracepoint): just save the filename as is
	from the symbol table, rather than trying to prepend the dir name.
	Also save the bfd section.  (tracepoints_info): use the section
	when looking up the function name.
	* tracepoint.h: add section field to tracepoint struct.

It's intended usage is in the context of inspecting tracepoints, to
report "the register exists, but I don't know its value, because I haven't
collected it."

If you found yourself using it to mean "this register does not actually
exist in this CPU variant", then you used the wrong approach.  You want
to be using target descriptions for that.

-- 
Pedro Alves