From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71503 invoked by alias); 23 Sep 2015 20:40:53 -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 71484 invoked by uid 89); 23 Sep 2015 20:40:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f201.google.com Received: from mail-pd0-f201.google.com (HELO mail-pd0-f201.google.com) (209.85.192.201) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 23 Sep 2015 20:40:50 +0000 Received: by pdbou10 with SMTP id ou10so4027128pdb.0 for ; Wed, 23 Sep 2015 13:40:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:message-id:date:subject:from:to:cc :content-type; bh=o9WDNFRkiVugzKJWrCGeaBlltddn0xDZjxBakG7gpTo=; b=j3wuJEykWEDHuq4s8gXEz7X1bDi7VzHelr4uImfG129eOHVPkC/In5M5znp3kSLgQK VYEJcgGPust0XgbY5rCp/LQ45qdQv9dZB6JDYmZmD8aXowccxGCdA66VU6l9RYs6w9/9 iHpGR9bv8jcIm32iMctjcuWaiM1skmAFeHHJMq4pj7xR/7jqs/RZoAqChdK6DN/4279q EmUuPQb4zUCCsZQfWQGPbl02p4cqFTny2pJAwdY4KNZfRjUS4hHtjX3W/R8Kr84nMS1a m7Hw7tJSFJ7RGulhs+EqZ3TkzY/TK8MW9BTBMdLqwtajPErrZuS9ztrfQ/Go02hFj82b 5aaQ== X-Gm-Message-State: ALoCoQmY6x8xJoswAGfcquEIH3bwbdta/8riiVvXj6cpOHvWM8iN3+QDmeKZsRSlxK/tECkCd+Pj MIME-Version: 1.0 X-Received: by 10.66.142.233 with SMTP id rz9mr27473368pab.48.1443040848819; Wed, 23 Sep 2015 13:40:48 -0700 (PDT) Message-ID: <001a113448083110dd05207021ae@google.com> Date: Wed, 23 Sep 2015 20:40:00 -0000 Subject: Re: [PATCH 2/7] Move some integer operations to common. From: Doug Evans To: Antoine Tremblay Cc: Pedro Alves , Gary Benson , gdb-patches Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00553.txt.bz2 Antoine Tremblay writes: > > The next question I have is: Is there anything in what we need that > > needs to be in a generated header? > > Can we ask the bfd folks to move things like bfd_endian to a > > non-generated header? > > [bfd.h can still include it] > > > > Quickly looking at how bfd.h is done it seems to be possible to move > some stuff to a static file however I wonder if the current problem > would prove enough justification for that work. One would hope no one would try to set too high a bar to justify this work, but whatever. > It would also introduce a bfd version dependency in common code to check > for this static header. And it could be quite an ugly #ifdef changing > ints to enum in case the header is present. This is a non-issue. gdb always uses bfd HEAD, and in general we don't support uses of bfd outside of binutils and gdb. > One thing to consider too is that this patchset has now changed a bit > and this enum is no longer used in GDBServer itself at all. I'm less interested in whether the enum is used in gdbserver than whether it is used in the common code (and thus by extension it still matters what gdbserver uses). We *could* just use a bool, is_big_endian or is_little_endian. The code today assumes it never sees BFD_ENDIAN_UNKNOWN, which would be nice to fix. Or we could invent a new enum that just has big/little endian.