This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Ping: [PATCH] objcopy: fix 32-bit build
On Mon, Jan 29, 2018 at 02:43:40AM -0700, Jan Beulich wrote:
> >>> On 29.01.18 at 00:04, <amodra@gmail.com> wrote:
> > On Wed, Jan 24, 2018 at 12:53:17AM -0700, Jan Beulich wrote:
> >> >>> On 10.01.18 at 10:32, <JBeulich@suse.com> wrote:
> >> > --- 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;
> >
> > Why not use "(bfd_vma) -1"?
>
> Well - why was the original value not 0xffffffffffffffff?
I suspect the intent was to use the largest positive bfd_signed_vma,
but Nick typoed the number of 'f' chars, and of course got it wrong
for 32-bit. "(bfd_vma) -1 >> 1" would have been right if that was
his intention. But the value used does not matter much. Any value
hugely larger than what is expected for a .gnu.build.attributes should
work from what I can see of the code.
I'm going to commit the following.
* objcopy.c (merge_gnu_build_notes): Use (bfd_vma) -1 as
"artificially large" end address.
diff --git a/binutils/objcopy.c b/binutils/objcopy.c
index 1e39f6d..8cdf27a 100644
--- a/binutils/objcopy.c
+++ b/binutils/objcopy.c
@@ -2064,7 +2064,7 @@ merge_gnu_build_notes (bfd * abfd, asection * sec, bfd_size_type size, bfd_byte
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;
break;
case 8:
@@ -2083,7 +2083,7 @@ merge_gnu_build_notes (bfd * abfd, asection * sec, bfd_size_type size, bfd_byte
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;
}
break;
--
Alan Modra
Australia Development Lab, IBM