This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]