This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH 1/3] arc: Add XML target descriptions for Linux targets


Sorry that email wasn't finished, sent by mistake :)

I'm still researching the topic.

Anton

> -----Original Message-----
> From: Anton Kolesov [mailto:akolesov@synopsys.com]
> Sent: Wednesday, October 18, 2017 18:07
> To: Yao Qi <qiyaoltc@gmail.com>; Anton Kolesov
> <Anton.Kolesov@synopsys.com>
> Cc: gdb-patches@sourceware.org; Francois Bedard
> <Francois.Bedard@synopsys.com>
> Subject: RE: [PATCH 1/3] arc: Add XML target descriptions for Linux targets
> 
> Hi Yao,
> 
> > -----Original Message-----
> > From: Yao Qi [mailto:qiyaoltc@gmail.com]
> > Sent: Thursday, October 12, 2017 4:29
> > To: Anton Kolesov <Anton.Kolesov@synopsys.com>
> > Cc: gdb-patches@sourceware.org; Francois Bedard
> > <Francois.Bedard@synopsys.com>
> > Subject: Re: [PATCH 1/3] arc: Add XML target descriptions for Linux
> > targets
> >
> > On 17-10-11 17:56:31, Anton Kolesov wrote:
> > > Add XML target descriptions for Linux targets.  Compared to default
> >
> > Hi,
> > I am converting existing GDB target descriptions in a more flexible
> > way to organize them.  I've done the x86 target descriptions, and
> > slowly converting tic6x and nios2 target descriptions.  Could you
> > please convert existing arc target descriptions first?  It is
> > definitely helpful to simplify this patch.  I had a talk about my work in
> Cauldron.
> > https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__slideslive.com_38902354_a-2Dflexible-2Dgdb-2Dtarget-2Ddescription-
> > 2Dfor-2Dprocessor-
> >
> 2Ddiversity&d=DwIDaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=bGeZp_Q7bzMjry
> >
> uhhu0vBa43pSPPzpiFmLmHs_6WFqE&m=MppHij0o6FxrwL3TgkCMii1KKmHt_
> >
> nSJaMNwdq8BcUk&s=XrFH1QC31ZrbgC4h4uHLGWxV6YuN5Nz2Q_rGtBg2k_k
> > &e=
> > If you want to convert existing arc target descriptions, I am happy to
> > share some steps to do that.
> >
> > > Linux descriptions:
> > >
> > > - Explicitly specify CPU machine.
> > > - Remove baremetal only ILINK{,1,2} registers.
> > > - Add LP_START and LP_END registers for hardware loops - required to
> > properly
> > >   evaluate possible next instruction during software single instruction
> > >   stepping.
> > > - Add BTA register which contains branch target address - address of next
> > >   instruction when processor is in the delay slot.
> > > - ARC HS description also adds R30, R58 and R59 registers, specific to this
> > >   architecture.
> >
> > IMO, it is not a good practise to linux and non-linux target
> > descriptions have target features of the same name, but same target
> > features have trivial differences, as you described above.  The common
> > practise we did is to define each target feature xml file, and use xi:include
> to "include"
> > each target feature into target description.  All existing target
> > descriptions follow this approach.
> >
> 
> If I extract R58, R59 and ILINK/R29 into separate features that would multiple
> problems:
> - order of registers in "info registers" will not match architectural numbers of
> registers.
> - that would add two XML features because of three registers. Considering
> amount of code that is needed for each feature it doesn't look like a good
> tradeoff. Especially since this should be propogated to each and every
> gdbserver that works with ARC.to produce XML target descriptions that
> match GDB expectations - almost all of them generate descriptions based on
> what are the actual registers in the target CPU - gdbserver in GDB is the only
> one that uses files from gdb/features/.
> - and that still before we tackle the true complexity of ARC: there are
> extension core registers R32-R57 that can be added by hardware designers;
> there is a "reduced register file" configuration where many core registers are
> removed, but there are two groups of registers removed, so extracting them
> into separate features would also break order of register (R4 will be after
> R31, etc).
> - in addition for each XML feature there is a need to create separate code in
> arc_gdbarch_init, and feature-reading code tends to be a verbose copy paste
> with minor edits, so removal of copy-paste in XML files adds more copy paste
> in GDB code and even more complexity at the side of gdbserver (and some
> gdbservers are not maintained by Synopsys, so updating them is
> complicated), so having "fixed" XML features always looked to me like a bad
> idea for the case of ARC.
> 
> That's why I've historically decided to
> 
> 
> If I extract R58, R59 and ILINK/R29 into separate features, then registers will
> lose their order in "info registers", so R29 will be after R30, blink/R31 or
> loop_counter/R60. Furthermore, if we extend the paradigm that feature
> should have a fixed set of register, then things go very bad if we consider a
> reduced register set configuration for ARC (16 core registers instead of 32) - it
> creates more holes in the feature. So there would be feature for always-
> present registers (R0-R3, R10-R15, R26-R28, R30-R31, R63), then registers
> added in normal configuration (R4-R9, R16-R25), then separate features for
> R29/ILINK, for R58+R59, for LP_COUNT/R60 (strictly speaking it is optional,
> though it almost always present). Things get even more complicated if we
> consider that chip designer can add their own extension registers R32-R57.
> One option is of course to just add separate XML features for each group of
> registers to make sure that order of registers in GDB matches architectural
> order, or to write a more complex logic in the arc_gdbarch_init so it would
> interleave scanning of different features to maintain order.
> 
> Even if we ignore reduced register set case and ordering of registers, it
> means that I need to split "core" feature into:
> - always present: R0 - R28, BLINK, LP_COUNT, PCL
> - present at baremetal only : R29
> - multiplier (present at Linux, maybe present at baremetal): R58, R59
> - flexible feature for extension core registers, that allows to insert R30-R57
> when any one is present.
> 
> Then those changes should be implemented in several GDBservers that work
> with ARC (most of them generate their own XML target description based on
> what registers are actually present or not present in the target CPU)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]