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 30.01.18 at 01:13, <amodra@gmail.com> wrote:
> 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.
Thanks!
Jan