NetBSD Problem Report #15303

Received: (qmail 14411 invoked from network); 19 Jan 2002 22:10:42 -0000
Message-Id: <20020119221039.7398C2687@kabel208245.kabel.utwente.nl>
Date: Sat, 19 Jan 2002 23:10:39 +0100 (CET)
From: reinoud@netbsd.org
Reply-To: reinoud@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: Crosscompiling Alpha->arm32 fails due to LP64 -> LP32 trouble
X-Send-Pr-Version: 3.95

>Number:         15303
>Category:       port-arm
>Synopsis:       Crosscompiling Alpha->arm32 fails due to LP64 -> LP32 trouble
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-arm-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jan 19 22:11:01 +0000 2002
>Closed-Date:    Sun Dec 07 16:42:12 +0000 2003
>Last-Modified:  Thu Feb 06 22:43:10 +0000 2014
>Originator:     Reinoud Zandijk
>Release:        NetBSD starbuck 1.5ZA NetBSD 1.5ZA (config.starbuck) #0: Sat Jan 19 15:08:37 CET 2002
>Organization:
NetBSD

>Environment:

cvs.netbsd.org sources dating from a few minutes ago. i.e. 19 jan 2002,
23:02 CET. Crosscompiling on a 1.5ZA kernel with 1.5.2 libs (AFAIK!).

>Description:

In my efford to get arch/acorn32 fully ELF operatable i've tried
cross-compiling acorn32 in ELF on an Alpha.

To compile it this way cross compile with the following line :

./build.sh -a arm -m acorn32 -D /mnt/bigstuff/acorn32/snapshot/ -T 
/mnt/bigstuff/acorn32/toolset/ -O /mnt/bigstuff/acorn32/obj -R 
/mnt/bigstuff/acorn32/release/ -u

Unfortunataly I got the assembler errors prolly connected to ints getting 
zero or rotating after shifting or so wich breaks on LP64 ...

I think its a relative small patch in the offset calculation of PC relative
loading or so ... here is the data ... happy hacking ;)

-----

dependall ===> gnu/usr.bin/groff/hpftodit
/usr/tmp/acorn32-toolset//bin/arm--netbsdelf-c++ -O2  -Werror   
-DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -D
HAVE_SYS_DIR_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 
-DRET_TYPE_SRAND_IS_VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -D
HAVE_CC_LIMITS_H=1 -DRETSIGTYPE=void -DHAVE_STRUCT_EXCEPTION=1 
-DHAVE_UNISTD_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1 -DHAVE_S
TRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 
-DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE
_STRSEP=1 -DHAVE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 
-I/usr/sources/cvs.netbsd.org/src/gnu/usr.bin/groff/hpftodit/../include 
-I/usr/sources/
cvs.netbsd.org/src/gnu/usr.bin/groff/hpftodit/../../../dist/groff/src/include 
-nostdinc -isystem /usr/tmp/acorn32-snapshot/usr/include  -c

/usr/sources/cvs.netbsd.org/src/gnu/usr.bin/groff/hpftodit/../../../dist/groff/src/utils/hpftodit/hpftodit.cc
/var/tmp/ccT0aLQB.s: Assembler messages:
/var/tmp/ccT0aLQB.s:765: Error: Value of 4294967296 too large for field of 4 bytes at 2536
/var/tmp/ccT0aLQB.s:836: Error: Value of 4294967392 too large for field of 4 bytes at 2808
/var/tmp/ccT0aLQB.s:904: Error: Value of 4294967548 too large for field of 4 bytes at 3000
/var/tmp/ccT0aLQB.s:978: Error: Value of 4294967344 too large for field of 4 bytes at 3248
/var/tmp/ccT0aLQB.s:1334: Error: Value of 4294967332 too large for field of 4 bytes at 4508
/var/tmp/ccT0aLQB.s:1336: Error: Value of 4294967752 too large for field of 4 bytes at 4516
/var/tmp/ccT0aLQB.s:1337: Error: Value of 4294967716 too large for field of 4 bytes at 4520
/var/tmp/ccT0aLQB.s:1338: Error: Value of 4294967728 too large for field of 4 bytes at 4524
/var/tmp/ccT0aLQB.s:1379: Error: Value of 4294967428 too large for field of 4 bytes at 4636
/var/tmp/ccT0aLQB.s:1407: Error: Value of 4294967440 too large for field of 4 bytes at 4716
/var/tmp/ccT0aLQB.s:1476: Error: Value of 4294967800 too large for field of 4 bytes at 4924
/var/tmp/ccT0aLQB.s:1524: Error: Value of 4294967404 too large for field of 4 bytes at 5072
/var/tmp/ccT0aLQB.s:1525: Error: Value of 4294967464 too large for field of 4 bytes at 5076
/var/tmp/ccT0aLQB.s:1560: Error: Value of 4294967452 too large for field of 4 bytes at 5176
/var/tmp/ccT0aLQB.s:1707: Error: Value of 4294967440 too large for field of 4 bytes at 5532
/var/tmp/ccT0aLQB.s:1831: Error: Value of 4294967764 too large for field of 4 bytes at 5968
/var/tmp/ccT0aLQB.s:2103: Error: Value of 4294967452 too large for field of 4 bytes at 6996
/var/tmp/ccT0aLQB.s:2114: Error: Value of 4294967584 too large for field of 4 bytes at 7048
/var/tmp/ccT0aLQB.s:2122: Error: Value of 4294967620 too large for field of 4 bytes at 7092
/var/tmp/ccT0aLQB.s:2123: Error: Value of 4294967632 too large for field of 4 bytes at 7096
*** Error code 1

Stop.

-----------


I tracked down the first one in the file near :

static
void check_type()
{
  require_tag(type_tag);
  if (tag_info(type_tag).value != 0) {
    if (tag_info(type_tag).value == 2)
      fatal("cannot handle TrueType tfm files");
    fatal("unknown type tag %1", int(tag_info(type_tag).value));
  }
}

with the following functions :

inline
entry &tag_info(tag_type t)
{ 
  return tags[t - min_tag];
}

and
  min_tag = 400,

and

static 

void require_tag(tag_type t)
{
  if (!tag_info(t).present)
    fatal("tag %1 missing", int(t));
}



its the int(tag_info(type_tag).value) thats breaking it ... it gets 
compiled into :



.............
.Lfe9:  
        .size    read_tags__FR4File,.Lfe9-read_tags__FR4File
        .align  2
.LC14:
        .ascii  "cannot handle TrueType tfm files\000"
        .align  2
.LC15:
        .ascii  "unknown type tag %1\000"
        .align  2
        .type    check_type__Fv,%function
check_type__Fv:
        @ args = 0, pretend = 0, frame = 12
        @ frame_needed = 1, current_function_anonymous_args = 0
        mov     ip, sp
        stmfd   sp!, {r4, r5, fp, ip, lr, pc}
        sub     fp, ip, #4
        mov     r0, #400
        ldr     r4, .L124
        sub     sp, sp, #12
        bl      require_tag__F8tag_type
        ldr     r3, [r4, #8]
        cmp     r3, #0
        beq     .L118
        cmp     r3, #2
        ldr     r5, .L124+4
        bne     .L120
        mov     r1, r5
        mov     r2, r5
        mov     r3, r5
        ldr     r0, .L124+8
        bl      fatal__FPCcRC6errargN21
.L120:
        ldr     r1, [r4, #8]
        sub     r4, fp, #32
        mov     r0, r4
        bl      __6errargi
        mov     r1, r4
        mov     r2, r5
        ldr     r0, .L124+12
        mov     r3, r2
        bl      fatal__FPCcRC6errargN21
        b       .L123
.L125:
        .align  2
.L124:
        .word   tags+4294967296	<=== obvious fault ... is this supposed to
                                     be a signed int/wrap ?? on 32 bits 
                                     processors this gets 2^32 => 0
        .word   empty_errarg
        .word   .LC14
        .word   .LC15
.L123:
.L118:
        ldmea   fp, {r4, r5, fp, sp, pc}
.Lfe10:
        .size    check_type__Fv,.Lfe10-check_type__Fv
        .align  2


--------


>How-To-Repeat:
Just try to cross compile :-/

>Fix:
Propably a small bugfix in calculating offsets to be signed 4 byte ints
instead of signed/unsigned 64 bits like it is now ... 

Maybe they made the assumption that a `long' is 32 bits ?

>Release-Note:
>Audit-Trail:

From: Reinoud Zandijk <reinoud@netbsd.org>
To: Richard.Earnshaw@arm.com
Cc: gnats-bugs@netbsd.org
Subject: toolchain/15303
Date: Tue, 5 Feb 2002 01:20:28 +0100

 Hiya Richard,

 a fix that might give some important insights is that the file compiles 
 fine when compiled with -O0 but fails with the same error with -O1 and -O2 
 ... so it looks to be related in the optimising scripts....

 Cheers,
 Reinoud

Responsible-Changed-From-To: port-arm32-maintainer->port-arm-maintainer 
Responsible-Changed-By: bjh21 
Responsible-Changed-When: Wed Mar 20 08:37:57 PST 2002 
Responsible-Changed-Why:  
Moved bug to port-arm category, since it applies to all NetBSD/arm systems. 
State-Changed-From-To: open->feedback 
State-Changed-By: jdolecek 
State-Changed-When: Wed Nov 26 21:22:08 UTC 2003 
State-Changed-Why:  
It should be possible now with gcc 3.3.2 nb1 in tree. Can you 
confirm this problem still exists? 
State-Changed-From-To: feedback->closed 
State-Changed-By: reinoud 
State-Changed-When: Sun Dec 7 15:19:53 UTC 2003 
State-Changed-Why:  
Problem can't be reproduced anymore with the import of the new gcc 3.x toolchain. Crosscompiled binaries seem to work fine and without problems. When breakage occures they deserve a PR# of their own. 

>Unformatted:

Home	PR Database Search