This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Ping: [PATCH] objcopy: fix 32-bit build
- From: "Jan Beulich" <JBeulich at suse dot com>
- To: <binutils at sourceware dot org>
- Date: Wed, 24 Jan 2018 00:53:17 -0700
- Subject: Ping: [PATCH] objcopy: fix 32-bit build
- Authentication-results: sourceware.org; auth=none
- References: <5A55EBCF020000780019D1AE@prv-mh.provo.novell.com>
>>> On 10.01.18 at 10:32, <JBeulich@suse.com> wrote:
> I do assume this isn't sufficient to address the non-64-bit-BFD case as
> well, but it's not entirely clear what the right approach to deal with
> that would be. I also wonder whether it was really meant to have 59 bits
> set here, rather than 63.
Anyone? Or did I overlook some better fix which may have gone in
in the meantime?
Jan
> binutils/
> 2018-01-10 Jan Beulich <jbeulich@suse.com>
>
> * objcopy.c (merge_gnu_build_notes): Replace 64-bit constants by
> equivalent expressions.
>
> --- a/binutils/objcopy.c
> +++ b/binutils/objcopy.c
> @@ -2064,7 +2064,7 @@ merge_gnu_build_notes (bfd * abfd, asect
> For now though, since v1 and v2 was not intended to
> handle gaps, we chose an artificially large end
> address. */
> - end = (bfd_vma) 0x7ffffffffffffffUL;
> + end = ~((bfd_vma)1 << 63);
> break;
>
> case 8:
> @@ -2083,7 +2083,7 @@ merge_gnu_build_notes (bfd * abfd, asect
> For now though, since v1 and v2 was not intended to
> handle gaps, we chose an artificially large end
> address. */
> - end = (bfd_vma) 0x7ffffffffffffffUL;
> + end = ~((bfd_vma)1 << 63);
> }
> break;
>