From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34894 invoked by alias); 14 Apr 2016 12:21:34 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 34874 invoked by uid 89); 14 Apr 2016 12:21:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:ip*10.253.24.29, H*RU:HELO, Hx-spam-relays-external:HELO, ABC X-HELO: mga01.intel.com Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Apr 2016 12:21:22 +0000 Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga101.fm.intel.com with ESMTP; 14 Apr 2016 05:21:13 -0700 X-ExtLoop1: 1 Received: from wtedesch-mobl2.ger.corp.intel.com (HELO [172.28.205.68]) ([172.28.205.68]) by FMSMGA003.fm.intel.com with ESMTP; 14 Apr 2016 05:21:11 -0700 Subject: Re: [PATCH V2 0/2] Split tdesc_(amd64|i386)_mpx into tdesc(amd64|i386)_mpx_* and tdesc(amd64|i386)_avx_mpx_* To: Pedro Alves , Yao Qi References: <1457025942-23711-1-git-send-email-walfred.tedeschi@intel.com> <864mb4mqkm.fsf@gmail.com> <570F8019.3060101@redhat.com> From: Walfred Tedeschi Cc: Joel Brobecker , gdb-patches Message-ID: <570F8B36.1070301@intel.com> Date: Thu, 14 Apr 2016 12:21:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <570F8019.3060101@redhat.com> Content-Type: text/plain; charset="windows-1252"; format="flowed" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-04/txt/msg00327.txt.bz2 Am 4/14/2016 um 1:33 PM schrieb Pedro Alves: > On 04/14/2016 11:29 AM, Yao Qi wrote: >> Walfred Tedeschi writes: >> >>> CPU features can occur in any combination. The current assumption that >>> feature "A" implies in feature "B" does not necessarily hold. >>> >>> This patch series construct an additional combination of the Intel(R) >>> Memory Protection Extensions (MPX) with Intel(R) Advanced Vector >>> Extensions (AVX). >> >> First of all, I am not against your patches. Just think a little more >> after reading them... >> >> This reveals a problem in gdb target description. It doesn't scale very >> well if processors have multiple different features, and features can be >> combined differently. A processor family has three features A, B, and >> C, and each processor implementation may have one, two or three of these >> features. In gdb target description, we need to have many *.xml and *.c >> files, for these combinations like, A, B, C, AB, AC, BC, and ABC. >> >> The root cause is that target description are static and pre-generated. >> If the target description can be generated dynamically according to the >> cpuid or AT_HWCAP, that would be simpler. In this way, we only have to >> define target descriptions for feature A, B, and C, and GDB/GDBserver >> combine them together in the runtime. > > I agree. This is not the first time this is suggested. If someone were > to do it, I'd be in favor too. > > Thanks, > Pedro Alves > Hello all, 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=20 are under review for me and Michael. Those patches impact technology=20 that is already public. Together with that we discuss the design on how to stich the target=20 descriptions together. Would you agree with that? In terms of the design: During this time we also proved that it would be possible to have a=20 single target description and selecting the features to be added=20 according to the feature bits during run time. The elegant option is of course the composition of the target=20 description under run time. But there is also the consideration of how=20 complex it would be. Have you already had some thoughts about that? Can you point us to some=20 discussion about the topic? Thanks a lot for the reviews and thoughts and best 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