public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Walfred Tedeschi <walfred.tedeschi@intel.com>
To: Pedro Alves <palves@redhat.com>,
	gdb-patches <gdb-patches@sourceware.org>,
	Yao Qi <qiyaoltc@gmail.com>
Cc: Joel Brobecker <brobecker@adacore.com>
Subject: Re: FW: Build xml target descriptions at run time
Date: Mon, 02 May 2016 13:00:00 -0000	[thread overview]
Message-ID: <57274F56.3030607@intel.com> (raw)
In-Reply-To: <AC542571535E904D8E8ADAE745D60B19445BAAD1@IRSMSX104.ger.corp.intel.com>

Am 5/2/2016 um 2:41 PM schrieb Alves, Pedro:
>> Firstly we also agree! :)
>> We have to agree upon a strategy and a design for that.
>>
>> I would propose that we go in the way it is by now for the patches
>> that are under review for me and Michael. Those patches impact
>> technology that is already public.
>>
>> Together with that we discuss the design on how to stich the target
>> descriptions together.
>>
>> Would you agree with that?
>
> I would.
>
>>
>> In terms of the design:
>> During this time we also proved that it would be possible to have a
>> single target description and selecting the features to be added
>> according to the feature bits during run time.
>>
>> The elegant option is of course the composition of the target
>> description under run time. But there is also the consideration of how
>> complex it would be.
>>
>> Have you already had some thoughts about that?
>
> Please share your thoughts as well...
>
>> Can you point us to some discussion about the topic?
>
> I'm recalling this being brought up at some Cauldron, and maybe
> (ISTR) Luis bringing that up on the gdb list somewhere.  ISTR recall this coming up for MIPS as well.  But I don't have pointers handy.
>
> I don't have a quick answer.  Below's a couple minutes worth of thought, all I could spare right now.
>
> Always going through a xml built at run time might be the simplest.
> However, even that poses challenges.
>
> The xml-building part itself wouldn't be anything complicated.  Just something along the lines of:
>
> x86_linux_read_description ()
> {
> strcat (output, target_xml_header);
>
> if (feature_foo_supported)
>    strcat (output, "<xi:include href="feature-foo.xml"/>"); if (feature_bar_supported)
>    strcat (output, "<xi:include href="feature-bar.xml"/>");
>
> strcat (output, target_xml_footer);
>
> return output;
> }
>
> However, gdb needs its own set of built-in target descriptions as well, for core file debugging, etc., and always going through the xml indirection would mean that libexpat becomes a hard requirement for native and core debugging as well, and, it'd require installing the xml files in the data-directory, along side gdb.  It's convenient NOT to have to install the xml files today, but maybe that's not a deal breaker.
>
> Also, then there's the gdbserver side.  gdbserver also makes use of the target descriptions for more than feeding a xml version back to gdb, and of course gdbserver doesn't parse the xml files at all.  They're instead converted at build time to whatever gdbserver needs.  So whatever design we come up with needs to address this as well.  Going the always-xml direction means that now gdbserver needs to link with expat and parse the xml files.
>
> Or maybe we could come up with a design that avoids having gdbserver parse xml, by still converting the feature xml files to C at build time (like, generate a set of struct target_desc_feature objects (which don't exist today), which would correspond to each feature that could be xinclude'd), and then at run time compose a struct target_desc from those struct target_desc_feature object, as well as a xml file to send back to gdb.
>
> Thanks,
> Pedro Alves

Pedro and All,

I was looking for Luis comments and I saw that he also would like to 
extend the xml files so the hard coded values in gdb could be also 
reduced.  That is an improvement on the target description scheme that 
makes a lot of sense. I would enjoy to see the number of tables we have 
reduced.

In refactoring the target description reading should/could we also 
consider that?

Regarding the gdbserver side: I was wondering that for the user it might 
be more complex to deliver the XML file set + gdbserver to target 
device, or?

Aside of that, the idea to make gdbserver parsing the xml looks good 
simplifying the handling.

Thanks and regards,
-Fred





Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

      parent reply	other threads:[~2016-05-02 13:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-03 17:26 [PATCH V2 0/2] Split tdesc_(amd64|i386)_mpx into tdesc(amd64|i386)_mpx_* and tdesc(amd64|i386)_avx_mpx_* Walfred Tedeschi
2016-03-03 17:25 ` [PATCH V2 2/2] Re-factor (i386|amd64)mpx target descriptors Walfred Tedeschi
2016-04-13 12:05   ` Pedro Alves
2016-03-03 17:26 ` [PATCH V2 1/2] Add redundant target descriptor for tdesc(amd64|i386)_avx_mpx_* Walfred Tedeschi
2016-04-13 12:05   ` Pedro Alves
2016-04-13 12:18     ` Walfred Tedeschi
2016-04-14 10:00     ` Walfred Tedeschi
2016-04-14 10:29 ` [PATCH V2 0/2] Split tdesc_(amd64|i386)_mpx into tdesc(amd64|i386)_mpx_* and tdesc(amd64|i386)_avx_mpx_* Yao Qi
2016-04-14 11:33   ` Pedro Alves
2016-04-14 12:21     ` Walfred Tedeschi
2016-04-14 13:28       ` Build xml target descriptions at run time Pedro Alves
     [not found]         ` <AC542571535E904D8E8ADAE745D60B19445BAAD1@IRSMSX104.ger.corp.intel.com>
2016-05-02 13:00           ` Walfred Tedeschi [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=57274F56.3030607@intel.com \
    --to=walfred.tedeschi@intel.com \
    --cc=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    --cc=qiyaoltc@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).