Multi-arch and user-control of architecture flags

Multi-arch and user-control of architecture flags

[Richard Earnshaw]

More random thoughts that I thought worth writing down before I forget 
them...

The current way to allow for a user to control some aspect of a target is 
to add a "set" command so that they can control a flag, for example, the 
ARM target has

  set apcs32 true/flase

to control whether the debugger should work with the processor in 26-bit 
mode or 32-bit mode.

As we move towards supporting multiple processors in a single GDB this is 
going to become increasingly confusing if we continue down this line, and 
it will become very unclear (to the poor user) which options apply to 
which target.

So how feasible would it be to extend the "set" and "show" commands so 
that they could sub-set the information?  For example, to allow

  set <target> <var> <value>

and 

  show <target> <var>

or even

  show <target>

to show all variables specific to the target.

If this isn't particularly practical, then perhaps we need a new command 
(tset/tshow?) that provides this.

R.

Re: Multi-arch and user-control of architecture flags

[Eli Zaretskii]

On Wed, 15 May 2002, Richard Earnshaw wrote:

> So how feasible would it be to extend the "set" and "show" commands so 
> that they could sub-set the information?  For example, to allow
> 
>   set <target> <var> <value>
> 
> and 
> 
>   show <target> <var>
> 
> or even
> 
>   show <target>
> 
> to show all variables specific to the target.

I don't know how hard is this, but I like the idea from the UI point of 
view.

Re: Multi-arch and user-control of architecture flags

[Andrew Cagney]

> On Wed, 15 May 2002, Richard Earnshaw wrote:
> 
> 
>> So how feasible would it be to extend the "set" and "show" commands so 
>> that they could sub-set the information?  For example, to allow
>> 
>>   set <target> <var> <value>
>> 
>> and 
>> 
>>   show <target> <var>
>> 
>> or even
>> 
>>   show <target>
>> 
>> to show all variables specific to the target.
> 
> 
> I don't know how hard is this, but I like the idea from the UI point of 
> view.

Have a look at the ``(gdb) set mips'' command ;-)  Another group with 
the same problem are the ``info'' commands.

New targets, when someone remembers, are done this way.  The problem is 
all the old commands and for that we have have a deprecate mechanism.

The mailing lists also contain discussion about a set [<arch>] 
disassembler command which would more directly tie into bfd's 
disassembler option.

Andrew

Re: Multi-arch and user-control of architecture flags

[Richard Earnshaw]

ac131313@cygnus.com said:
> Have a look at the ``(gdb) set mips'' command ;-)  Another group with
> the same problem are the ``info'' commands. 

Hmm, yep, that looks like what I want.

Note, however, there's something odd here...

  /* Add root prefix command for all "set mips"/"show mips" commands */
  add_prefix_cmd ("mips", no_class, set_mips_command,
                  "Various MIPS specific commands.",
                  &setmipscmdlist, "set mips ", 0, &setlist);

  add_prefix_cmd ("mips", no_class, show_mips_command,
                  "Various MIPS specific commands.",
                  &showmipscmdlist, "show mips ", 0, &showlist);

Then at the end of the file:

  /* Debug this files internals. */
  add_show_from_set (add_set_cmd ("mips", class_maintenance, var_zinteger,
                                  &mips_debug, "Set mips debugging.\n\
When non-zero, mips specific debugging is enabled.", &setdebuglist),
                     &showdebuglist);

One of these must shadow the other....

R.

Re: Multi-arch and user-control of architecture flags

[Andrew Cagney]

> 
> Hmm, yep, that looks like what I want.
> 
> Note, however, there's something odd here...
> 
>   /* Add root prefix command for all "set mips"/"show mips" commands */
>   add_prefix_cmd ("mips", no_class, set_mips_command,
>                   "Various MIPS specific commands.",
>                   &setmipscmdlist, "set mips ", 0, &setlist);
> 
>   add_prefix_cmd ("mips", no_class, show_mips_command,
>                   "Various MIPS specific commands.",
>                   &showmipscmdlist, "show mips ", 0, &showlist);

> Then at the end of the file:
> 
>   /* Debug this files internals. */
>   add_show_from_set (add_set_cmd ("mips", class_maintenance, var_zinteger,
>                                   &mips_debug, "Set mips debugging.\n\
> When non-zero, mips specific debugging is enabled.", &setdebuglist),
>                      &showdebuglist);
> 
> One of these must shadow the other....

The latter is ``set debug mips''.  showdebuglist vs showmipscmdlist. 
Yes, bad variable names.

Andrew

Re: Multi-arch and user-control of architecture flags

[Andrew Cagney]

>   /* Add root prefix command for all "set mips"/"show mips" commands */
>   add_prefix_cmd ("mips", no_class, set_mips_command,
>                   "Various MIPS specific commands.",
>                   &setmipscmdlist, "set mips ", 0, &setlist);
> 
>   add_prefix_cmd ("mips", no_class, show_mips_command,
>                   "Various MIPS specific commands.",
>                   &showmipscmdlist, "show mips ", 0, &showlist);
> 

Just a PS on this.  The command set ``set mips fpu ...'' et.al. isn't 
perfect - it sets a global for all mips which is probably sufficient for 
what people want.

Eventually a per thread command may be needed.   So that a target 
containing an 8086 and x86-64 can have, separatly, their disassembly 
mode.  Something like:

	thread 5 set i386 disassembler x86-64

(just ignore the syntax though).  However, not our problem :-)

Andrew

Re: Multi-arch and user-control of architecture flags

[Richard Earnshaw]

> >   /* Add root prefix command for all "set mips"/"show mips" commands */
> >   add_prefix_cmd ("mips", no_class, set_mips_command,
> >                   "Various MIPS specific commands.",
> >                   &setmipscmdlist, "set mips ", 0, &setlist);
> > 
> >   add_prefix_cmd ("mips", no_class, show_mips_command,
> >                   "Various MIPS specific commands.",
> >                   &showmipscmdlist, "show mips ", 0, &showlist);
> > 
> 
> Just a PS on this.  The command set ``set mips fpu ...'' et.al. isn't 
> perfect - it sets a global for all mips which is probably sufficient for 
> what people want.
> 
> Eventually a per thread command may be needed.   So that a target 
> containing an 8086 and x86-64 can have, separatly, their disassembly 
> mode.  Something like:
> 
> 	thread 5 set i386 disassembler x86-64
> 
> (just ignore the syntax though).  However, not our problem :-)
> 

Yeah!  I was thinking of a similar sort of requirement if a user has two 
physical CPUs in the design, then you would need to be able to configure 
each instance.

However, we would need to be able to have multiple instances of the 
gdbarch current for that to work...

R.