make bug, gcc stuff, posting binaries, more diffs, LONG
Alex S. Crain
alex at umbc3.UMD.EDU
Wed Jun 22 03:29:21 AEST 1988
This article is aimed at folks compiling gcc, and covers everything that
I have to say on the subject. (back to real work for awhile). This is also
intended as a global reply to the globs of mail that I've been recieving
lately. I'm sorry that I cant reply to everyone personally, but I just
don't have the time.
*******************************************************************************
In article <31200025 at urbsdc> aglew at urbsdc.Urbana.Gould.COM writes:
>
>>Note the kernel has a bug in it (what AT&T produce something buggy,
>>never ;-) so if for some reason the make blows up (usally you see
This isn't a kernal bug, it's a bug in make. sometimes make isn't
perfect at closing all of its files correctly, sometime and runs out of
file descriptors.. usually this means that a dup() fails somewhere and
output doesn't get redirected from stdio, so you see whatever the contents
of some buffer the make dies. I've seen this behaviour on other system 5
machines as well.
*******************************************************************************
Regarding the _mulsi(), etc library calls:
I think that the solution to this is to create a header file with
the integer math routines coded in assembly, and declared 'inline'. This will
cause the math to be directly inserted into the code, with register argument
passing, where possible. I started working on this and put it off, I've
collected some fast integer math stuff in 68K assembly, and will be happy
to forward what I have to anyone interested.
*******************************************************************************
Thank you to all the poeple who have taken an interest in gcc, and
to those who helped me with my proble with /bin/as.
*******************************************************************************
About the diffs that were posted:
This is ment as constructive critisizm, and I hope that it is taken
as such. The diffs that were posted contain a *potential* bug in the handling
of switch tables. I know, because I helped write the code that was 'fixed'. The
problem is with the assembly fragment
LI129:
mov.w 10(%pc,%do.w),%d1
jmp 6(%pc,%d1.w)
swbeg &5
L129:
short rel-rel
short rel-rel
short rel-rel
short rel-rel
L130:
The constant 10 is the correct offset under most circumstances. It is possible
(although I have never seen it happen) for the reload pass to insert code
between the mov.w and jmp instructions, which would trash the offset. The
solution to the problem is to use a rel-rel value between the Lxx and LIxx
labels, as so:
LI129:
mov.w LD129(%pc,%do.w),%d1
jmp 6(%pc,%d1.w)
swbeg &5
L129:
short 0 # this is for the offset calculation
short rel-rel
short rel-rel
short rel-rel
short rel-rel
set LD129, L129-LI129
L130:
The changes to the compiler are simple enough, and I have included diffs
to tm-3b1.h and final.c to accomplish this. The code to generate this *will*
be included in the 1.23 distribution.
Note that I have never gotten reload to put anything between the
mov & jmp instructions, and that gcc will bootstrap itself with the constant
10. I have been assured however, that it is indeed possible, and I have no
doubt that bebugging that would be horrible if it did occur.
As far as appliing the patches, you can do it now, you could get a
running gcc and then do it, you could wait till 1.23 comes out, or you
could never do it. (mine was the second choice)
*******************************************************************************
About the binary gcc-cpp that was posted.
This might cause obstack.h to barf because of _STDC_ being defined.
(I just don't remember) If so, you can't #undef _STDT_ because its builtin,
so you have to fix the #ifdefs. There's only a couple of them.
The errors will be syntax errors from the function prototypes.
*******************************************************************************
I found this in my mailbox, and I post it just in case anyone else had the
same sentiment. (.signature deleted to protect the assanine)
> I am not inclined to think of my machine as a toy in the class
> of the ibm-pc's, and I am not going to use .binaries from
> anyone. Please consider that there are numerous reasons that
> .binary files aren't appreciated on the net (there is some
> preliminary discussions going on now, soon to be wide open).
>
> If the source code isn't available, the program isn't trust-
> worthy enough for all to use. Further, your setup with respect
> to shlib, etc. is probably not used by all (ie. my Vers.2
> utilities) and assumes a level of standardization which doesn't
> exist. The only form which can be widely used is source code.
>
You may have been following my comments with interest, but you
certainly wern't paying attention. It has been stated several times
that the stock preprocessor on the 3b1 has a finite limit on the size of
the symbol table, and that this limit is too small to compile gcc and its
related software. the compiler dies with a "too many #defines" error.
This has posed a significant problem for first time builders of gcc.
One solution is to create a restricted gcc-cpp, replace /lib/cpp with it,
and then compile gcc with this. This loses because of a bug in /lib/ccom
that propagates with gcc-cpp, ie: if the lines
# line 6 "/usr/include/arh.h"
# line 2 "main.c"
appear in the cpp output, the compiler will trash the debugging line number
information in the symbol table. (the two lines must be separated by a blank
line)
My solution was to use the cpp from gcc-1.12 (about a year old), which
does not give /lib/cpp grief, and I have been upgrading from that. The version
that I published is from 1.18, with the necessary modifications (which have
also been posed to the net) to make it compatable with /lib/ccom. I attempted
to get the modifications permenantly installed in gcc distrtibution, but
Richard Stallman did not feel that the changes were justified, as the target
population is so small.
I am not particlularly interested in distributing the sources to gcc,
although I will if someone has no other way of obtaining the code. I published
the binary because I have found through the experiance of others that this
is without question the simplist solution to the bootstrapping.
If it will make you feel better, gcc is distributed with a VMS binary
to enable bootstrapping on that machine. If you are not inclined to think
of your machine as a toy in the class of a VAX, that is your problem.
******************************************************************************
*** ../gcc-1.22/tm-3b1.h Fri Jun 3 19:53:31 1988
--- tm-3b1.h Thu Jun 16 11:04:01 1988
***************
*** 24,29
and this notice must be preserved on all copies. */
#define SGS_3B1
#include "tm-hp9k320.h"
--- 24,30 -----
and this notice must be preserved on all copies. */
#define SGS_3B1
+ #define USG
#include "tm-hp9k320.h"
***************
*** 253,259
break; \
} \
else if (reg1 != 0 && GET_CODE (addr) == LABEL_REF) \
! { fprintf (FILE, "L%d-LI%d(%%pc,%s.w)", \
CODE_LABEL_NUMBER (XEXP (addr, 0)), \
CODE_LABEL_NUMBER (XEXP (addr, 0)), \
reg_name[REGNO (reg1)]); \
--- 254,260 -----
break; \
} \
else if (reg1 != 0 && GET_CODE (addr) == LABEL_REF) \
! { fprintf (FILE, "L%%%d(%%pc,%s.w)", \
CODE_LABEL_NUMBER (XEXP (addr, 0)), \
reg_name[REGNO (reg1)]); \
break; } \
***************
*** 255,261
else if (reg1 != 0 && GET_CODE (addr) == LABEL_REF) \
{ fprintf (FILE, "L%d-LI%d(%%pc,%s.w)", \
CODE_LABEL_NUMBER (XEXP (addr, 0)), \
- CODE_LABEL_NUMBER (XEXP (addr, 0)), \
reg_name[REGNO (reg1)]); \
break; } \
default: \
--- 256,261 -----
else if (reg1 != 0 && GET_CODE (addr) == LABEL_REF) \
{ fprintf (FILE, "L%%%d(%%pc,%s.w)", \
CODE_LABEL_NUMBER (XEXP (addr, 0)), \
reg_name[REGNO (reg1)]); \
break; } \
default: \
***************
*** 271,277
fprintf (FILE, "%s%d:\n", PREFIX, NUM)
#define ASM_OUTPUT_CASE_LABEL(FILE,PREFIX,NUM,TABLE) \
! fprintf (FILE, "\tswbeg &%d\n%s%d:\n\tshort 0", \
XVECLEN (PATTERN (TABLE), 1) + 1, PREFIX, NUM)
#define ASM_OUTPUT_OPCODE(FILE, PTR) \
--- 271,277 -----
fprintf (FILE, "%s%d:\n", PREFIX, NUM)
#define ASM_OUTPUT_CASE_LABEL(FILE,PREFIX,NUM,TABLE) \
! fprintf (FILE, "\tswbeg &%d\n%s%d:\n\tshort 0\n", \
XVECLEN (PATTERN (TABLE), 1) + 1, PREFIX, NUM)
#define ASM_OUTPUT_CASE_JMP_OFFSET(FILE,PREFIX,NUM) \
***************
*** 273,278
#define ASM_OUTPUT_CASE_LABEL(FILE,PREFIX,NUM,TABLE) \
fprintf (FILE, "\tswbeg &%d\n%s%d:\n\tshort 0", \
XVECLEN (PATTERN (TABLE), 1) + 1, PREFIX, NUM)
#define ASM_OUTPUT_OPCODE(FILE, PTR) \
{ if ((PTR)[0] == 'j' && (PTR)[1] == 'b') \
--- 273,282 -----
#define ASM_OUTPUT_CASE_LABEL(FILE,PREFIX,NUM,TABLE) \
fprintf (FILE, "\tswbeg &%d\n%s%d:\n\tshort 0\n", \
XVECLEN (PATTERN (TABLE), 1) + 1, PREFIX, NUM)
+
+ #define ASM_OUTPUT_CASE_JMP_OFFSET(FILE,PREFIX,NUM) \
+ fprintf (FILE, "\tset %s%%%d,%s%d-%sI%d\n", \
+ PREFIX, NUM, PREFIX, NUM, PREFIX, NUM);
#define ASM_OUTPUT_OPCODE(FILE, PTR) \
{ if ((PTR)[0] == 'j' && (PTR)[1] == 'b') \
*** ../gcc-1.22/final.c Fri Jun 3 19:52:20 1988
--- final.c Thu Jun 16 11:00:59 1988
***************
*** 465,470
for (idx = 0; idx < vlen; idx++)
ASM_OUTPUT_ADDR_VEC_ELT (file,
CODE_LABEL_NUMBER (XEXP (XVECEXP (body, 0, idx), 0)));
break;
}
if (GET_CODE (body) == ADDR_DIFF_VEC)
--- 465,474 -----
for (idx = 0; idx < vlen; idx++)
ASM_OUTPUT_ADDR_VEC_ELT (file,
CODE_LABEL_NUMBER (XEXP (XVECEXP (body, 0, idx), 0)));
+ #ifdef ASM_OUTPUT_CASE_JMP_OFFSET
+ ASM_OUTPUT_CASE_JMP_OFFSET(file, "L",
+ CODE_LABEL_NUMBER (PREV_INSN (insn)));
+ #endif
break;
}
if (GET_CODE (body) == ADDR_DIFF_VEC)
***************
*** 476,481
ASM_OUTPUT_ADDR_DIFF_ELT (file,
CODE_LABEL_NUMBER (XEXP (XVECEXP (body, 1, idx), 0)),
CODE_LABEL_NUMBER (XEXP (XEXP (body, 0), 0)));
break;
}
--- 480,489 -----
ASM_OUTPUT_ADDR_DIFF_ELT (file,
CODE_LABEL_NUMBER (XEXP (XVECEXP (body, 1, idx), 0)),
CODE_LABEL_NUMBER (XEXP (XEXP (body, 0), 0)));
+ #ifdef ASM_OUTPUT_CASE_JMP_OFFSET
+ ASM_OUTPUT_CASE_JMP_OFFSET(file, "L",
+ CODE_LABEL_NUMBER (PREV_INSN (insn)));
+ #endif
break;
}
******************************************************************************--
:alex.
nerwin!alex at umbc3.umd.edu
alex at umbc3.umd.edu
More information about the Unix-pc.general
mailing list