Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>
To: Andrew Pinski <apinski@cavium.com>,
	gdb-patches@sourceware.org, binutils@sourceware.org
Subject: Re: [PATCH 1/3] Move AARCH64 ILP32 rejection handling
Date: Thu, 01 Sep 2016 09:43:00 -0000	[thread overview]
Message-ID: <2cad9002-f670-dc82-842a-859c469e8519@arm.com> (raw)
In-Reply-To: <1472715400-43043-2-git-send-email-apinski@cavium.com>

On 01/09/16 08:36, Andrew Pinski wrote:
> For AARCH64 ILP32, we reject compatibility too
> early on to support gdb ILP32.  This patch
> moves ILP32 rejection from compatible
> to elfNN_aarch64_merge_private_bfd_data
> which allows aarch64 and aarch64:ilp32
> to be handled correctly with gdb.
> An added bonus is that we can have an error
> message on why two object files are rejected.
> 
> OK?  Tested both binutils and gdb.
> 

You haven't explained why you've dropped these tests:

-  /* Otherwise if either a or b is the 'default' machine
-     then it can be polymorphed into the other.  */
-  if (a->the_default)
-    return b;
-
-  if (b->the_default)
-    return a;
-
-  /* So far all newer cores are
-     supersets of previous cores.  */
-  if (a->mach < b->mach)
-    return b;
-  else if (a->mach > b->mach)
-    return a;

R.

> Thanks,
> Andrew Pinski
> 
> 2016-08-31  Andrew Pinski  <apinski@cavium.com>
> 
> 	* cpu-aarch64.c (compatible):
> 	Don't reject different mach or ILP32 here.
> 	* elfnn-aarch64.c (elfNN_aarch64_merge_private_bfd_data):
> 	Add an error message on why endianess is rejected.
> 	Reject different ILP32/LP64 settings.
> 
> Signed-off-by: Andrew Pinski <apinski@cavium.com>
> ---
>  bfd/ChangeLog       |  8 ++++++++
>  bfd/cpu-aarch64.c   | 28 +++-------------------------
>  bfd/elfnn-aarch64.c | 17 ++++++++++++++++-
>  3 files changed, 27 insertions(+), 26 deletions(-)
> 
> diff --git a/bfd/ChangeLog b/bfd/ChangeLog
> index 59dfb2c..77b2b6b 100644
> --- a/bfd/ChangeLog
> +++ b/bfd/ChangeLog
> @@ -1,3 +1,11 @@
> +2016-08-31  Andrew Pinski  <apinski@cavium.com>
> +
> +	* cpu-aarch64.c (compatible):
> +	Don't reject different mach or ILP32 here.
> +	* elfnn-aarch64.c (elfNN_aarch64_merge_private_bfd_data):
> +	Add an error message on why endianess is rejected.
> +	Reject different ILP32/LP64 settings.
> +
>  2016-08-31  Alan Modra  <amodra@gmail.com>
>  
>  	* elf64-ppc.c (group_sections): Delete stub14_group_size.  Instead,
> diff --git a/bfd/cpu-aarch64.c b/bfd/cpu-aarch64.c
> index 596d241..6fb9133 100644
> --- a/bfd/cpu-aarch64.c
> +++ b/bfd/cpu-aarch64.c
> @@ -34,31 +34,9 @@ compatible (const bfd_arch_info_type * a, const bfd_arch_info_type * b)
>    if (a->arch != b->arch)
>      return NULL;
>  
> -  /* If a & b are for the same machine then all is well.  */
> -  if (a->mach == b->mach)
> -    return a;
> -
> -  /* Don't allow mixing ilp32 with lp64.  */
> -  if ((a->mach & bfd_mach_aarch64_ilp32) != (b->mach & bfd_mach_aarch64_ilp32))
> -    return NULL;
> -
> -  /* Otherwise if either a or b is the 'default' machine
> -     then it can be polymorphed into the other.  */
> -  if (a->the_default)
> -    return b;
> -
> -  if (b->the_default)
> -    return a;
> -
> -  /* So far all newer cores are
> -     supersets of previous cores.  */
> -  if (a->mach < b->mach)
> -    return b;
> -  else if (a->mach > b->mach)
> -    return a;
> -
> -  /* Never reached!  */
> -  return NULL;
> +  /* Machine compatibility is checked in
> +     elfNN_aarch64_merge_private_bfd_data.  */
> +  return a;
>  }
>  
>  static struct
> diff --git a/bfd/elfnn-aarch64.c b/bfd/elfnn-aarch64.c
> index 3435a3d..1e27501 100644
> --- a/bfd/elfnn-aarch64.c
> +++ b/bfd/elfnn-aarch64.c
> @@ -6530,11 +6530,26 @@ elfNN_aarch64_merge_private_bfd_data (bfd *ibfd, bfd *obfd)
>  
>    /* Check if we have the same endianess.  */
>    if (!_bfd_generic_verify_endian_match (ibfd, obfd))
> -    return FALSE;
> +    {
> +      (*_bfd_error_handler)
> +	(_("%B: endianness incompatible with that of the selected emulation"),
> +	 ibfd);
> +      return FALSE;
> +    }
>  
>    if (!is_aarch64_elf (ibfd) || !is_aarch64_elf (obfd))
>      return TRUE;
>  
> +  /* Don't allow mixing ilp32 with lp64.  */
> +  if ((bfd_get_arch_info (ibfd)->mach & bfd_mach_aarch64_ilp32)
> +      != (bfd_get_arch_info (obfd)->mach & bfd_mach_aarch64_ilp32))
> +    {
> +      (*_bfd_error_handler)
> +	(_("%B: ABI is incompatible with that of the selected emulation: \"%s\" != \"%s\""),
> +	 ibfd, bfd_get_target (ibfd), bfd_get_target (obfd));
> +      return FALSE;
> +    }
> +
>    /* The input BFD must have had its flags initialised.  */
>    /* The following seems bogus to me -- The flags are initialized in
>       the assembler but I don't think an elf_flags_init field is
> 


      reply	other threads:[~2016-09-01  9:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-30  0:26 [PATCH 0/3] Support AARCH64 ILP32 for gdb Andrew Pinski
2016-08-30  0:26 ` [PATCH 2/3] Add ILP32 support to gdb Andrew Pinski
2016-08-30  7:44   ` Andreas Schwab
2016-09-01  4:21     ` Andrew Pinski
2016-09-01  7:41       ` Andreas Schwab
2016-08-30  0:26 ` [PATCH 1/3] Move AARCH64 ILP32 rejection handling Andrew Pinski
2016-08-30  0:26 ` [PATCH 3/3] Handle ILP32 AARCH64 correctly for gdbserver Andrew Pinski
2016-08-30  8:01   ` Andreas Schwab
2016-08-31 10:42   ` Pedro Alves
2016-08-31 12:58     ` Yao Qi
2016-08-31 20:02       ` Andrew Pinski
2016-09-01  7:37 ` [PATCH v2 0/3] Support AARCH64 ILP32 for gdb Andrew Pinski
2016-09-01  7:36   ` [PATCH 2/3] Add ILP32 support to gdb Andrew Pinski
2016-09-01  9:50     ` Andreas Schwab
2016-09-01 13:13     ` Yao Qi
2016-09-01  7:37   ` [PATCH 3/3] Handle ILP32 AARCH64 correctly for gdbserver Andrew Pinski
2016-09-01  8:32     ` Andreas Schwab
2016-09-01  7:37   ` [PATCH 1/3] Move AARCH64 ILP32 rejection handling Andrew Pinski
2016-09-01  9:43     ` Richard Earnshaw (lists) [this message]

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=2cad9002-f670-dc82-842a-859c469e8519@arm.com \
    --to=richard.earnshaw@arm.com \
    --cc=apinski@cavium.com \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    /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