From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25825 invoked by alias); 22 Feb 2018 17:39:08 -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 25814 invoked by uid 89); 22 Feb 2018 17:39:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=arranging, H*c:alternative, company, heard X-HELO: mail-ot0-f177.google.com Received: from mail-ot0-f177.google.com (HELO mail-ot0-f177.google.com) (74.125.82.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Feb 2018 17:39:05 +0000 Received: by mail-ot0-f177.google.com with SMTP id a7so5333616otk.9 for ; Thu, 22 Feb 2018 09:39:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TA84ANRwwfCBtgDUfltPIOuBYxifhweqZNLjDqBJy8Y=; b=LlUGVFMIMSoAnk8IyaOB1V8KyWCy14LaiNBsN+Xgk3KrIzHruK/o8EX+J0AdWXu8Hj zXYmlNP3vZH6aglqS6OkWEKqNbN5d2aKC58bg+97/ptv89bs2MNcK0BJ90XI975QjmzJ HwwvdaWGxrywsuyfj817BxbVJPZ3UjdrxsQ+qlY55k5fkogRscGEFFkecRSxWPItwGBN rGooVRPSS7qOD7/3ZyHe3eSPzA3m7OueM84deXWCcOb8DZgLIIytZWol9bzvMxQCE8hA yXpaKu6IMuE2fNz1uTI2SCd9ogS8Cc2trIs580NrAg7qQCwkDGJ+MpWMvggfMm8ixZzl w0uw== X-Gm-Message-State: APf1xPBqGtakkCbx4BNcixMeiuGPj7A4p8BcXJYCnfGAg4V9vlAJO33Q MuZZKssWvJbZmFJx48rXvbLJzk1esB1bgc2OgzkoPlv+ X-Google-Smtp-Source: AG47ELsNXlrqkHnfRYDD7uaO0Z1sdO9ijbtyCxsvQj/6HrzD+RD+ZwDVFDhgkrg2zMHj2bjxyBGpCV0elvhrf2IFfKA= X-Received: by 10.157.67.121 with SMTP id y54mr6003714oti.117.1519321143911; Thu, 22 Feb 2018 09:39:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.152.100 with HTTP; Thu, 22 Feb 2018 09:39:03 -0800 (PST) In-Reply-To: <87371tq6uz.fsf@tromey.com> References: <20171010233010.58471-1-peeter.joot@lzlabs.com> <87371tq6uz.fsf@tromey.com> From: Peeter Joot Date: Thu, 22 Feb 2018 17:39:00 -0000 Message-ID: Subject: Re: [PATCH] review request: implementing DW_AT_endianity To: Tom Tromey Cc: gdb-patches@sourceware.org, Peeter Joot , Simon Marchi Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-02/txt/msg00322.txt.bz2 I'm still holding the patch for submission. I'd handled all the reviewer comments I received, implemented the tests suggestion by the reviewers, and verified that I introduced no test regressions. Also, the gcc side issues I noticed testing this are already fixed in the latest version (trunk, but perhaps one of the releases now too). Unfortunately, the FSF attribution required for me to submit this formally on behalf of the company I work for has been delayed repeatedly. The last I heard from the company lawyer who was arranging the attribution is that there's just a few more i's and t's to dot and cross, but it should be done soon. Let me try your differs from arch suggestion. With respect to the gdbarch parameter, I'm not sure, as it's been a while since I worked on this, and will have to inspect what I was doing before I can answer. Peeter -- Peeter Note that my preferred email address is now: peeterjoot@protonmail.com On Thu, Feb 22, 2018 at 12:20 PM, Tom Tromey wrote: > >>>>> "Peeter" == Peeter Joot writes: > > I happened to run across this patch today. > > What's the status of it? > > Peeter> +enum bfd_endian > Peeter> +type_byte_order (struct gdbarch * gdbarch, struct type *type) > Peeter> +{ > Peeter> + if (TYPE_ENDIANITY_BIG (type)) > Peeter> + return BFD_ENDIAN_BIG; > Peeter> + else if (TYPE_ENDIANITY_LITTLE (type)) > Peeter> + return BFD_ENDIAN_LITTLE; > Peeter> + if (!gdbarch) > Peeter> + gdbarch = get_type_arch (type); > Peeter> + return gdbarch_byte_order (gdbarch); > > Does it ever make sense to call type_byte_order with a gdbarch other > than the type's gdbarch? I would assume not but I'm not really sure. > What would this mean? > > Anyway, if it doesn't make sense, then I'd suggest just removing the > gdbarch parameter. > > Peeter> + unsigned int flag_endianity_big : 1; > Peeter> + unsigned int flag_endianity_little : 1; > > It also seems to me that perhaps only a single bit is needed -- > something like: > > unsigned int flag_endian_differs_from_arch : 1; > > Then type_byte_order could do: > > enum bfd_endian endian = gdbarch_byte_order (...); > if (blah blah flag_endian_differs_from_arch) > endian = (endian == BFD_ENDIAN_LITTLE) ? BFD_ENDIAN_BIG : > BFD_ENDIAN_LITTLE; > > Of course this only makes sense if the arch endianness can't change > somehow, and if only the type's arch can be used to get the endianness. > > Tom >