Bug 14933

Summary: ar & ranlib generate truncated files on 32bit filesystem
Product: binutils Reporter: Alan Hourihane <alanh>
Component: binutilsAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: hjl.tools
Priority: P2    
Version: 2.23   
Target Milestone: ---   
URL: http://sourceware.org/ml/binutils/2012-12/msg00112.html
Host: Target:
Build: Last reconfirmed:
Attachments: test case

Description Alan Hourihane 2012-12-08 00:20:17 UTC
Hi,

Just moved from binutils 2.22 to 2.23 and ar & ranlib generated bad archives with the message "file truncated".

Looking into the problem reveals that in archive.c we have at around line 2414....

file_ptr firstreal;
....
file_ptr max_first_real;

max_first_real <<= 31;

then later we do....

      /* The archive file format only has 4 bytes to store the offset
         of the member.  Check to make sure that firstreal has not grown
         too big.  */
      if (firstreal >= max_first_real)
        {
          bfd_set_error (bfd_error_file_truncated);
          return FALSE;
        }

I added a check that did this in the errored function.

printf("CHECK %d %d (%d)\n",firstreal,max_first_real,sizeof(file_ptr));

It came back with....

CHECK 104 -2147483648 (4)

So, shouldn't firstreal/max_first_real be ufile_ptr's ?
Comment 1 Alan Hourihane 2012-12-08 12:51:55 UTC
Actually, I think I found the patch by Nick Clifton back in June which seems to suggest this is to catch overflows for 4Gb archives.

In light of that, I think it really should be ufile_ptr's and that max_first_real should be.....

max_first_real = -1; (or 0xffffffff)
Comment 2 Alan Hourihane 2012-12-08 14:28:10 UTC
Scratch that last comment. Duh.
Comment 3 H.J. Lu 2012-12-08 15:16:21 UTC
What is your host machine? What is the size of your file_ptr?
Comment 4 Alan Hourihane 2012-12-08 15:26:06 UTC
Hi,it's an Atari m68k. file_ptr as mentioned in comment #1 is 4 bytes.
Comment 5 H.J. Lu 2012-12-08 15:50:52 UTC
(In reply to comment #4)
> Hi,it's an Atari m68k. file_ptr as mentioned in comment #1 is 4 bytes.

Does Atari m68k have 64-bit integer?
Comment 6 Alan Hourihane 2012-12-09 00:44:23 UTC
Yes, 64bits is "unsigned long long"
Comment 7 H.J. Lu 2012-12-09 00:56:07 UTC
Do you have a testcase which only requires binutils
to reproduce?
Comment 8 Alan Hourihane 2012-12-09 09:00:23 UTC
Created attachment 6776 [details]
test case
Comment 9 Alan Hourihane 2012-12-09 09:01:23 UTC
With the binary file you can do...

ar rcv libxxx.a main.o
a - main.o
ar: libxxx.a: File truncated
Comment 10 H.J. Lu 2012-12-09 17:35:11 UTC
A patch is posted at

http://sourceware.org/ml/binutils/2012-12/msg00112.html
Comment 11 Sourceware Commits 2012-12-09 18:01:44 UTC
CVSROOT:	/cvs/src
Module name:	src
Changes by:	hjl@sourceware.org	2012-12-09 18:01:39

Modified files:
	bfd            : ChangeLog archive.c 

Log message:
	Properly check indicies bigger than 4Gb
	
	PR binutils/14933
	* archive.c (bsd_write_armap): Properly check indicies bigger
	than 4Gb.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5877&r2=1.5878
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/archive.c.diff?cvsroot=src&r1=1.92&r2=1.93
Comment 12 Sourceware Commits 2012-12-09 18:06:48 UTC
CVSROOT:	/cvs/src
Module name:	src
Branch: 	binutils-2_23-branch
Changes by:	hjl@sourceware.org	2012-12-09 18:06:44

Modified files:
	bfd            : ChangeLog archive.c 

Log message:
	Properly check indicies bigger than 4Gb
	
	PR binutils/14933
	* archive.c (bsd_write_armap): Properly check indicies bigger than
	4Gb.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&only_with_tag=binutils-2_23-branch&r1=1.5758.2.31&r2=1.5758.2.32
http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/archive.c.diff?cvsroot=src&only_with_tag=binutils-2_23-branch&r1=1.87&r2=1.87.4.1
Comment 13 H.J. Lu 2012-12-09 18:07:17 UTC
Fixed.