Home Original page

Ping: [PATCH] objcopy: fix 32-bit build

Jan Beulich JBeulich@suse.com
Tue Jan 30 08:22:00 GMT 2018 
>>> 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
More information about the Binutils mailing list