On Thu, 2012-12-27 at 22:21 +0100, Franck Jullien wrote: > 2012/12/22 Franck Jullien <[email protected]>: > > 2012/12/22 Jeremy Bennett <[email protected]>: > >> On Sat, 2012-12-22 at 01:00 +0100, Franck Jullien wrote: > >>> In order to get registers names and groups from the target descriptor > >>> file, some new functions are needed. > >>> > >>> This patch adds: > >>> > >>> - tdesc_find_register_name: Search FEATURE for a register REGNO and > >>> return its name. > >>> > >>> - tdesc_nb_feature: Return the number of features available in the > >>> target descriptor. > >>> > >>> - tdesc_feature_idx_name: Return the name of feature given it's index. > >>> > >>> - tdesc_set_register_group_early: Search FEATURE for a register named > >>> NAME and set its group to GROUP. > >>> > >>> - tdesc_register_group: Search GDBARCH for a register REGNO and return > >>> its group. > >> > >> This is good - the above description should go in ChangeLog.or32 for > >> target-descriptions.c and target-descriptions.h. > >> > > > > OK > > > >> However, I'm not sure these functions are all needed generically, in > >> which case they belong in or32-tdep.c. target-descriptions.h already has > >> a wide range of functions, and if you extend this, you need to explain > >> why they must be generic and not specific to a particular architecture. > >> > > > > OK. > > > >> I think it is because you are introducing the concept of register > >> groups, which as far as I know is an OR1K specific concept. I'm not yet > >> really clear how your use of groups relates to the general concept of > >> features - could you explain a bit more about this. > >> > > > > I think the concept of groups can be extended to other arch. If you > > have more than > > one auxiliary register related to one function (eg. timer, uart,...) > > then it is a group. > > > > I decided to create groups from feature name because the xml format only > > allows > > to put a register in a general, float or vector group (gdb doc.): > > > > "The register group to which this register belongs. group must be > > either general, > > float, or vector. If no group is specified, gdb will not display the > > register in > > info registers." > > > > We could also change the xml format to allow generic register group name. > > > > Jeremy, did you have some time to think about this ? > > I'd like to know if I should stay with my new "feature becomes a > group" approach or > if I should modify the xml definition, adding the possibility to use > any group name. > The former also needs new functions in target-descriptor.c to handle > group creation > on the fly....
Hi Franck, I like the idea of adding generic structure to GDB features. However I am not expert enough on this. I think it would be a very good subject to raise either on the GDB mailing list or on #gdb at freenode.net. Part of the problem is that this stuff is poorly documented at present, so it's not quite clear what the vision is for its future use. I noticed your other email about MIPS using non-standard XML, although I believe this then requires a suitable modified DTD etc. Best wishes, Jeremy -- Tel: +44 (1590) 610184 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: [email protected] Web: www.embecosm.com _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
