Re: [Qemu-devel] [PATCH] gdb: provide the name of the architecture in the target.xml

[David Hildenbrand]

> On 6 October 2014 20:14, David Hildenbrand <address@hidden> wrote:
> > actually the questions were addressed in the last review. Haven't received 
> > any
> > answer from you to my reply. Maybe some mails got lost in the system.
> >
> > 32bit arm:
> > -"On my way through the possible architecture names
> >   (binutils-gdb/gdb/features/*.xml), I wasn't able to come up with the 
> > right name
> >   for arm 32 bit (arm-core.xml) - they don't specify any. This patch 
> > therefore
> >   adapts to the xml files from gdb."
> 
> But can we specify it for 32 bit ARM? Saying "set arch arm" at
> a gdb prompt works OK, so can we pass "arm" through in the XML too?
> The gdb documentation says that anything that works as an arch
> string at the gdb prompt is OK to pass through in the XML.

Yes, arm should work. But this whole armvX thing (see my other mail) makes me
wonder which is the right one. And if there is any difference (at least for
our purpose).

> 
> > - Not included in this patch as Edgar provided a patch in the previous 
> > thread
> >   (that's why he is on cc) that can easily be adopted. I don't want to 
> > simply
> >   include his effort in my patch :) And we have to make sure that this name 
> > is
> >   the right one.
> >
> > More complicated names:
> > - "The architecture should be known at the same point when specifying the 
> > xml
> >   file. So if anyone can come up with the proper arm name in the future (or 
> > even some
> >   kind of detection algorithm), it can simply be set in target-arm/cpu.c 
> > (after
> >   "arm-core.xml")."
> 
> At the moment we specify the XML file in the CPU class init
> function, whereas specific CPU subfeatures may not be known
> until rather later when we actually instantiate a CPU
> object. Are there any cases where we'd actually need to care?
> I can't tell, because you seem to be taking the "we're going
> to ignore all the CPU types where the answer isn't obvious"
> approach. The ARM "iwmmxt" architecture would be an interesting
> one to check, since if we really need to use that string rather
> than a generic "arm" string we need to postpone choosing the
> name til CPU init time when we set up the feature bits.

You're right, I was most likely only thinking about the kvm case :) But we of
course chose to emulate (almost) every cpu version/feature we want.

Even if the e500 might work with the common definition, you identified one
potential case that won't work, so we can't go with this generic approach.

So should each architecture rather provide a function that gives the name back?
Like
- NULL if not known
- Generic name if not further specified
- Complex name if specific version was initialized?

> 
> > - The same should apply for all architectures. So we can set (or even build)
> >   the proper string when also specifying the core xml file.
> >
> > Do you have something in mind like your "powerpc:common" and "powerpc:e500"
> > example? To build the names based on some pattern?
> >
> > I don't think that we can generalize the name format here (at least 
> > "aarch64"
> > makes me assume that :) ). I think it would be enough to set the complete
> > strings in the class init functions.
> 
> Only if the complete string doesn't depend on things we don't
> know at that point. Maybe we can always pick a generic
> name for each architecture, in which case we should do that
> (and do it for all architectures now, not only three).
> What does gdb do differently if you specify "powerpc:common"
> versus "powerpc:e500", for instance? Is it anything we care
> about?

I would have thought that the generic one would have worked for us (especially
because the gdb supplied xml files don't contain most of the special names). But
you point was right.

We should rather focus on the really supported architectures than on the ones
given in the xml files.

Thanks!

David