contrib@iso.estec.nl (contrib (AM Davidson)) (11/10/89)
In article <127@geysir.os.is> eik@os.is (Einar Kjartansson) writes: >Whe I try to make perl version 3.0, patch level 1, I get the following >output. I tried this also telling perl to use its onw malloc, it made no >difference. This looks like an error in the hp-ux library. >The system is hp-ux 3.10 running on a HP 9000/825. > > cc array.o cmd.o cons.o consarg.o doarg.o doio.o dolist.o dump.o >eval.o form.o hash.o malloc.o perly.o regcomp.o regexec.o stab.o str.o >toke.o util.o perl.o -lm -ldbm -o perl >/bin/ld: Target of conditional branch is out of range > Reference from: /lib/libc.a(syscall.o)(0x3c) >/bin/ld: Invalid fixups exist >*** Error code 1 > >Stop. >-- > Einar Kjartansson | eik@os.is I had the same problem (on an 840) and called the local support centre - they were very helpful and acknowledged that it is a bug (fixed in HPUX 7.0). The good news is that there is a work around. Do the following: ar xv /lib/libc.a cerror.o syscall.o to extract the offending routines. Now patch them in with the rest of the .o files and link directly, viz: ld /lib/crt0.o array.o cmd.o cons.o consarg.o doarg.o doio.o \ dolist.o dump.o eval.o form.o hash.o perly.o regcomp.o \ regexec.o stab.o str.o toke.o util.o perl.o \ cerror.o syscall.o \ -lm -ldbm \ -lc \ -o perl You'll have to do the same trick with the link of taintperl. Oh BTW, don't use Perl's own malloc - it'll go crazy. Murray. -- =============================================================================== | A.M. Davidson Tel (0)1719-84025 Fax (0)1719-17401 Telex 39098ESTC NL | | mail : ISO Project, ESTEC, PO Box 227, 2200 AG Noordwijk, The Netherlands. | | e-mail: ..mcvax!hp4nl!estec!iso!contrib or contrib@iso.estec.nl | ===============================================================================
ggordon@agsm.ucla.edu (Glen Gordon) (11/11/89)
From article <127@geysir.os.is>, by eik@os.is (Einar Kjartansson): > Whe I try to make perl version 3.0, patch level 1, I get the following > output. I tried this also telling perl to use its onw malloc, it made no > difference. This looks like an error in the hp-ux library. > The system is hp-ux 3.10 running on a HP 9000/825. > > cc array.o cmd.o cons.o consarg.o doarg.o doio.o dolist.o dump.o > eval.o form.o hash.o malloc.o perly.o regcomp.o regexec.o stab.o str.o > toke.o util.o perl.o -lm -ldbm -o perl > /bin/ld: Target of conditional branch is out of range > Reference from: /lib/libc.a(syscall.o)(0x3c) > /bin/ld: Invalid fixups exist > *** Error code 1 > > Stop. > -- > Einar Kjartansson | eik@os.is > Orkustofnun (National Energy Authority) | eik@geysir.uucp > Grensasvegi 9, IS-108 Reykjavik, Iceland | mcvax!hafro!geysir!eik > Phone: 354-1-83600 Fax: 354-1-688896 Home: 354-1-16407 I too had this problem on HP-UX 3.11 until I undef'd SYSCALL in config.sh and reran the .SH scripts. After that all went well and all the tests ran perfectly. I assume that HP's syscall, which is not documented anywhere I know about is not intended for public consumption. -- Glen Gordon UCLA, Anderson Graduate School Of Management
kamat@uceng.UC.EDU (Govind N. Kamat) (11/13/89)
In article <1322@iso.estec.nl> contrib@iso.estec.nl (contrib (AM Davidson)) writes: In article <127@geysir.os.is> eik@os.is (Einar Kjartansson) writes: >Whe I try to make perl version 3.0, patch level 1, I get the following >output. I tried this also telling perl to use its onw malloc, it made no >difference. This looks like an error in the hp-ux library. I had the same problem (on an 840) and called the local support centre - they were very helpful and acknowledged that it is a bug (fixed in HPUX 7.0). The good news is that there is a work around. Umm. The bad news is that syscall on HP-UX seems to be buggy, just like many other things on it. #include <sys/types.h> #include <sys/stat.h> #include <syscall.h> main() { syscall(SYS_mkdir, "/usr/tmp/tst", 0755); } ====> Core Dump on Series 800s. You may wish to wait until all these problems are fixed. I just undef'ed SYSCALL in Perl's config.h. -- Govind N. Kamat College of Engineering kamat@uceng.UC.EDU University of Cincinnati Cincinnati, OH 45221, USA
jand@kuling.UUCP (Jan Dj{rv) (11/13/89)
In article <KAMAT.89Nov12133840@uceng.UC.EDU> kamat@uceng.UC.EDU (Govind N. Kamat) writes: [stuff about compiling perl deleted] >Umm. The bad news is that syscall on HP-UX seems to be buggy, just >like many other things on it. > > #include <sys/types.h> > #include <sys/stat.h> > #include <syscall.h> > main() > { > syscall(SYS_mkdir, "/usr/tmp/tst", 0755); > } > >====> Core Dump on Series 800s. > >You may wish to wait until all these problems are fixed. I just >undef'ed SYSCALL in Perl's config.h. > >-- >Govind N. Kamat College of Engineering >kamat@uceng.UC.EDU University of Cincinnati > Cincinnati, OH 45221, USA I was surprised to hear that syscall doesn't work on 800 series. I have used perl on our 835 and never had problems with syscall. This led me to belive that something was wrong with the supplied program above. After some fiddling and testing I found that: 1. Kamat was right, his program above doesn't work (sorry for not beliving you) 2. This however does work: #include <sys/types.h> #include <sys/stat.h> #include <syscall.h> main() { long l = 0; syscall(SYS_mkdir, "/usr/tmp/tst", 0755); } Note that "long l;" doesn't work, the initializer is nessecery. Could some guru please explain what is going on here? Jan D.
tml@hemuli.atk.vtt.fi (Tor Lillqvist) (11/14/89)
In article <1322@iso.estec.nl> contrib@iso.estec.nl (contrib (AM Davidson)) writes: >Oh BTW, don't use Perl's own malloc - it'll go crazy. It is possible to use perl's malloc if you patch it. I don't have diffs handy, but I remember two changes were necessary on the hp9000s800: Use the strut field in the overhead union: #if defined(mips) || defined(sparc) || defined(hp9000s800) double strut; /* alignment problems */ #endif and change the test for corrupt pointers to #ifdef hp9000s800 if (*((unsigned int*)p) != 0 && (*((unsigned int*)p) > 0x80000000 || *((unsigned int*)p) < 0x40000000)) #else -- Tor Lillqvist, VTT/ATK
jand@kuling.UUCP (Jan Dj{rv) (11/14/89)
In article <1989Nov10.174805.24464@agsm.ucla.edu> ggordon@agsm.ucla.edu (Glen Gordon) writes:
:From article <127@geysir.os.is>, by eik@os.is (Einar Kjartansson):
:> Whe I try to make perl version 3.0, patch level 1, I get the following
:> output. I tried this also telling perl to use its onw malloc, it made no
:> difference. This looks like an error in the hp-ux library.
:> The system is hp-ux 3.10 running on a HP 9000/825.
:>
:> cc array.o cmd.o cons.o consarg.o doarg.o doio.o dolist.o dump.o
:> eval.o form.o hash.o malloc.o perly.o regcomp.o regexec.o stab.o str.o
:> toke.o util.o perl.o -lm -ldbm -o perl
:> /bin/ld: Target of conditional branch is out of range
:> Reference from: /lib/libc.a(syscall.o)(0x3c)
:> /bin/ld: Invalid fixups exist
:> *** Error code 1
:>
:> Stop.
:> --
:> Einar Kjartansson | eik@os.is
:> Orkustofnun (National Energy Authority) | eik@geysir.uucp
:> Grensasvegi 9, IS-108 Reykjavik, Iceland | mcvax!hafro!geysir!eik
:> Phone: 354-1-83600 Fax: 354-1-688896 Home: 354-1-16407
:I too had this problem on HP-UX 3.11 until I undef'd SYSCALL in
:config.sh and reran the .SH scripts. After that all went well and all the tests ran perfectly.
:I assume that HP's syscall, which is not documented anywhere I know about
:is not intended for public consumption.
:--
:Glen Gordon
:UCLA, Anderson Graduate School Of Management
I had exactly the same problem. The reason for this error is that syscall
has a branch to $cerror at the specified location (0x3c) and I guess that
the branch is too long (bytewise) for the assembler. (NOTE I'm only guessing
since I don't understand HPPA).
The fix we made was to extract syscall.o and cerror.o from /lib/libc.a
(ar x /lib/libc.a syscall.o cerror.o)
and put these in front of the other objectfiles when linking, thus
bringing syscall and cerror "closer together".
That is:
cc syscall.o cerror.o [ rest of .o ] -lm -ldbm -o perl
Everything worked nicely.
I really don't know if my "explanation" makes any sense to you but the point
is that it works (or at least seems to work).
Further info from somebody that understands HPPA would be greatly
appriceated.
Jan D.bla@hpcupt1.HP.COM (Brad Ahlf) (11/22/89)
> I had exactly the same problem. The reason for this error is that syscall > has a branch to $cerror at the specified location (0x3c) and I guess that > the branch is too long (bytewise) for the assembler. (NOTE I'm only guessing > since I don't understand HPPA). > > Further info from somebody that understands HPPA would be greatly > appriceated. > Jan D. ---------- This is essentially correct. The assembler code for syscall.o used a short branch code sequence when it should use a long branch code sequence. When the syscall ends up more than a short branch away, the linker complains. I believe that this has been fixed in 7.0. Brad Ahlf HP Languages Technical Support
cary@hpclcac.HP.COM (Cary Coutant) (11/28/89)
> This is essentially correct. The assembler code for syscall.o used a short > branch code sequence when it should use a long branch code sequence. When > the syscall ends up more than a short branch away, the linker complains. I > believe that this has been fixed in 7.0. More precisely, the incorrect code in syscall.o was a conditional branch to the external symbol $cerror (in cerror.o). The linker can fix unconditional short branches (BL instructions) whose targets are too far away, but it cannot fix conditional branches (COMB, etc., instructions). A BL has a range of +/-256K, while a COMB has a range of only +/-2K; thus the conditional branches are legitimate only to local labels. In 7.0, syscall() was fixed so that it uses the BL instruction to reach $cerror. Cary Coutant, Series 800 Linker Project Manager HP California Languages Lab
cary@hpclcac.HP.COM (Cary Coutant) (11/28/89)
> #include <sys/types.h> > #include <sys/stat.h> > #include <syscall.h> > main() > { > syscall(SYS_mkdir, "/usr/tmp/tst", 0755); > } > > ====> Core Dump on Series 800s. This problem is due to the fact that syscall() must shift all of its arguments down one before transferring to the system call gateway. Since it doesn't know how many arguments were actually supplied, it always copies enough for the most demanding system call. Unfortunately, in this example, the stack frame for main() is small enough that syscall actually destroys the return address in this process. By adding a local variable, as one poster suggested, or by adding a few dummy parameters -- e.g., syscall(SYS_mkdir, "/usr/tmp/tst", 0755, 0, 0, 0); -- the problem can be avoided. I'm not aware that anyone has discovered this problem before; thanks for reporting it! Cary Coutant, Series 800 Linker Project Manager HP California Languages Lab
stacy@hpcupt1.HP.COM (Stacy Martelli) (12/05/89)
/ hpcupt1:comp.sys.hp / cary@hpclcac.HP.COM (Cary Coutant) / 4:02 pm Nov 27, 1989 / > #include <sys/types.h> > #include <sys/stat.h> > #include <syscall.h> > main() > { > syscall(SYS_mkdir, "/usr/tmp/tst", 0755); > } > > ====> Core Dump on Series 800s. > This problem is due to the fact that syscall() must shift all of its > arguments down one before transferring to the system call gateway. > Since it doesn't know how many arguments were actually supplied, > it always copies enough for the most demanding system call. > Unfortunately, in this example, the stack frame for main() is small > enough that syscall actually destroys the return address in this > process. By adding a local variable, as one poster suggested, or > by adding a few dummy parameters -- e.g., > > syscall(SYS_mkdir, "/usr/tmp/tst", 0755, 0, 0, 0); > I'm not aware that anyone has discovered this problem before; > thanks for reporting it! > > Cary Coutant Actually, I don't know if this is the problem you are seeing or not, but it is not the problem I fixed from a bug report that was filed by someone reading this notes string -- I fixed the stack copying problem some time ago. The problem I found was in some code having to do with lightweight system calls. Bits were being deposited in a scratch register without clearing it out first. It just so happens that this is the register syscall uses to do the argument shift. The symptom for this was a segmentation violation and when the core is examined it looks like we branched to and address between 0x200 and 0x300. The problem has been fixed for 8.0. The same workaround Cary describes should work however, you should specify 9 arguments after the system call number to be sure to zero out the scratch register. syscall(SYS_mkdir, "/usr/tmp/tst", 0755, 0, 0, 0, 0, 0, 0, 0); Stacy Martelli HP-UX Kernel Lab