public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Hans-Peter Nilsson <hp@axis.com>
To: Pedro Alves <pedro@palves.net>
Cc: <amodra@gmail.com>, <binutils@sourceware.org>
Subject: Re: [PATCH] Don't define ARCH_cris for BFD64
Date: Thu, 5 May 2022 14:56:08 +0200	[thread overview]
Message-ID: <20220505125608.D23F920444@pchp3.se.axis.com> (raw)
In-Reply-To: <ccfa44e7-7435-4e80-1054-cec678431a16@palves.net> (message from Pedro Alves on Thu, 5 May 2022 13:11:29 +0200)

> From: Pedro Alves <pedro@palves.net>
> Date: Thu, 5 May 2022 13:11:29 +0200

> 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
        ^^^^^
There's your problem! :)
(want64=true)

> supposed to happen.

Right.  I somehow thought with --enable-targets=all we'd get
a 64-bit bfd_vma but sure, then we'd not be discussing this.

But I agree we should make that change.

Host systems (with a compiler) without a 64-bit type these
days seem IMHO unlikely to be suitable as hosts, at least
not for --enable-targets=all and newer binutils (+gdb+sim).

brgds, H-P

  reply	other threads:[~2022-05-05 12:56 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-04  7:56 Luis Machado
2022-05-04  8:08 ` Alan Modra
2022-05-04  8:15   ` Luis Machado
2022-05-04  8:39     ` Alan Modra
2022-05-04 14:37       ` Hans-Peter Nilsson
2022-05-04 22:37         ` Alan Modra
2022-05-05  9:01           ` Luis Machado
2022-05-05 11:11           ` Pedro Alves
2022-05-05 12:56             ` Hans-Peter Nilsson [this message]
2022-05-06  0:56             ` Alan Modra
2022-05-06  2:35               ` Hans-Peter Nilsson
2022-05-06  9:09                 ` Luis Machado
2022-05-06  9:00               ` 32-bit archs, want64=true, and gas integers (Re: [PATCH] Don't define ARCH_cris for BFD64) Pedro Alves
2022-05-06  9:55                 ` 32-bit archs, want64=true, and gas integers Jan Beulich
2022-05-06 10:01                   ` Pedro Alves
2022-05-06 10:17                     ` Jan Beulich
2022-05-06 10:43                       ` Pedro Alves
2022-05-06 11:55                         ` Jan Beulich
2022-05-06 12:04                           ` Pedro Alves
2022-05-06 14:32                         ` Hans-Peter Nilsson
2022-05-06 14:44                           ` Pedro Alves
2022-05-07 20:19                             ` Hans-Peter Nilsson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220505125608.D23F920444@pchp3.se.axis.com \
    --to=hp@axis.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=pedro@palves.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).