From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112204 invoked by alias); 11 Jun 2015 16:18:10 -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 112193 invoked by uid 89); 11 Jun 2015 16:18:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 11 Jun 2015 16:18:09 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 6CFB828A01; Thu, 11 Jun 2015 12:18:07 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wMw-uc2cRnNG; Thu, 11 Jun 2015 12:18:07 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 4BA36286D2; Thu, 11 Jun 2015 12:18:07 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id CDBB940274; Thu, 11 Jun 2015 12:18:06 -0400 (EDT) Date: Thu, 11 Jun 2015 16:18:00 -0000 From: Joel Brobecker To: "Tedeschi, Walfred" Cc: "eliz@gnu.org" , "gdb-patches@sourceware.org" Subject: Re: [PATCH 1/1] Fix broken GDB build after adding Bound table support for i386. Message-ID: <20150611161806.GC11014@adacore.com> References: <1433940196-22975-1-git-send-email-walfred.tedeschi@intel.com> <20150610141308.GB11014@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-06/txt/msg00224.txt.bz2 > I am considering using a guard on the code like bellow: > if (gdbarch_ptr_bit (gdbarch) == 64) > { > #ifdef __x86_64__ > mpx_bd_mask = MPX_BD_MASK; <- Here. MPX_BD_MASK is #define MPX_BD_MASK 0xfffffff00000ULL /* select bits [47:20] */ > bd_ptr_r_shift = 20; > bd_ptr_l_shift = 3; > bt_select_r_shift = 3; > bt_select_l_shift = 5; > bt_mask = MPX_BT_MASK; > #else > error(_("operation not supported yet") > #endif > } > else > { > > I consider that debugging a 64 bit application with a 32 bit debugger > is not supported fully, but I might be wrong. > In any case would this be an acceptable solution? First, my understanding of the the general principles used in the GDB project: For native compilers, we would indeed generally say 32bit GDB can only debug 32bit applications, but not as an absolute rule. That limitation is usually not because of GDB but rather because of a limitation in the underlying systems which don't support 64bit debugging from 32bit programs. In your case, we are in a slightly different situation, however, as we are in what we call "target" (-tdep) code, rather than "native" (-nat). In that case, if it is difficult to support 32bit debugging 64bit app + something of little interest, then we can indeed consider keeping that scenario unsupported. But we should otherwise try looking at whether we can support it. Now, looking more specifically at your situation, it seems to me that supporting 64bit target if CORE_ADDR is 32bit is going to be, erm, hard. So, something along the lines above would indeed be the best we can do. You have to be careful to conditionalize on something else that __x86_64__, though, as the host's CPU might not be an x86/x86_64... -- Joel