From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by sourceware.org (Postfix) with ESMTPS id 9E06A3857405 for ; Thu, 5 May 2022 11:11:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9E06A3857405 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f44.google.com with SMTP id i5so5614494wrc.13 for ; Thu, 05 May 2022 04:11:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=8pAL+IvJ7k0W76CwDoxetukO4Bg6Ws24VD9nXuxLzHA=; b=DDmLIVuJpB1v/g4f81OKsKLq7j/dpUTy1AKRj6TkncNCzMFE5/m1szykjjT+CS2W89 HhxWS1OchGSRUdDTKXFfibiCMWd+tu3OivsBsVLIo6eNH5uGaitQizBY6ux0Kl7XYHfm SKnFs1XK1a/wC3vFHPduTkp4dZBrVZrvIsDI6+APSmHGqMAE0UTFD6/PiUm4/gSiBVIF cQ4rL1DyZk5OUdhADtDlNdYNuOj2O9hZF0XUxykm7ZhkSPd+n/UctrsBlt5uDT18bnUD WfMPXBG6WqJwgRZt2itw0dzKZzXSvoGHgV6c4588Hbm5zy7v/VUSUUUUd9LbC5dn6gO1 k8ag== X-Gm-Message-State: AOAM5322MQSujLZyMFVeb+NVNNpOyhSZRhZI142h36gxjkoFcp/oxwGY yHs7g+XLr7SGMKMsT22a3euuVcA1RcwWoA== X-Google-Smtp-Source: ABdhPJy0FxVUPbvD1kTeaJ0+IGLVPiSYtf7QzFm6SrP5luDFs3k7VlCnDs8L0arVUm6Om45z8jWZ6Q== X-Received: by 2002:a5d:64a6:0:b0:20c:64ef:c9cc with SMTP id m6-20020a5d64a6000000b0020c64efc9ccmr14768587wrp.190.1651749092097; Thu, 05 May 2022 04:11:32 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id bh26-20020a05600c3d1a00b003942a244ee8sm1220517wmb.45.2022.05.05.04.11.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 May 2022 04:11:31 -0700 (PDT) Message-ID: Date: Thu, 5 May 2022 12:11:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH] Don't define ARCH_cris for BFD64 Content-Language: en-US To: Alan Modra , Hans-Peter Nilsson Cc: binutils@sourceware.org References: <20220504075628.81292-1-luis.machado@arm.com> <88ada15d-c371-df10-368e-f1c9fb91c289@arm.com> <20220504143703.58AD620462@pchp3.se.axis.com> From: Pedro Alves In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2022 11:11:35 -0000 On 2022-05-04 23:37, Alan Modra via Binutils wrote: > OK, so this means we have two slightly different versions of cris > support. Configured to support cris directly with --target or > --enable-targets mentioning one of the cris tuples will always give > you a 64-bit bfd. On a 32-bit host configured with > --enable-targets=all you'll get a 32-bit bfd, and miss some support > for explicitly choosing and displaying targets. (The #ifdef comments > in config.bfd are used to generate targmatch.h, which gets included > into targets.c.) I guess I don't understand the logic fully, and if you have the patience for me, I'd like to understand it better. In the --enable-targets=all case with a 32-bit bfd, it seems counterintuitive to want to be able to choose and display cris, if its bfd supposedly wants 64-bit, given want64=true. If bfd says cris wants 64-bit bfd, and you have a 32-bit bfd, it seems weird to build it in 32-bit mode, and let users choose and use it? I just tried a 32-bit --enable-targets=all --disable-sim build of current master, and indeed we end up with these files built: $ ls bfd/*cris* bfd/aout-cris.lo bfd/aout-cris.o bfd/cpu-cris.lo bfd/cpu-cris.o bfd/elf32-cris.lo bfd/elf32-cris.o however, those are built with a 32-bit bfd ("#define BFD_ARCH_SIZE 32" in bfd/bfd.h), which if we trust win64=true (and 56fbd041853a "Fix gas/22304 by forcing a 64-bit bfd for cris*-*") is not supposed to happen. Currently, gas --enable-targets=all isn't very useful, as you can't make it assemble for non-primary targets AFAIK, but if it did, then a 32-bit --enable-targets=all build would assemble cris using 32-bit bfd, which I assume would be affected by gas/22304 again. Unlike gas however, a 32-bit --target-targets=all gdb knows how to cross-debug cris and will happily do it, again with a 32-bit bfd. Maybe the gas issue that led to making cris want 64-bit bfd doesn't affect any other tool, so meh, who cares, right?, but it still seems counterintuitive/strange to have tool dependencies or mismatches like that. Shouldn't instead BFD64 / want64 / TARGET64_LIBOPCODES_CFILES all agree in principle so we avoid these tool mismatches, where a port says it wants 64-bit bfd but then it can happen to be built and be used with 32-bit anyhow? Sometimes I wonder whether 32-bit bfd_vma is still worth it, though. FWIW, GDB always has 64-bit CORE_ADDR nowadays, even on 32-bit hosts. Anyhow, I got confused trying to figure out how all this is supposed to work, and I realize that the above may sound like a rant, though it was not intended, so sorry if it does. I guess other people who read this code for the first time may end up scratching their heads too.