From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by sourceware.org (Postfix) with ESMTPS id 4D66B3857C59 for ; Thu, 2 Dec 2021 22:02:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4D66B3857C59 Received: by mail-pj1-x1035.google.com with SMTP id j6-20020a17090a588600b001a78a5ce46aso3640734pji.0 for ; Thu, 02 Dec 2021 14:02:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=sE91qow9ks3IdWTj7oe5guy78sqXP/0sZB1w0uzRufI=; b=enLB3LwHKFb2323afmXNF4zLzobkxxhRw3E8fuZlmQ1/mlwgcTkIbiuleW1BgGkVfD PAHfI/3HNDpjC3K2fGa3yLJgBP+6xREOOkMUqbP1/kGorVmjfa9IPer8pGkN//qKkxWD Xt8b3TGLQBr6gQwnrUtHtH0F31uZu2KZO5d1QK70SI0NprLJkSU9n8UkNvkiIp3Nq0Q2 uH1mevJiy0YDsa0fGtW4DEaP/g0ZcpGcVtFpWXPwNeDB9TleB6xJn1dl5tpUEGT/CfDT vySgLepZoxvNm8oBguZywlK4yLAzVSxGmk1w7Zq3WNBzMZKJE9rthBBm4E6HzmNh+iI0 N1PQ== X-Gm-Message-State: AOAM5304DjkkOzN+K+kueWHA5ZsJMT0iZdEfQAYJEBOZO2tLLBozWuqs MQTEedMimBlMs3JoNeFf5U8xvg28ylk= X-Google-Smtp-Source: ABdhPJy9tB0DllCSpG5CiatPRb0l+h48W2C3Qj0UjFs/qavZjeh+ERHrYubzFYP2TNmx+mP3+I7IMA== X-Received: by 2002:a17:90a:9294:: with SMTP id n20mr8913046pjo.69.1638482532055; Thu, 02 Dec 2021 14:02:12 -0800 (PST) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id 38sm496869pgl.73.2021.12.02.14.02.10 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Dec 2021 14:02:11 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 8A99D1140B2E; Fri, 3 Dec 2021 08:32:07 +1030 (ACDT) Date: Fri, 3 Dec 2021 08:32:07 +1030 From: Alan Modra To: binutils@sourceware.org Subject: Re: Don't compile some opcodes files when bfd is 32-bit only Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3032.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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, 02 Dec 2021 22:02:16 -0000 On Thu, Dec 02, 2021 at 11:48:50AM -0500, Mike Frysinger wrote: > On 02 Dec 2021 19:26, Alan Modra via Binutils wrote: > > On Thu, Dec 02, 2021 at 12:19:37AM -0500, Mike Frysinger wrote: > > > i don't > > > have specific familiarity with the bpf port as i didn't author it. i only > > > just finished overhauling the sim build & test logic to support testing in a > > > multitarget build so they can all (or most at this point) be tested at the > > > same time. and i can see the same runtime error you see now too. is the > > > 64-bit bfd setting easy to detect in subdirs ? > > > > I used > > if grep '#define BFD_ARCH_SIZE 64' ../bfd/bfd-in3.h > /dev/null > > in opcodes/configure.ac and made configure-opcodes depend on > > configure-bfd in the top level Makefile.def. bfd-in3.h is made during > > bfd configure. > > hmm, that seems messy. gdb & ld have specific --enable-64-bit-bfd options > (albeit, copied & pasted from bfd/configure.ac). should that instead be > refactored into e.g. config/bfd64.m4 and then all these subdirs get that > same configure logic ? You're right, it would be cleaner to do it that way. What we have in opcodes at the moment came about from me trying to automatically choose the set of opcodes targets that need a 64-bit bfd by parsing bfd config files. I gave up on implementing that idea, but was then in the mindset of depending on bfd config rather than depending on top-level config options. > > > if so, i think we can change > > > the sim to skip 64-bit-only ports if 64-bit bfd isn't available. > > > > Yes, I think that is the right way to go for --enable-targets=all. > > > > > riscv i think is a bit diff in that it supports 32-bit & 64-bit. > > > > You can argue that with the riscv maintainers. ;-) > > > > Note that if a user specifically wants a riscv32 sim then using > > --target=riscv32-elf or even --enable-targets=riscv32-elf will get > > them a 64-bit bfd. > > --enable-targets=all does not though, and riscv32 only needs a 32-bit bfd. > the symbols in question aren't tied to the bfd size. > > tbh, i haven't been following what's been going on, i just raise my head > when the sim fails to link. and it's failing to link now after this change. > -mike Reverting the opcodes Makefile changes will currently result in opcodes failing to link. The riscv opcodes objects now depend on riscv bfd objects that are only compiled for a 64-bit bfd. -- Alan Modra Australia Development Lab, IBM