From baford@schirf.cs.utah.edu  Mon Jan 23 11:14:00 1995
From: baford@schirf.cs.utah.edu (Bryan Ford)
Date: Mon, 23 Jan 1995 11:14:00 -0000
Subject: 16-bit i386 code support
Message-ID: <199501231915.MAA06861@schirf.cs.utah.edu>

Hi - what's the current gas status w.r.t. my 16-bit i386 support patches?
I finally sent off the copyright release (sorry it took so long);
the FSF should have received it by now.

Also, I have a few "final" bug fixes to send you - in fact, one of the
bugs affected 32-bit code as well as 16-bit (segment register prefixes
didn't work with the mov ax<->disp32 instruction).  As of today
I have a complete DOS extender working here, with raw, XMS, VCPI, and
DPMI support, built completely with the GNU tools and mostly written in C -
a fairly exhaustive test of the 16-bit support I think. :-)

Anyway, would you like another incremental patch based on the last
set of patches I sent you, or just an all-in-one patch based on
vanilla binutils-2.5.2?

Thanks!

				Bryan
---
Bryan Ford	baford@cs.utah.edu	University of Utah, CSS
`finger baford@schirf.cs.utah.edu' for PGP key and other info.



From raeburn@cygnus.com  Mon Jan 23 12:04:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Mon, 23 Jan 1995 12:04:00 -0000
Subject: 16-bit i386 code support
References: <199501231915.MAA06861@schirf.cs.utah.edu>
Message-ID: <9501232004.AA24116@cujo.cygnus.com>

   Date: Mon, 23 Jan 95 12:15:09 MST
   From: Bryan Ford <baford@schirf.cs.utah.edu>

   Hi - what's the current gas status w.r.t. my 16-bit i386 support patches?
   I finally sent off the copyright release (sorry it took so long);
   the FSF should have received it by now.

I don't see it listed, as of 5:42 yesterday morning, the last time my
nightly batch job fetched a copy of the file from the FSF.  I'll send
off some mail and see what's up.

   Also, I have a few "final" bug fixes to send you - in fact, one of the
   bugs affected 32-bit code as well as 16-bit (segment register prefixes
   didn't work with the mov ax<->disp32 instruction).  As of today
   I have a complete DOS extender working here, with raw, XMS, VCPI, and
   DPMI support, built completely with the GNU tools and mostly written in C -
   a fairly exhaustive test of the 16-bit support I think. :-)

Wow!

   Anyway, would you like another incremental patch based on the last
   set of patches I sent you, or just an all-in-one patch based on
   vanilla binutils-2.5.2?

Ideal would be patches based on the latest snapshots on ftp.cygnus.com
in ~ftp/private/gas.  But one big set of patches to 2.5.2 would do.

Ken



From baford@schirf.cs.utah.edu  Mon Jan 23 18:01:00 1995
From: baford@schirf.cs.utah.edu (Bryan Ford)
Date: Mon, 23 Jan 1995 18:01:00 -0000
Subject: 16-bit i386 code support 
References: <9501232004.AA24116@cujo.cygnus.com>
Message-ID: <199501240201.TAA07558@schirf.cs.utah.edu>

OK, here's the complete set of 16-bit code support patches,
relative to binutils-2.5.2.  If they prove difficult to merge
for some reason, tell me and I'll download the latest
snapshot and put together a patch against that.

Thanks!
			Bryan


begin 644 16bit-code-patch.gz
M'XL("!Y=)"\``W!C:`#,.UE[&SF.S_*O8+NW'<DJ*2I=OMKI5FPY[1E?GV5W
MDLUDZBM545*-Z]#685N3>'_[`B!9AU12W+LOFT[',@F```CB("';F4Q8(PFO
MV-CQD]AQHT:[V6NVWXXG-O[?</QV<Y9.%H>W&HW&1KS*6>BP:RMF;9WI!X?M
MO<->"SX<=+?J]?H:HI51XK.KX)&U]UCKX+!W<-CI"IS??V<-?5_O:7U6IY][
M[/??MQAC@&OP,`Q"PP\,FX^3J1%Q*W8"7RM.CTW;>#3=A"^-3QR7&W&8^)89
M<UO;JJ].!H$Q=J9+>(X/U!SUFQ78?(N]Y.;CQ9P?;3'!^<%^%SBNP\^>MI_C
M/#;#*8^-F#_,^+,Q<<W'(`FUI=DHY-;:N<#+IAJ%J2`Z>%!S+T=*KI));6G.
MB^P@RF$R6//M+CL+PB<SM)G-+=<,351QD['=MUL,1;7YA$6@1MAP).4Z_@.H
M:!(PH_#KT9;]`ZMK6BO&T;0V6%O32BU-!V/9.]3[\'>]I0'\BI61B4HK:W<Z
M:&3X0]A8\P=&UEQG9<V-9E8RF]I9\T>&UBRQM*9@O]\B]ONZ9+]2J6R/%MXX
M<)G/N1TQXI])_MG3S+%FS`YXQ/P@9OS9B>)M3:"]-VU&PJB!,V"3I4+`:#T;
M#0)0]72;#+3\S_;/OYX+61@QSE"6=]MK$<CT-IJ+%?@39_K6Z>SW&V2U32\N
M;G@9Q#IC*H.M?.0V.^46Z^AH6ZT6_`5;Z1^LVE8I^LB,A:GUP0\>]CJ'O7YF
M:BVM!3Y!Z^$^U7]F=W3\#AD[]V/N,J##0-6^XT_9Z?5HJ[Y5/QV>#>XO[HP_
MAR=WU[?'N)0XK(_<VJJ/AA<PCI,CFC*#)"[,#&Y/_CB_@T_WM\/1,1H0@AEF
M:,U>H^<F?"P3&<<WZQ0A*G<)9R,^9WJ'Z>W##FAR;\TIS2$5]=?N'G8ZF?YZ
M^VCJ\*\*!LZ73K?W%?2_V_!,:[9;JZ"0ONGQ8[$M,-A!-^7,C<2W>1A90<B/
M%V#\1T=+!()HHGL/_T<2!P_+^#B&D/4BM[B+*TOAX#)5/_!Y8X4K*X#=DY`'
M_190?'Q^"L*'J%L`Q:DQ6,5&_@OXO6;K+Q%XA1DE(6\Z?MF.BYG-IB1@Z%B2
MRS]`8X)CV6YO-":)MF1._<-.+Y=?[/4IO8`?RJ!`':#><63C.:I5*O'X>/L_
MXK$:;08,#UFG#1^BV!PWHH47-8-MJ4J!;2]\Y[D$G\9?10%W=XD`#C5P#O#P
M,P98B597:*EK6%I8.*>E-8!`4L8EC;^*2W?A/QO*YRQ3@3G`Q1\--)?7$RR3
M74@N:6;2%\@O4]UHF)E6EI*/W,0ZL\R!_(5@D<>ZA#",6&"4.@2(WF&WLQ(C
MVCV=H@3D8>_/3MG8M!X:W+?9!,+HY:@!\0%"-[<2D-KE49.,X"28+T)G.L-3
M<M#2\%^=_FW3OQWZM\O.0@Z..9C$D-UQR/+@4%-RIT$<L@2ECZ$3QQS.[(*]
M#Q>FC[F@S8()BV><W?O.(W@!)U[@R'ULSIH8JX@!']S$.(%<`5$1^(1#;`N)
M[73)D>5PW^(,SB:`$.8J35:=FXVI/6Y`\A+];D7-!!?B=E)3J]W-G(AA(L7@
MY]P,8T0%96FT\'O'-\,%HUSEE$<6N*\8F'"=<0CC!1KS,)B&IH=D)JB;2#)Z
MQ!9!PBP0/^2V$TG1F!,ST[??`C$O`"M;$"$8).=(:X/$7J34]>'JGGW@/@]-
ME]TD8]>QV(5C<3\"!<#:.!+-2&%$"%'6[=`1XP[,AXQT!5;45HM(BAH+0J)2
M!=T"\R$+YHA8`XX7S#7C#'>=!C)!;09>&XG/@CG(-`.2(.63X[ILS%D2\4GB
M4BG!`)I]/+_[X_K^C@VN/K./@]O;P=7=YR.`CF<8/O@C%[0<;^XZ0!HD"TV?
MMIM(7`XA5P&<P?OSB_.[SR`'.SN_NQJ.1NSL^I8-V,W@]N[\Y/YB<,MN[F]O
MKD=#2)I'G*<FM$'/$]HK4*7-8Q-.I)+],VQO!/RY-IN9CQRVV>)@AS8SP<O,
M%S_>0:)BN@%D;"@I0&?*/&+.!%-LC3W!:<*$>75O"7_Y!&JLO]=CEV84L<$C
M;.F)Z8U#QY["Q\L!:[7USH'&[D<#48S5\;^?'=]R$YNS;2QX9MOYD6@1V7R^
M-`C'8!42!M%)T^A6?:G($\$%^#0-,8*\?T/T"6N)&$1U*T&`2<=4IK#=&3=M
M&:,2/W*F/ME5S$014Y?1"P9L2'2,B`H7(\R0<,H"#<7R=U.`L%WQ,Y+#ULP,
M80Q,UY]&.51)T+&?\X,$9D3.O_GJJ`#]&9RM0Z;Y`JH@H5*.I<A2,>"&#122
MP\D#?512*<&RP"=YYM2QCE;'QXN81U#K&:X)NIJ;4UX"Y.-X=%2!*.`GWAA.
M+YAD3V\W$)MMT^PV$QN(90/9GV"&;&.%7LC=P(I*5A)(P$=H+J^G]\5R.`>&
M/9]%Z!@VK!+RB(=PC$J6<0.HER,X*]:L9#:*C&!2QETT+QFT9MQZB!*O9,HI
MA5]'G92R=D[(TB[C*O`X:-R?ZILF-V)V8/(E9V[P"<Z<XW,V_#0T+@<?SD\J
MK>>>V;6+,Q?7@U/CC_,/?\!L"_Z4S%Y<?X3)"?PI3MX,/@R-T?E_#BM@2,)]
M0.X4@U.#0[!5%^<<CT8PD78=03@!;Z%1QE$3!P:O(]@N#A^I@2!P.<1*!#JB
MH\!`>W$2^JR%4N86DJ!J,?*/1C#^%[=BR/\@8?!CN6;9:D194J)C/[/#+P7)
MOA)/=,<RC\&&DY@^HU#LF`G9JH!52V_)'CV3S2!UH@_'Q#"Z&GEGLAN12#B&
M]V(.Y&$4YH,8(@)1E9%"Q5'`@3CZ@'D"GA6/0_192'_-*!Q5@20LA"(UWLEU
MHB.\I6$_'8/LZ=(U=G5_<2%FCO'?QCN?/\=2,:"+.7BM>%+=5AB_1(<,I6@]
M__(LF,-/__"W-8D-A9W\"&#RDQ&:3Z2?FMI.C%Y55`W=.@K:>$<X3:T!!FML
MAXV&)\;@XN+Z1.V58*N2*18`I5Z7Z>%HCAIA52I(H;X"B]P98P[*XP:=6-(A
M\EL1S*IEWJ4[*0BR_,Y*(,1Z^=](BD=K1=#4TI`Z9ND%(\M)52+6J@K6@KY*
M`[C\NX+)*RTL'P,!G-/$2VKBE^8#I,%00Q>LVHG\-[&Z^$NM&1=.%?Q.:!)U
M+WQ/9J=,'620)Q8WF=7R"]',!J7_F)ANI")UQB1X"O`"Z"H$(TAL9LRA'M7[
M4J.I$]78#GJ)UM?LR)>`I@Z$O86H)W'V-^,H7RNA]?9Z\-9SATNP=G<3&#AT
M70'B\BCMIT^??OOMM_6B`O'69"RQ.JU78^VU^Z;":J]B25U3MH*N#+,5AGD'
MJ[;`B*`$<.G7VOHU"G:WPZI%33>87E.RDD[DBEG^05G.>O+5`OTZ6R4/NUD8
MI**E(D\PK=S-KSSBL2A5?"=VT,''4'RS>>!0)2O3>#QFTNF/(UE_8S&5GI8W
M$;/"N$5WWLQ+(IEFF**`!"HF#"CJZ6$JD4^=+65@_917Y;<BSA^4#ZDJ7U1C
M+0T\UO#OQFAX5\.@TE*GZOMW6D>4)>BB-`;FEO-8&L4E0LJ-RJ.\="9S81[R
M8;XYTD<Y;U8,])IZH-`8:8D^!9,)8&@B_U^;>*`CD\Z7BF0Y?'-WFY)28UE*
M0)2/,I+"N5+)HJJ-;YF6:8@=@PZ+2I`24T(B5F^\PS7F002'HVB)/W+]5*>_
M;F>K*XO5I42UU^UYIF)=:C>WY7EMOVZS\WFKV&CO0:1S=.MG=-KIP`H@1!J#
M>_-X(6N_#&-Y9AD5Y1&I.VZ;X0;!0S)/T5=F<DQ6!`'+#2)N0(X&G\!(`=D0
M6P2EOF.M3I<Q@!=&AF5"+6+GGC\5B3*(92H^?THM8@:<%BDLSRYC3\M.5(%"
M&429)`BG7)2]2O,?RCWEZ:Z'7[-9YK."+-`JS)2ATGORS(QF!EUX&A;X3C#D
M@J#E,&NIF;8M#2LJH9.;+=UVQS==@BSB9N/+6.CZ\.'-P`>E(E)A:O4LT08N
M/!#*2.9S*-+'>&$D2/B!9'(-U'I:Z_&7<:C`4*=S"2L_MV8MNGY)3\;*@FIZ
M&1L^`C0WH0"/4:%\&7\%H&Q]'/=+EQ8S97OK1`9:-6RC.>8K$J]"E-$@YR4;
M!TH55PJTNO>6Z0>^`TMA=!(YOR0D;G)*`,K4()QAB?5(*J4PR`WEV+E>D>([
M$SN6U?@V#6UK4+M@Z@859BZ?*>LRH12,HHK$D>3IHBD(U<U2*8RZE%B!Q<SR
MQ+BI27`9@40E)R&PA#NY/AVR[U3-G0[N!O+C'X,1S%S=#:_N1A3[OF>5K?Q,
MM9^&I)4/R]-NX;(X"<&"+N.RQU()\8:]43`F7K5!8*%;2YJ$>B.;\\`;HA9=
M[JMI->M!6NHE'H,=G_H>N-J<ID$[;K^KI9\-<>EDJ#'(*W$^#]YIKX*K,02'
MSWEPK(J6P=48@J,4P"3>E_Y_Y`O2V"@M:V1-2B?!3CQO(2U56S=.^L=1NGDT
MH`[W3*7^OT*';I6U'`L44<C0Q>_%'"I/1X4,[P$#AO.H,(H4)'%I,6G>EP5S
MQ7/YPJ7W<7DN!(#D8!EBE17\^?[LU/C;_>6-<3=X?S$T/@ROAK?G)ZPJ&B&T
M$I"3ZYO/K)J7>@W8[5""^0$>ME(HZH3Y,P.4O)?"CCY?OK^^&&WB[78(7F$C
MQ,?;\[OA)H"+\ZN_;YH__7PUN$0-28[M!3@$H0/R9%#>U#"]?Z&T?/-S=_JP
M4WR33H?7/76G`&DO3[O%].YANW786==QE^'DNN[T_F&O?=AN9<_<W2ZUK>$/
MO47-%R#NL(JH6O1DSHTH5MF]X]?P]6]P"0JO4O6GJ4<I`8"@_!F*<\B]8)):
MUV1Y#]F!2SY2RQZ.=FLU;#2K@[<?W14IS8*G.)#O6VQWJY[QM%).+/-$11K=
MWE6RFRZ!A5<`^*3EJOK2YC6J]-+R."^\FX1S5;U@'ENZ4%KTTD5Q4>143IEK
MX%H;S4.XI95>B'1XG7FD`,NMO_MI@^6*>60X2ZTYO4-]+V<>$`[0//I=V9HC
M]I>5YB.%1I2C5\"J'I,?P%+KEX"K;X13^=`/Z/D\EIU%FP")N;$S?16<Z\0Q
ME#H$2AUR!WO4(G>@>N0P`%P%]*H/.4GB1/CJQ"90&260.(MV$BQ(.H5V$M'F
M6]DI:`&L3#U3R1DEMZ9@,PG3(6H\3@?RPFGKK7)J1JJ],K9$VU/..,MFRVRT
M#&[)5+OMPUZGQ%1+4;%OYV^FS]J`T4(GJ%,S64\VDW5%,UE7-GQOL>Q9C1)%
MPPX,;!4P_I5X<WIC/3O_=#ED3]A900VY]'QK!W3SRO+/<@)?[X^=F+P)8>MX
M3?3$WT!^B0$9]Q6?:IV8/(S&6CC?:=,(Y3QXN8FMIN'$M*@?097=4\PCFUOR
M!A/H8=M)6TR3%-)2L$,5F0>6(C\Z9($O>BM`4[:#"3'XWQTBHV82/S^'N&A<
MU',"?\?<,I-(/#+`__CI*:#.@(ATVM&IX;/3AB#1%N;,V"&KGGM>ITU>_$7F
M.)%GNBX6@H[GD9>MUJ02'P/'9EAA9]JCQYTJWJPLC>%+"6J[9$J].RYM!#M>
M`XSW8O+0SB.>P-8C5R/F03XJ?\>C]N4KU%"0!K*?G8F/W1;GH..3Z[,S(7^'
M;*K3;:=?(OBV+1NTB;C&VB^:&/:#8![C&Y\!V2^D0;#_:@I[@+R5*<P0MY%E
MO4]/@RL:TIB>!^NTUX&IA5H:WCFW7K9$)S>=BI8006]UNUI;S[HLF[$'NMN-
M9?M?#+_LX."1K(%<O&L'U6:-.-R;8P.3W%9$0G,65_"0A^/]&MHEQ6ZLS:(Y
MMYR)`Z9+C])SU['@(`1SVK8HF4R<9RU]R$,KA-D&O=AZZ>L7-M^RF0DD7&Q)
M68#%\HRRG5[;BQO;N/%.D#>H,<P!"798]11J(;W_'7^@T:HE\>40D9RFX$6\
MTGV3;W5FA-\L8-5M</^AZ?,@B8JLLRFDK_ZV?/Q3M[+BMQ=)NI0?P8Y83:T-
MRO]X?7MJ7-]@;6R,[L_`,R$M[F*/4Q'RM!14"$567]B:D+_!+QHL,?^$WRI8
MH`MR_$?,SU#/8\AE;'PZ#_D4PA4/TR\*!',.2K#!=>#F*W7_E#*ULP,,`I:A
M`&O"^'1]C[Z%H\,!VE/^`[2"*QF2H^\@^Y&*DT]@X"Y>&HQY_(1;_81]CSO,
MII]$G1[JV:-C4N.9RKODPN*]?1YRX(J8;13V&%\05K57D]OU(S#VSV7O4R.!
MOFV)QRRQDE@<K!Z(7`X^&3>W0T`>CFI;ZLGKFU0.E-!X,O7>GJ;WTY,IOO@C
M/+QH:E-*%=M)L4$TTSFV[6+4@O0B4.]B0JO%C7*:V;ZPU/K5YL*"IWQB)F[,
M9"1*#4`$Q/RAIN[#1!JEZ.NCW@IF6A:/(DI=6C!F`O.)_^`'3]CH6&%9S`E\
M=T&(Y!6=?V/8Q`[%Q/<YDL"F4<5'\,C#T+%50E2O"(<.TP9,`^"N+3C'&"K;
M1@`*)+H+H6!R)JL"`._@35*N;1NRL`AY\#!F"U9-T5\2TDL_>*,%?9$'W9B$
M;Q3,3+"&<0N)&T`:;Z]#3X0GP9,P\'/,%T!XO`#$YT=L!97.$R?HE5)XWFPK
M89M#=6/OQ,*(B((A\0V!/PM<,)&Q>-N$,,&JF-V!$)B]D$'%F!L0NAM@+RE:
M6(TL1=BC2%WU-MBEWE6G55D0F$3TI?6U\0Z/N9]X:-Z]S*97#W7KN;5_1/,O
MTI$1I>H2Y`[[[]./-3HLUW\:<%Y.ST<WX*<+WA@W5)J/*;P_)#,0&QJ@X]#+
M[Z]$0(XPJY/[!5LN-YP.E*FR,LC*(:99G(R-]LOT%T_F0LO("%L`[Q_R_TJ<
M4$2S$C-`X1Q?)8`>G4%A&#*\K1B&KD)'T89W[$A%$9:IK3247*+T11]$FDI-
M!_1E!1"V.3835P$S<0/<*JQI?&Q"5KL@OI2&]B=LH=/N:;H.QM#I[^,'^;TV
MB.*-=Y\`25VJ'[.J^#3"1JD6[G=%12(&SE?Q-!)>':W:"D*TY_2,HVU2"B$V
M2'JJIM"=PD];ONPE3[4&6Z'"GWL,:G&@W`TG9Y.F(XJ.3"G$JVQ:?^7L'P!K
MF73?2!V%?EIT2L`E?SY"N3=Z*OJ&)\#(D^7AX0(!\!`,1R>#FZ%Q=VW<?;PV
MWG^^&QJ#T]/;X6AT?O6!&*BD`:33U35]'S=I'W,\N4?(7LH+;A"M0#;WZZ^L
M4V/?66[-HQ2G:(78"XSW^ZHX,>1T]"6E_57AOI#`63*8IF>I=AWQ7<?<!FJ4
M\9D^H5+\)CN49XD\&%F,*)T:J;*0NY^.\\S6)(EOBM0/XW"CDFTC?JZDR=XO
M-DO1*+^CX_]+M!*0:#:B5BP/._L5UK8F*%;R*VJ,^,8VPRF]*M2$B514SI@Q
M])()(07XDDE2KT.QDJ<E)A3^2^'PR1%I*?OT%5N]JW>U;DM:RO^T=ZS-;=O(
MS]&O8#V9JV0JMMZ6Y.82UW%2]VH[8[N7]JXW.HJB+,6DJ(A4Y-3Q?[]]`"#`
MEYQD^NTRK261NWCL+A:+Q6(AU$I&%P!YSX']0MJEK$#-.<"':@*@.`1]OA`R
M!Z6U:TJ=ENC!!SEUOSFZLMSU"B<NL!1P78Y1;]%ZN<3(7:E@<^?O"(^TP$)4
MZ.\H+%VA$W/7A+S-(/!A4HA0L#>D/I(IP,JS!(``V8Z"C9RQ'O4Y;IO4VDIF
MU=QD;1%<HXV/$-VD8$-^U1H'_^GK','W<GE%]26*$O9TBM^@-1PUP#:PUI/*
M&;BO5(EIF3U.Q3`*ZYD2!2/L4[;-%FA367Q^<4*\)N]0WM0SCT0-\')AJ$]Y
M1.=/;Q7R(2L\E8+Q:UN[(=I')0BIX[,^$UVZQ'R$,I6O$_]RT?HRG<C%TI]M
MBO$;)"U',[+Y:2FMB']((W::K7I[@"KQX*#>D0?WEV#ALJ+33-1#?M/$-PM=
MX3VC<RC)IO-'MBU@+8<:AGQMUC-KB;X^FL,02QETTWE,IT_$7BFM;ZN+6DW`
MB;EIB2&>*]`:M."K=GCF0,M=1%L^MSKT2+2<5JVIP?9,M3[=+W@33$8<Z#F*
M0]H-CZSJWY;_;OVG;E7)T75=LQ9UJT45)QUG-[2ENI2T6E@"\?=L*(^CT,<S
M>[R`U^WMO<0Z1K0\),39+\+4)`5PP<KCE:70[TQ]M`YUEZPP"Y7;$Z8S*<81
MK:M],!%CMA=[G7^(U8`NE$*A4%5B$9%4)1[D5C7S/N$T-'5P72W',BT:WP=+
M&1*>=FZ^L%K6$#DL&T"C/PT%6N"[0G&RGPA%8+JU-#*1T(93"PSG&X\=6BF/
MEM#6B<V@+^!`F]"NZ=MCW)4]NC[]YXDP'>Y)%*3\6\J8S_JDA8V'[U,2WV6)
MIW&O2WU7-3.%`(L61=&D+P:N#J)6+&(`57$,P$KFSANHB@O&2#,U1CI)=8_$
MT-II*0N.AA/33Z/9XRG6*Z!8KXABK>T4:Y503*U3A+.,5S`:5([J@>(:=\W&
M-@JGM=!V"J<Q\BBL)@-MC2W6T,ETF6NJI>?(UY=';T9';]^>G+\:-4?'/QU=
M6M6L!N9&FQ)HS&K)TITUH#@S>4@Q[L@H6.I',!B7I&1H4VA/]<,\*J*[!^,9
MZ-*>Q<3QO6DLCQ,+XYJ*3N8S<5H6S66P/>@X;DRG^L'H=F@G`!8%B;>H<T#Q
M`\UNIUUO=93WDJ66UL.LTO(]%S^#"/\(R\L:J+@FJS@K64[3>=X%S>BH]]GO
M]!N%A#+3C1-]',/U(7']01??NW?[[SWWSG#]!70TGUUY'"&58[S3V;`/5+<P
M(JP/U@_J%TAN8G;`*]O.FEJ['Y0#V12$;Q4BB9*5I2?CE>?<IFTE-K')8&1N
M@+7`1F-:O,U.?&&3\D3[@5P<NJ$C^45NA?0L4I->+)*M;H/3CG4'/;GOJ`8M
M_BOWBJ%LT2[K%<_LNL\[;_[\"_J.0SIG7D(U"CJ,]XZ%$08/A05R:'7$(0*>
M+C-S%J'C0"DP4[]D-W]6NM6>&Y"4!Y>DA6EA*HU&4Z5;VK:;S^%)M)L/J,TA
M_,?IZL1N?JM+.T<MF7A.QM3&KCP42^'X5:?VY,G]X0.%O8;D@9_P#J7"P!7'
MQ=N3RZ/S5U=6FV,XG;MD5P4^B8TTI>I(<IEB=1226@DADIC+4&WDHG6WH1E-
M/#T[.WEU>D03J6AL2Z#/@\";S"D*0&^L@7YV<G9Q^;N&*^L6C@UH08)<]5V'
M]W$B,.V97IS+C%.QP4??H+K4US!M=_"TL_'B%5F;C;N^\>:2=R<NO9M+]F[B
MC&^<E.:=4'C>PN<<N<P)TU`W&VYU85D':7KSIJYH57D1FF=>"`A-N=6L`CF^
M.#NY&IV>8^PQ'1VZJJ%[(59;2EY%Z>%8S"UN&/#Y/-1N=5JYU&FAS,L7',81
MGT:.8%K'&LEK'#YFT.+<GC.4X''Y,`4`BAO$("]0()BF[V#8S4O;9.*8@6&=
M_K"AI<?I-6G7$C]4$K`VI=2Z"=LM&(SA^+V(S'U.2;*@;!$R]5RF5I*)K]I)
MXC#T2HMB%NM==G1K)3GDM`_6/OGGG],1#@I,=2*9",M."L2PJ-U:!O^0,RO*
MA%N85LML[UA"*1AL;4Z?DI;,70`T^H@/9"<?QUPC.5?ZS5868Y:M+)<[V[B<
M3<[5.5"A6!PYP@8>?/R?T=_$Z$GH[CO17NS=T3$<@Q_FNR)FFU#$[I_7/N6O
MZ@^[_6%K4,#N%"(R'!-?6<#G+LF)EH>SU^Y1.C;Z9);O,J7/:`H9#JWT/WX!
MJI[VF5TO4BCD%,G!L'X")>C3GO^4)@_K-+'0$_37N$.=ATXO$/UM2-DR!#Q9
M<WGP[TRW_S$E\Q1(YR',J'E(]*)BO<3U%UAF:S$[]@XZ32+00:=5Y_1@ULO(
M"9;WTT4$ZZ4'6GO%=.H-M/L$;#H\&.1CXHG3A77#&8SJN$%!ZS")^W(2QM']
M`QBWVFJ%_5$!6#H6;CS#FA:7;+`B$U@2R<#!BJ:J41MG'C]02BDOFJ,[&Z<_
M##$8>[J/G28CRLCT<D&;QHJ@\$0>M,FC(V*XO,V(.+JG+7EC1$0B6/(*([*?
MT7R<]_8E/KSG^+@'&03QL02LW<H!>S?#_&.XI;3`80W,X&Q0(@[EO_]=@B[\
M_GMI8%`_1&MB"CP3'L&*+3>@<($H-Y/(D,,X3C!EYPL^3TX=HG@+V??E"N3)
M19D(B#0<B"7<CAB-R?$[LWE41VYZM.!F'NYE^F]Q_@G.NN5$D1>,?<PLMKA9
M8U(`0X*@9<!JT3@S,N%WD5B-4P%5;*00YKA#'-D[IICNU91)MCR]>0;=28ZP
M,#Y\%9.%[=TY+DH:;7G@V;1LNZ-/BQ@M7=-.<Z**;5I_>WS&?[I>L%R"%L&]
M!MZ8T!?[\VRU%7OEW3@KC)FBY'"TP8<YX,C?X%!\%>8;6OO4?7%\3092<'BV
M2LI6L:F%)`T4/(&=WB"G<4O)LJ[".KV$1F``1EVCVLJ#81DL0'<NYB[FCPDG
M:Y>BDD1'Q0EOO3MFRS<SC]+0S6G?2[&9B"7HE[BC!=FJIU-J(\5#Z52NJZQR
MS@2#G"IV3C"=#"_3VP2/H(>NS*<`;4CU8*^&TD"1.Q01QA3!4$/*O53G&!V9
MXP_=Y)CI[?A8"J&G!IC6/V.0Y8XPZ.S/J.;$6"+V8PPUCC=4:<@#)PJJ.V)T
M[=0.'T0N1*CH9LX9@(',E,#OV(K@`WJ)1_W9IM^@4@$QY\82Z:)8[/FQEB<!
MTK<#6#R(R.LX#!PQ,S#)?;]B8^5:`%Q">0[PHY!8(A>1)'=,7TQ1MZQ7F(8P
MFF."1]%"4G5"[5&@-FE=GXNJSF.UR8[Q>M8,_H>%B>W$,5I?*D*&]DO#%35'
M).-`]0CM6CBDF>Y(=P9+(,X*P^@QC<7B4\76M]R1V<Q:4B4Z"3%.:X$)/WP,
M\]6W8AS<C($&R>ULW%*`_A[Y45@77D^YY>IP-40_9!5(,MES2(VEMW#\&!HT
M69-0R7F80GS59CEBY0P`(!VR$*<$1)U,B$:I(<&)#=%\8%[AEA5*`HT[4[6I
M!.`X,AC:4#]BFJ!^2;F8`V60\S#VG$3TO6?]!DY;,`@0+%SQE)(,(&PF%`^8
M..M9T=K%$#@%7F>F)%D8Z6#"=.5`BZ>K,.`0"1@X7K"<W0-''Q+)%EV/A`X4
M,7+47PRY6L?+M0K"H]28N91%7G+W@Y!DC3;,N44X\AU2=FACSUW>V)?;:F:L
MB)BB(XN;BF*OVIJ.%!FB$@6-DGMR`[Z(WM(6_(/H2907]2&.9I"D&]H1:2ZB
M33%44<74IEI"<X52@L0UP7N#:XFF8ZZ!,L6LGS2TR2DA50-',*P2D]P6V<]P
M3:19>-+(E18>_RY<R(@DE?OL+ME/.Q%S7^<M9W(!GUS/UM:9LQ)Y?-O=83O/
M39&/FSD5U&@F?L066>PMF9L_<4^-*,B)CN0$X<>4X62X]/2P5*MQYS0JUKVU
M`T@[=:M5IR=U:U2W7KW[?!Y22&8=`%[-HR6>ESYR73P)](`'<5-X_;[$4UB7
M'LR*\.<SK*R*T,9<W14F,GP-NNT=(IX&09VQ!1(=7^G5^Y;=/E"'5W#$3L'N
MCQ-##DN.=D3NS0PIR-Q:1WS'P#W!CF4[&M.Q1RU)>_J,[O2Y*_BUV?L,?Y$H
M#>X7+K]9"=Z&$0SQ0Q4$'7D4ZB].)FW"U"H'/;6B-?Y7-R=IB"QK(\OJ];ZB
M<[(T^PM;)DZFE#703C?P,45BBXI;*;BYT5LYW=YCX"$59C(R&48D5Q3W1*&"
M$[E?..BC*`X&\K#Q_8X;N#M\7NENVJ6*M=$C3S*)EOK.;"J!!],MP)$.[)4!
M`]^7ZTB#=K=!A\L$>%(&;)<6K;$\C5180PD.5K0IJ8DE(:>F34E5622D;9PP
M;;"-#_%$P9;2BF#G"G9<!DN>R=Y!O=G%HYX-_&2]SC$2,B\WGYY!-[_Q?$B)
MAL'RQ:/\H.Y8C[AC18=>;]#?(@/N9J)!EQ*!H3U%Y*U%3SXHV-*";:/19KG%
M'-=:;A9?BE+0_&)Q+.Q%`0JR")9?<9HI\9=Q)?8?3^=-_$4\].,"PN7R)?X*
MQA0UOH3*FZ)&E=13V)$BUA!SWCDK7!%_QQ;ZVM^?PQ^Y<88CME?C69N,45I"
M-.42ZCORUWQ"9R;-]][=$IXBFWL=7@SA<@=3TD>\MMX%*Q@L@ETT_'G)*=:`
M+IUDF4<SMNNZW7JK!99=MU]OL7G#(SU>A;"J@ZJC*>]V&E:=,O^.<6]/"UG#
MB*\^34NP*MRAM'SXA&BD]CAUN\X0$`UG.J7Y5)\S<<;\C(4<B<#&%%<*L$V[
MX!&%;`I+4:9`62DF;5X?729;TB@O#DW$HK%D,0P<11X]WD*8HU@GU-)N?:;3
MXAJY_'2/VQJ]V/#5>E8(K=$G'VE3B,7T,+&TM4$ZGA%%88S=?Q\LE6R,5>>E
M6)A3F@:+]7=,F0"R/(85U)(T*SQF!5=`G/"V<B+#@U3SNJ4L*``NY("%5:R\
M6"H;M[U%Q3(L5>"VTK"B"SJ\KQ=>:C`DP%RZLZUTNZ3EQ>JXL`,:2GY-FY*J
M<K6XP"FJBW%RZBJF67&WBDE7WB_?Z%BVLMR.^4;/LK7E]PR&`EUQ(\>"FYG]
MDR'0UY`H8%\UL=R8Y=5TJXGG8NUV&\S.@5C%O%_XGFSRP72;2KAY)*BXXL(2
MN:#1524B.SE+1^"XJS"B8*<7%')V'5HWG#4YP-B36SK3=./,%^0?%>>7T87O
MW/+1;4S)L(C15Z?R.H@-$+QE(O"`H'4!..&+'LC+Q6S8%V$WE'U/G)7$]("<
M082W+M!)3'DV]%/[&SHI`YW%=;^/^^@K#E/MXY$)<X8^O>)L7!?GH^/?1O\Z
MN;RHAC7K#[0BJB&E`@;;S6O7<C%.BE`005[V0%KJO7OWI^0*EJ?X\B,%\F1X
M@RB>AK,=PS8K22%HDIV#5U*3-@`SXJ.3Y)>+B[=$C^O3LY.K+$%:F)I8_FCJ
M/QJ<Q:'3ZF,4IMWIM.K-MI![8+`:J9G%G1AIFN0#>%N-M=)5-@.'"GC;`GZN
M:[52UX!=!ERL`N>&*LLBY:R3]SG`(`(CF4*^.OC]18WM8Y1Q4.)1(,ML3!US
M4DHK'^@EY0-5AE>/M;YI3]3%'"P)0RB:1RL'"9NN(=EE]9C6:*HZ.U-=&E-9
MH*DZ+23&S%=<F7:V"`<&-:@US%970;]!"8SZ+7FW+-^N*R\OX?1`Y,87Q[3I
M?DY^$CMCS`Y$=RR)X90]RXA]/:#D.]8..O8IEP\^@Q9P(IWLC@$,K[];%&"A
M[06(3":[5O6G<$.[NK@'PI=\O:@9FC$;CDP,+O;=^Y-]/"6`&YA&K)GY/,];
M;T*D+H%L]X:=O!M%4TCZY;\'>-L>K->2*+-!C^]IEB%'N/8X.?L5#>^+\RL@
MO^<O;@>]QEYH>=%ZT<9/>=<J?L=@-/S\"#R%SS_P0$?0[]^.W0@?.ZT!7E3H
M+;P-_9XMVXT&7R2)WV=+NFN1L&9]>$7/\<L,OWGC(%R($J#R#E7H3[@Y?U2>
M056]_BT&@1%$C(&L]`VJ;?%7F<&-$.PO0_"TRR.YC1^=Q=SW'?E.%O1G_S::
M!_@MF"\C?QY+`.XI$P7>X+4A`DC0`+_.)P3_T;GCWG<;C80F\&.L'D?JFZN^
M!03+V<(H8A`_V#Q*^N(.K:?5:.5.YJO:/@;5D941[2N`:,;3D@E%MLF^R#ZZ
M![9-\IHO%&0`DH7(M9[>OSDY'[TZP>#]*SS:0P^NCB]/WUY?/:B4@A5;(VQI
MRPB"FF9_9=.T8C+ML_/:A[`53?**VJ<`OHER22E;J2=!2]5,^?W0!0`%BN<;
M;H<NPC8#7MN-87N0OOB3+OU$!91<]OR('J>C>/WM-^RF0(R\B+TAID8LT*UE
M]^OVC?MU#VCR.\B]KMGSI[NU)_Y$#]G%A]E+E:-/T<<LJ![>F[D$.@5+4;SY
M5S#G`.==PBRBA8L*!M"@OPM0`*+!X#SP#"8"`8)S`<"L)W,#2NC>TC!>('N1
M;M!94P!3P/X"Z,?+>%$!^HP[H$N76YG[;2E?C,VC>X39;S5YMR]^O7[[Z_7H
M]<7EV='U<Y%<OF*KNU2>\UF.BGU]\MOUZ.KZZ/*:TM0\AT?G%^<(]VJ4\PZS
M0%,]I90NU)]ZWXN`"FA=!/YX8A>6H%.[/VR8>73E;<),;A=&ZP\_G%R\3I&X
MNO/TWGCPL%-3($BTZM-[_'B@@+JKDV,VCM!B%&DQ]\!2>GJ?(OD##;D].N8^
M%/>`$=(3F?UMMTIO:U;JH;C'4R5+''E4R'-K[U"#PD,V&@B=N4E`Z%*SO3'8
MOOEUCT;P;L0'3%,%PXM:\O/XXNSLXERKB"YX._KE],UYM=E++BL;%;QYH&R@
-1/7*_P"OK@ER@X4``(M:
`
end





From roland@gnu.ai.mit.edu  Mon Jan 23 19:52:00 1995
From: roland@gnu.ai.mit.edu (Roland McGrath)
Date: Mon, 23 Jan 1995 19:52:00 -0000
Subject: Can't close {standard input}
Message-ID: <9501240350.AA06645@churchy.gnu.ai.mit.edu>

gas-950120, host=m68k-hp-bsd4.3 target=i386-gnuelf

I am using gcc -pipe, and it seems to be working ok except I get this
message for each file:

{standard input}: Assembler messages:
{standard input}:0: Can't close {standard input}: No such file or directory

Any clue?



From jbrooks@ea.com  Mon Jan 30 17:35:00 1995
From: jbrooks@ea.com (Brooks, John)
Date: Mon, 30 Jan 1995 17:35:00 -0000
Subject: Discussion groups bfd and gas2
Message-ID: <2F2D93EF@pcsmtp.ea.com>

I would like to join to the following lists:

bfd@cygnus.com
gas2@cygnus.com

Please add my name to any lists describing usage/modifications of 
gcc 2.6+, ld, and binutils.

Thank you.


John Brooks (jbrooks@ea.com)
Technical Director
Creative Development Group
Electronic Arts



From raeburn@cygnus.com  Tue Feb  7 14:43:00 1995
From: raeburn@cygnus.com (raeburn@cygnus.com)
Date: Tue, 07 Feb 1995 14:43:00 -0000
Subject: new changes in gprof, bfd, gas
Message-ID: <199502072243.RAA18929@kr-pc.cygnus.com>

Some of these might be of interest to people:

>From David Mosberger-Tang, revised gprof support.  Now alpha-osf
configurations are supported, and line-level profiling is available.
The latter requires bfd_find_nearest_line; currently at least ELF and
SOM are missing this support, and the SOM code aborts when it is
called.  Lots of other changes too; see gprof/NOTES for details.
Texinfo documentation should be forthcoming.

>From Bryan Ford, some 16-bit assembly and msdos .exe executable file
support for the i386.  Bryan says he's managed to build a working
memory extender for DOS using this code.  And he even gave me
documentation changes.  Currently the .exe support uses a.out for
object files.

Both these changes should be in tonight's snapshot.



From law@snake.cs.utah.edu  Tue Feb  7 15:10:00 1995
From: law@snake.cs.utah.edu (Jeffrey A Law)
Date: Tue, 07 Feb 1995 15:10:00 -0000
Subject: new changes in gprof, bfd, gas 
References: <199502072243.RAA18929@kr-pc.cygnus.com>
Message-ID: <6855.792198610@snake.cs.utah.edu>

  In message < 199502072243.RAA18929@kr-pc.cygnus.com > you write:
  > configurations are supported, and line-level profiling is available.
  > The latter requires bfd_find_nearest_line; currently at least ELF and
  > SOM are missing this support, and the SOM code aborts when it is
  > called.
Right.  find_nearest_line may never be supported for SOM; the
idea of duplicating a goodly portion of dbxread/stabsread AND
hpread from GDB is revolting.

I can certainly change the SOM backend not to abort, but it's
not going to give any meaningful results though (I certainly
hope there's an option to give the traditional gprof results
without using find_nearest_line).

Jeff




From law@snake.cs.utah.edu  Tue Feb  7 15:24:00 1995
From: law@snake.cs.utah.edu (Jeffrey A Law)
Date: Tue, 07 Feb 1995 15:24:00 -0000
Subject: new changes in gprof, bfd, gas 
References: <199502072243.RAA18929@kr-pc.cygnus.com>
Message-ID: <7021.792199472@snake.cs.utah.edu>

  In message < 199502072243.RAA18929@kr-pc.cygnus.com > you write:
  > 
  > Some of these might be of interest to people:
  > 
  > >From David Mosberger-Tang, revised gprof support.  Now alpha-osf
  > configurations are supported, and line-level profiling is available.
  > The latter requires bfd_find_nearest_line; currently at least ELF and
  > SOM are missing this support, and the SOM code aborts when it is
  > called.  Lots of other changes too; see gprof/NOTES for details.
I notice some problems with the new code:

core_init looks for sections by name.  That is *very* bad for
formats such as SOM & ELF.

The specific problem I see is it looks for $CODE$; well, in
SOM there may be hundreds of $CODE$ sections in a file, and
even if you get all of them you're still going to miss
other sections with code in them like $MILLICODE$.

[ Of course the old code had the same behavior in that it just
  looked for .text; but we never made use of the info for
  SOM/HPUX.  From my quick reading the new code actually wants
  to use information it gathers about sections & their contents. ]

Can someone run this mess through indent?  GNU has formatting
standards, we might as well try to adhere to them.


Jeff






From raeburn@cygnus.com  Tue Feb  7 16:06:00 1995
From: raeburn@cygnus.com (raeburn@cygnus.com)
Date: Tue, 07 Feb 1995 16:06:00 -0000
Subject: new changes in gprof, bfd, gas
References: <6855.792198610@snake.cs.utah.edu>
Message-ID: <9502072356.AA08833@cujo.cygnus.com>

   Date: Tue, 07 Feb 95 16:10:10 MST
   From: Jeffrey A Law <law@snake.cs.utah.edu>

     In message < 199502072243.RAA18929@kr-pc.cygnus.com > you write:
     > configurations are supported, and line-level profiling is available.
     > The latter requires bfd_find_nearest_line; currently at least ELF and
     > SOM are missing this support, and the SOM code aborts when it is
     > called.
   Right.  find_nearest_line may never be supported for SOM; the
   idea of duplicating a goodly portion of dbxread/stabsread AND
   hpread from GDB is revolting.

Hm.  Well, I think eventually we should have gprof support the
stabs-in-coff and stabs-in-elf configurations; assuming that were
already done, would putting the hooks into som.c to call out to that
code be hard?  For now, how much trouble would it be to support only
the HP native format in find_nearest_line?

Probably the approach to take would be what David has already done for
ecoff -- when line-number info is first requested, process it all once
and build up a cache of the line number or procedure info in memory,
then scan it efficiently later as needed.

The handling of stabs would probably boil down to code to iterate over
the stabs and pass them to some routine that updates the cache
appropriately.  (That's assuming a cache format that's independent of
file format.  Or maybe a separate cache for stabs-derived info.)

   I can certainly change the SOM backend not to abort, but it's
   not going to give any meaningful results though (I certainly
   hope there's an option to give the traditional gprof results
   without using find_nearest_line).

Yes, I believe that's the default.  And I haven't tested it out myself
but I'm pretty sure it'll do something reasonable if find_nearest_line
simply fails.



From law@snake.cs.utah.edu  Tue Feb  7 16:17:00 1995
From: law@snake.cs.utah.edu (Jeffrey A Law)
Date: Tue, 07 Feb 1995 16:17:00 -0000
Subject: new changes in gprof, bfd, gas 
References: <9502072356.AA08833@cujo.cygnus.com>
Message-ID: <7320.792202591@snake.cs.utah.edu>

  In message < 9502072356.AA08833@cujo.cygnus.com > you write:
  > 
  > Hm.  Well, I think eventually we should have gprof support the
  > stabs-in-coff and stabs-in-elf configurations; assuming that were
  > already done, would putting the hooks into som.c to call out to that
  > code be hard?  For now, how much trouble would it be to support only
  > the HP native format in find_nearest_line?
Calling out for the embedded stabs to a common library routine to
handle stabs is easy.  Handling HP C native would still be very
problematical.

The SLT (source line table) doesn't have all the information
we're going to need.  We have to walk down the NTT (name and type)
tables to be able to associate a code address with a file and
line number.

It can be done; it's just a pain.

  > Probably the approach to take would be what David has already done for
  > ecoff -- when line-number info is first requested, process it all once
  > and build up a cache of the line number or procedure info in memory,
  > then scan it efficiently later as needed.
Certainly.  Canonicalize the information, then throw away all
the debug information -- the debug symbols typically are huge
and we only care about a small portion of them.

  > appropriately.  (That's assuming a cache format that's independent of
  > file format.  Or maybe a separate cache for stabs-derived info.)
I'd highly recommend a canonical format.  It certainly makes
handling



From davidm@cs.arizona.edu  Tue Feb  7 16:22:00 1995
From: davidm@cs.arizona.edu (David Mosberger-Tang)
Date: Tue, 07 Feb 1995 16:22:00 -0000
Subject: new changes in gprof, bfd, gas
Message-ID: <9502080017.AA32570@piston.cs.arizona.edu>

>>>>> On Tue, 7 Feb 1995 18:56:43 -0500, raeburn@cygnus.com said:

  Ken> Probably the approach to take would be what David has already
  Ken> done for ecoff -- when line-number info is first requested,
  Ken> process it all once and build up a cache of the line number or
  Ken> procedure info in memory, then scan it efficiently later as
  Ken> needed.

As I have mentioned before, for gprof purposes, it would be much more
efficient to have a function walk_line_syms() that takes a callback
function as an argument.  The callback would be invoked once for each
line symbol and would provide the same information as
find_nearest_line() currently does (i.e., address, filename,
functionname, and line-number).  I believe this is also easier to
implement because the symbols can be processed in an order that suits
the object-file format.

Just my 2 cents though...

  Jeff>    I can certainly change the SOM backend not to abort, but
  Jeff> it's not going to give any meaningful results though (I
  Jeff> certainly hope there's an option to give the traditional gprof
  Jeff> results without using find_nearest_line).

  Ken> Yes, I believe that's the default.  And I haven't tested it out
  Ken> myself but I'm pretty sure it'll do something reasonable if
  Ken> find_nearest_line simply fails.

It works fine as long as find_nearest_line() returns false when it
doesn't have debugging info available (either because it's not
implemented or because the image doesn't have debugging info).

	--david



From rms@gnu.ai.mit.edu  Tue Feb  7 16:56:00 1995
From: rms@gnu.ai.mit.edu (Richard Stallman)
Date: Tue, 07 Feb 1995 16:56:00 -0000
Subject: new changes in gprof, bfd, gas
References: <7021.792199472@snake.cs.utah.edu>
Message-ID: <199502080056.TAA13633@pogo.gnu.ai.mit.edu>

I am not sure what SOM is, but supporting it is not high priority for
the GNU project.  I have no objection to it if someone feels like
working on it, as long as people understand this work is not
particularly helpful for GNU.




From law@snake.cs.utah.edu  Tue Feb  7 16:59:00 1995
From: law@snake.cs.utah.edu (Jeffrey A Law)
Date: Tue, 07 Feb 1995 16:59:00 -0000
Subject: new changes in gprof, bfd, gas 
References: <199502080056.TAA13633@pogo.gnu.ai.mit.edu>
Message-ID: <7584.792205149@snake.cs.utah.edu>

  In message < 199502080056.TAA13633@pogo.gnu.ai.mit.edu > you write:
  > I am not sure what SOM is, but supporting it is not high priority for
  > the GNU project.  I have no objection to it if someone feels like
  > working on it, as long as people understand this work is not
  > particularly helpful for GNU.
ELF has many of the same problems (sans native HP C debug support).

ELF (last I heard) was very important to the GNU project.

Jeff




From rms@gnu.ai.mit.edu  Tue Feb  7 20:34:00 1995
From: rms@gnu.ai.mit.edu (Richard Stallman)
Date: Tue, 07 Feb 1995 20:34:00 -0000
Subject: new changes in gprof, bfd, gas
References: <7584.792205149@snake.cs.utah.edu>
Message-ID: <199502080434.XAA14004@pogo.gnu.ai.mit.edu>

    ELF (last I heard) was very important to the GNU project.

Yes, it is.  Wht the sarcasm?  I was talking about SOM, not ELF.



From law@snake.cs.utah.edu  Tue Feb  7 21:36:00 1995
From: law@snake.cs.utah.edu (Jeffrey A Law)
Date: Tue, 07 Feb 1995 21:36:00 -0000
Subject: new changes in gprof, bfd, gas 
References: <199502080434.XAA14004@pogo.gnu.ai.mit.edu>
Message-ID: <7956.792221754@snake.cs.utah.edu>

  In message < 199502080434.XAA14004@pogo.gnu.ai.mit.edu > you write:
  >     ELF (last I heard) was very important to the GNU project.
  > 
  > Yes, it is.  Wht the sarcasm?  I was talking about SOM, not ELF.
No sarcasm.

The issues exist for ELF too, which you've confirmed is important for
GNU.  Therefore, we need to keep those issues in mind and try to handle
them correctly.

Jeff



From gary@Intrepid.COM  Tue Feb 14 14:31:00 1995
From: gary@Intrepid.COM (Gary Funck)
Date: Tue, 14 Feb 1995 14:31:00 -0000
Subject: gas - MIPS/ELF/DWARF probs
Message-ID: <9502142230.AA02803@presto>

Hello,

Our company is working with the NYU GNAT team; we hope to develop
DWARF-based debugging support for Ada programs compiled by gnat
(GNU Ada Translator) and then debugged by gdb.  Paul Hilfinger
of Berkeley (hilfingr@tully.cs.berkeley.edu) is working on making
gdb Ada-aware.  We've been lurking on the gas2 list for a while now;
this is our first posting to this group.  We hope the following
message is "on topic", and look forward to your comments/help.

                          -----

We are targetting SGI's IRIX 5.x operating system, and have configured
gcc-2.6.2 to generate DWARF, and to use the GNU assembler
(binutils-2.5.2).  Although, IRIX 5.x tools still use the "MIPS
Debug" format (a derivative of the Third Eye dbx-like debugging
format), their debugger knows how to debug either MDEBUG or DWARF.
We eventually plan to target IRIX 6.x, which uses DWARF info.
directly.  Thus, IRIX 5.x seemed a reasonable starting point for
experimentation.

We've run into (what we think are) a few gas bugs/problems. Please
find them dsscribed below.  As you'll see, the problems came up
when we tried to build objc (Objective C) using the boostrapped xgcc.
We built Objective C by mistake, however, we believe that the
same gas problems will come up whether/not we're building objc.

The problems are described below:


When copiling objc/hash.c

We end up with the following code:

.L_D215:
	.4byte	0x4
	.previous
	.align	2
	.globl	hash_delete

The align directive gets an assertion failure in the procedure,
mips_align in config/tc-mips.c:


/* Align the current frag to a given power of two.  The MIPS assembler
   also automatically adjusts any preceding label.  */

static void
mips_align (to, fill, label)
     int to;
     int fill;
     symbolS *label;
{
  mips_emit_delays ();
  frag_align (to, fill);
  record_alignment (now_seg, to);
  /* obj-elf.c doesn't communicate with these routines, yet it
   * overrides ".previous", ".2byte",  etc.  They should clear,
   * but do not know how to clear, insn_label, which is passed
   * in as "label" to this routine.  For now, we remove the
   * ability to align the previous label.
   */
  if (label != NULL)
    {
      assert (S_GET_SEGMENT (label) == now_seg);
      label->sy_frag = frag_now;
      S_SET_VALUE (label, (valueT) frag_now_fix ());
    }
}

The check for (label != NULL) above passes, and the assertion that
follows fails.  The 'label' formal parameter is in fact the current
instruction's label:

/* Symbol labelling the current insn.  */
static symbolS *insn_label;

Normally, this insn_label variable is reset to NULL by assembler
statements which generate code/data.  By "normally", we mean that
tc-mips.c does the right thing.  However, the file config/obj-elf.c
"overrides" tc-mips.c's handling of operations such as ".previous",
".2byte":

  {"comm", obj_elf_common, 0},
  {"ident", obj_elf_ident, 0},
  {"local", obj_elf_local, 0},
  {"previous", obj_elf_previous, 0},
  {"section", obj_elf_section, 0},
  {"size", obj_elf_size, 0},
  {"type", obj_elf_type, 0},
  {"version", obj_elf_version, 0},
  {"weak", obj_elf_weak, 0},

/* These are used for stabs-in-elf configurations.  */
  {"line", obj_elf_line, 0},

  /* These are used for dwarf. */
  {"2byte", cons, 2},
  {"4byte", cons, 4},
  {"8byte", cons, 8},

  /* We need to trap the section changing calls to handle .previous.  */
  {"data", obj_elf_data, 0},
  {"text", obj_elf_text, 0},

One thing that obj-elf.c does _not_ do, however is to reset tc-mips.c's
idea of the current instruction label.  So when the .align opcode
comes along, it is not overridden, and it in turn checks for
the insn_label, which now has a different section, than the section
resulting from popping to the previous section via the ".previous" opcode.

For now, we just removed the check in mips_align(), which forces
alignment on the prior label.  It seems there is also the question
as to whether ".previous" must remember the previous label or not
as well as the question of how obj-elf.c should communicate with
tc-mips.c.

The second problem has to do with the fact that the DWARF code
generation may generate code along the following lines (line
3256 in objc/Object.s):

        .section        .debug
.L_D193:
        .4byte  .L_D193_e-.L_D193
        .2byte  0x14
        .2byte  0x12
        .4byte  .L_D198
        .2byte  0x38
        .asciiz "_i_Object__free"
        .2byte  0x83
        .2byte  .L_t193_e-.L_t193
.L_t193:


That last ".2byte" pseudo-op has a foward reference to L_t193_e, and
this is apparently handled as a "fixup" in gas.  The relocation value
is given as "BFD_RELOC_16" ... even though this value will in fact
be absolute and not relocatable (it is the difference of two reloacatable
items).

The procedure "md_apply_fix" in config/mips/tc-mips.c is supposed to
handle fixups, however, it does not have an entry in its case
statement for items with BFD_RELOC_16, so the default case alternative
is executed, and this triggers an internal error.

Earlier in the handling of this ".2byte" directive, we ran
into the following assertion, at the very beginning of
mips_apply_fix() which fails:

  assert (fixP->fx_size == 4);

To work around these problems, we made following patches to tc-mips.c:

*** targ-cpu.c.orig	Sun Feb 12 20:51:25 1995
--- targ-cpu.c	Sun Feb 12 21:29:50 1995
*************** md_apply_fix (fixP, valueP)
*** 5312 ****
--- 5313,5319 ----
+ #if 0
+   /*
+    * DWARF support may define something like:
+    *   .2byte L1-L2
+    * which is handled as a fix up.  The check below incorrectly bounces
+    * that construct.
+    */
*************** md_apply_fix (fixP, valueP)
*** 5313 ****
--- 5321 ----
+ #endif
*************** md_apply_fix (fixP, valueP)
*** 5336 ****
--- 5345,5353 ----
+ #if 1
+     case BFD_RELOC_16:
+       /* nothing to do - but better not be relocatable.
+        * Sixteen bit fixups are generated by the DWARF support.
+        */
+       assert(!fixP->fx_pcrel);
+       break;
+ #endif
+ 
*************** mips_align (to, fill, label)
*** 5585 ****
--- 5603,5609 ----
+ #if 0
+   /* obj-elf.c doesn't communicate with these routines, yet it
+    * overrides ".previous", ".2byte",  etc.  They should clear,
+    * but do not know how to clear, insn_label, which is passed
+    * in as "label" to this routine.  For now, we remove the
+    * ability to align the previous label.
+    */
*************** mips_align (to, fill, label)
*** 5591 ****
--- 5616 ----
+ #endif

We view the patches above are really just temporary workarounds.

Has anyone seen and/or fixed these problems?

--
|  Gary Funck  		     gary@intrepid.com
|  Intrepid Technology Inc., Mountain View CA (415) 964-8135
--





From ian@cygnus.com  Tue Feb 14 14:44:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 14 Feb 1995 14:44:00 -0000
Subject: gas - MIPS/ELF/DWARF probs
References: <9502142230.AA02803@presto>
Message-ID: <199502142244.RAA05158@sanguine.cygnus.com>

   Date: Tue, 14 Feb 95 14:30:59 -0800
   From: gary@Intrepid.COM (Gary Funck)

   However, the file config/obj-elf.c
   "overrides" tc-mips.c's handling of operations such as ".previous",
   ".2byte":

This is the wrong way around.  Actually, the pseudo-ops defined in
tc-mips.c are used, provided they are defined.  You should be able to
fix this problem by defining the relevant pseudo-ops in tc-mips.c, if
OBJ_ELF is defined, to do the tc-mips local processing and then call
the obj-elf.c routine.

   For now, we just removed the check in mips_align(), which forces
   alignment on the prior label.  

As you know, this is not really an acceptable solution.  Existing MIPS
assembler code relies on this working.

   To work around these problems, we made following patches to tc-mips.c:

These patches are not really usable as is, because they don't include
any context.  I don't know how you generated them, but please always
generate patches using diff -c.

Ian



From gary@Intrepid.COM  Tue Feb 14 15:22:00 1995
From: gary@Intrepid.COM (Gary Funck)
Date: Tue, 14 Feb 1995 15:22:00 -0000
Subject: gas - MIPS/ELF/DWARF probs
Message-ID: <9502142321.AA02979@presto>

| From: Ian Lance Taylor <ian@cygnus.com>
| Date: Tue, 14 Feb 1995 17:44:00 -0500
| Cc: gas2@cygnus.com
| In-Reply-To: < 9502142230.AA02803@presto > (gary@Intrepid.COM)
| Subject: Re: gas - MIPS/ELF/DWARF probs
| 
|    Date: Tue, 14 Feb 95 14:30:59 -0800
|    From: gary@Intrepid.COM (Gary Funck)
| 
|    However, the file config/obj-elf.c
|    "overrides" tc-mips.c's handling of operations such as ".previous",
|    ".2byte":
| 
| This is the wrong way around.  Actually, the pseudo-ops defined in
| tc-mips.c are used, provided they are defined.  You should be able to
| fix this problem by defining the relevant pseudo-ops in tc-mips.c, if
| OBJ_ELF is defined, to do the tc-mips local processing and then call
| the obj-elf.c routine.

OK -- thanks.  Just to clarify: it is considered OK for a tc-targ.c
routine to call an obj-format.c routine when processing these
pseudo-ops?

Related question: if this is the proper way to handle things, has
this problem already come up in a different ELF/DWARF port?
Is there a port (ie, Solaris) that already handles such things
properly, that I might use as a reference?

| 
|    For now, we just removed the check in mips_align(), which forces
|    alignment on the prior label.  
| 
| As you know, this is not really an acceptable solution.  Existing MIPS
| assembler code relies on this working.

roger.

| 
|    To work around these problems, we made following patches to tc-mips.c:
| 
| These patches are not really usable as is, because they don't include
| any context.  I don't know how you generated them, but please always
| generate patches using diff -c.
| 

Looks like I inadvertently specified "-c -p0", where the 0 is interpreted
as the number of lines of context (none) in this case.  I'll stick
with -c -p next time.  The patches _with_ context are shown below.

By the way, it seems that suggested fix of handling .#byte and .previous
in tc-mips.c will fix the assertion failure in mips_align(), but
this still leaves the question open (at least for me) as to the
best way to fix the handling of:

        .section        .debug
.L_D193:
        .4byte  .L_D193_e-.L_D193
        .2byte  0x14
        .2byte  0x12
        .4byte  .L_D198
        .2byte  0x38
        .asciiz "_i_Object__free"
        .2byte  0x83
        .2byte  .L_t193_e-.L_t193
.L_t193:

Do the patches to md_apply_fix() below, look like the way to go?

*** targ-cpu.c.orig	Sun Feb 12 20:51:25 1995
--- targ-cpu.c	Sun Feb 12 21:29:50 1995
*************** md_apply_fix (fixP, valueP)
*** 5310,5316 ****
--- 5310,5324 ----
    unsigned char *buf;
    long insn, value;
  
+ #if 0
+   /*
+    * DWARF support may define something like:
+    *   .2byte L1-L2
+    * which is handled as a fix up.  The check below incorrectly bounces
+    * that construct.
+    */
    assert (fixP->fx_size == 4);
+ #endif
  
    value = *valueP;
    fixP->fx_addnumber = value;	/* Remember value for tc_gen_reloc */
*************** md_apply_fix (fixP, valueP)
*** 5334,5339 ****
--- 5342,5356 ----
        /* Nothing needed to do. The value comes from the reloc entry */
        break;
  
+ #if 1
+     case BFD_RELOC_16:
+       /* nothing to do - but better not be relocatable.
+        * Sixteen bit fixups are generated by the DWARF support.
+        */
+       assert(!fixP->fx_pcrel);
+       break;
+ #endif
+ 
      case BFD_RELOC_PCREL_HI16_S:
        /* The addend for this is tricky if it is internal, so we just
  	 do everything here rather than in bfd_perform_relocation.  */
*************** mips_align (to, fill, label)
*** 5583,5594 ****
--- 5600,5619 ----
    mips_emit_delays ();
    frag_align (to, fill);
    record_alignment (now_seg, to);
+ #if 0
+   /* obj-elf.c doesn't communicate with these routines, yet it
+    * overrides ".previous", ".2byte",  etc.  They should clear,
+    * but do not know how to clear, insn_label, which is passed
+    * in as "label" to this routine.  For now, we remove the
+    * ability to align the previous label.
+    */
    if (label != NULL)
      {
        assert (S_GET_SEGMENT (label) == now_seg);
        label->sy_frag = frag_now;
        S_SET_VALUE (label, (valueT) frag_now_fix ());
      }
+ #endif
  }
  
  /* Align to a given power of two.  .align 0 turns off the automatic


--
|  Gary Funck  		     gary@intrepid.com
|  Intrepid Technology Inc., Mountain View CA (415) 964-8135
--





From ian@cygnus.com  Tue Feb 14 15:30:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 14 Feb 1995 15:30:00 -0000
Subject: gas - MIPS/ELF/DWARF probs
References: <9502142321.AA02979@presto>
Message-ID: <199502142330.SAA05269@sanguine.cygnus.com>

   Date: Tue, 14 Feb 95 15:21:55 -0800
   From: gary@Intrepid.COM (Gary Funck)

   OK -- thanks.  Just to clarify: it is considered OK for a tc-targ.c
   routine to call an obj-format.c routine when processing these
   pseudo-ops?

IMHO, yes.

   Related question: if this is the proper way to handle things, has
   this problem already come up in a different ELF/DWARF port?
   Is there a port (ie, Solaris) that already handles such things
   properly, that I might use as a reference?

Sure.  The MIPS port, itself, already overrides the ELF .section
directive.  It does MIPS specific stuff, and calls obj_elf_section.
Look at the end of md_pseudo_table in tc-mips.c (this may have been
added since the 2.5.2 release--if you don't know about the developer
snapshots for gas/binutils, ask me).

   Looks like I inadvertently specified "-c -p0", where the 0 is interpreted
   as the number of lines of context (none) in this case.  I'll stick
   with -c -p next time.  The patches _with_ context are shown below.

Thanks.

   By the way, it seems that suggested fix of handling .#byte and .previous
   in tc-mips.c will fix the assertion failure in mips_align(), but
   this still leaves the question open (at least for me) as to the
   best way to fix the handling of:

	   .section        .debug
   .L_D193:
	   .4byte  .L_D193_e-.L_D193
	   .2byte  0x14
	   .2byte  0x12
	   .4byte  .L_D198
	   .2byte  0x38
	   .asciiz "_i_Object__free"
	   .2byte  0x83
	   .2byte  .L_t193_e-.L_t193
   .L_t193:

   Do the patches to md_apply_fix() below, look like the way to go?

Yes, I believe that something along the lines of your patches is
correct.  Particularly if it works.

Ian



From rearnsha@armltd.co.uk  Sat Feb 18 08:17:00 1995
From: rearnsha@armltd.co.uk (Richard Earnshaw)
Date: Sat, 18 Feb 1995 08:17:00 -0000
Subject: Problems with gasp
Message-ID: <9502181619.AA19012@sun52.armltd>

I'm having some dificulty with variable expansion in gasp.  I'd like to concatenate
a variable with an additional string and put it back in the same variable.  The
code I have is, essentially:

	Temp	.ASSIGNC 	"string"
	...
	Temp	.ASSIGNC	"\&Temp'extra"

but the result of this is the string \&Temp'extra, not "stringextra" as desired.

This does not happen if I concatenate a macro parameter with extra, eg
	.MACRO Foo Temp
	bar	.ASSIGNC	"\Temp'foo"
	.ENDM

	Foo xxx

gives "xxxfoo" as desired.
	
Is this not inconsitent?

Additionally, here's a patch for istrue() in gasp.c, for strings NE never returns
true. 

*** gasp.c~     Thu Jan 19 21:04:07 1995
--- gasp.c      Sat Feb 18 16:04:40 1995
***************
*** 2330,2336 ****
          res = 0;
        }
        else
!       res = cond == EQ && same;
      }
    else
      /* This is a numeric expression */
--- 2330,2336 ----
          res = 0;
        }
        else
!       res = cond != EQ ^ same;
      }
    else
      /* This is a numeric expression */



From baford@schirf.cs.utah.edu  Sun Feb 19 11:04:00 1995
From: baford@schirf.cs.utah.edu (Bryan Ford)
Date: Sun, 19 Feb 1995 11:04:00 -0000
Subject: Relocation bug in i386-gnu-as
Message-ID: <199502191906.MAA27970@schirf.cs.utah.edu>

Given the following input:


	.text

	nop
	nop
	nop
	nop
foo:


	.data

	.long	0xdeadbeef
bar:
	.long	foo
	.long	0xbadf00d


the resulting value of 'bar' is consistently twice what it should be
(8 in this case instead of 4).  It's probably getting relocated twice
for some reason.  I'm using the gas-950208 snapshot.

Sorry if this has already been reported (it seems too obvious to
survive for long undetected).

Thanks!
				Bryan



From ian@cygnus.com  Sun Feb 19 19:25:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Sun, 19 Feb 1995 19:25:00 -0000
Subject: Relocation bug in i386-gnu-as
References: <199502191906.MAA27970@schirf.cs.utah.edu>
Message-ID: <9502200325.AA28377@tweedledumb.cygnus.com>

   Date: Sun, 19 Feb 1995 12:06:13 -0700
   From: baford@schirf.cs.utah.edu (Bryan Ford)

   the resulting value of 'bar' is consistently twice what it should be
   (8 in this case instead of 4).  It's probably getting relocated twice
   for some reason.  I'm using the gas-950208 snapshot.

I believe this was fixed on 15 Feb.

Ian



From baford@schirf.cs.utah.edu  Mon Feb 20 08:04:00 1995
From: baford@schirf.cs.utah.edu (Bryan Ford)
Date: Mon, 20 Feb 1995 08:04:00 -0000
Subject: More gas/bfd patches
Message-ID: <199502201605.JAA01594@schirf.cs.utah.edu>

OK, here are three more patches, based on the gas-950208 snapshot.
I've verified that they merge cleanly into gas-950219.

The first is just another minor bug fix to the 16-bit i386 support:

diff -ur gas-950208/include/opcode/i386.h gas-new/include/opcode/i386.h
--- gas-950208/include/opcode/i386.h	Mon Feb  6 12:00:43 1995
+++ gas-new/include/opcode/i386.h	Sun Feb 19 10:06:03 1995
@@ -101,6 +101,8 @@
 {"sahf", 0, 0x9e, _, NoModrm, { 0, 0, 0} },
 {"pushf", 0, 0x9c, _, NoModrm|Data32, { 0, 0, 0} },
 {"popf", 0, 0x9d, _, NoModrm|Data32, { 0, 0, 0} },
+{"pushfl", 0, 0x9c, _, NoModrm|Data32, { 0, 0, 0} },
+{"popfl", 0, 0x9d, _, NoModrm|Data32, { 0, 0, 0} },
 {"pushfw", 0, 0x9c, _, NoModrm|Data16, { 0, 0, 0} },
 {"popfw", 0, 0x9d, _, NoModrm|Data16, { 0, 0, 0} },
 {"stc", 0, 0xf9, _, NoModrm, { 0, 0, 0} },
@@ -280,8 +282,10 @@
 {"lret", 1, 0xca, _, NoModrm|Data32, { Imm16, 0, 0} },
 {"lretw", 0, 0xcb, _, NoModrm|Data16, { 0, 0, 0} },
 {"lretw", 1, 0xca, _, NoModrm|Data16, { Imm16, 0, 0} },
-{"enter", 2, 0xc8, _, NoModrm, { Imm16, Imm8, 0} },
-{"leave", 0, 0xc9, _, NoModrm, { 0, 0, 0} },
+{"enter", 2, 0xc8, _, NoModrm|Data32, { Imm16, Imm8, 0} },
+{"leave", 0, 0xc9, _, NoModrm|Data32, { 0, 0, 0} },
+{"enterw", 2, 0xc8, _, NoModrm|Data16, { Imm16, Imm8, 0} },
+{"leavew", 0, 0xc9, _, NoModrm|Data16, { 0, 0, 0} },
 
 /* conditional jumps */
 {"jo", 1, 0x70, _, Jump, { Disp, 0, 0} },


The second is a minor fix to bfd/libaout.h that I needed 
in order to get bfd to compile here:

diff -cr gas-950208/bfd/libaout.h gas-950208-new/bfd/libaout.h
*** gas-950208/bfd/libaout.h	Thu Feb  9 08:04:33 1995
--- gas-950208-new/bfd/libaout.h	Thu Feb  9 08:08:55 1995
***************
*** 442,448 ****
  NAME(aout,swap_std_reloc_in) PARAMS ((bfd *, struct reloc_std_external *,
  				      arelent *, asymbol **));
  
! CONST struct reloc_howto_struct *
  NAME(aout,reloc_type_lookup) PARAMS ((bfd *abfd,
  				      bfd_reloc_code_real_type code));
  
--- 442,448 ----
  NAME(aout,swap_std_reloc_in) PARAMS ((bfd *, struct reloc_std_external *,
  				      arelent *, asymbol **));
  
! reloc_howto_type *
  NAME(aout,reloc_type_lookup) PARAMS ((bfd *abfd,
  				      bfd_reloc_code_real_type code));
  

The third is a little more interesting - it adds read support
to the "binary" BFD backend.  Basically, if you specify "binary"
as the format of an input file to ld or objcopy or whatever,
the input file will be read into a data section as raw, uninterpreted bytes,
and some symbols will be produced, based on the filename of the input file,
marking the start and end of the data chunk.  Basically, it allows you
to link arbitrary files into a program without all the machine-dependent,
format-dependent "wrap-a-file-in-a-.o" kludgery that's usually needed.
(e.g. see the Linux boot image creation mechanism. :-) )

The binary BFD reader will only be enabled when it is specifically
requested by name; it will never "match" when an automatic BFD format
search is being done.

I didn't find any documentation on the binary BFD backend (or on any
other BFD backends for that matter); if there is some, point me to it
and I'll add appropriate documentation for the reader.

BTW, this code requires a horrible kludge to find the size of the
input file, because bfd_seek doesn't support SEEK_END, and by definition
there's no way to find the length of an uninterpreted binary input file
based only its contents.  (I just read through the file once and count
the number of bytes before EOF.)  I noticed that the srec reader also
needs to detect EOF.  Maybe it would be a good idea to enable SEEK_END
in bfd_seek(), and simply make it known that certain file formats
cannot be placed in archives.  Perhaps modify the ASSERT in bfd_seek()
to die only if someone tries to bfd_seek in an archive...?

				Bryan

diff -ur gas-950208/bfd/binary.c gas-new/bfd/binary.c
--- gas-950208/bfd/binary.c	Wed Oct 19 12:08:55 1994
+++ gas-new/bfd/binary.c	Sat Feb 18 13:48:50 1995
@@ -31,10 +31,16 @@
    the file.  objcopy cooperates by specially setting the start
    address to zero by default.  */
 
+#include <ctype.h>
+
 #include "bfd.h"
 #include "sysdep.h"
 #include "libbfd.h"
 
+/* Any bfd we create by reading a binary file has three symbols:
+   a start symbol, an end symbol, and an absolute length symbol.  */
+#define BIN_SYMS 2
+
 static boolean binary_mkobject PARAMS ((bfd *));
 static asymbol *binary_make_empty_symbol PARAMS ((bfd *));
 static boolean binary_set_section_contents
@@ -50,15 +56,29 @@
 }
 
 /* Most of the symbol routines can just return an error.  */
-#define binary_get_symtab_upper_bound _bfd_nosymbols_get_symtab_upper_bound
-#define binary_get_symtab _bfd_nosymbols_get_symtab
+#define	binary_close_and_cleanup _bfd_generic_close_and_cleanup
+#define binary_bfd_free_cached_info _bfd_generic_bfd_free_cached_info
+#define binary_new_section_hook _bfd_generic_new_section_hook
+
 #define binary_print_symbol _bfd_nosymbols_print_symbol
-#define binary_get_symbol_info _bfd_nosymbols_get_symbol_info
-#define binary_bfd_is_local_label _bfd_nosymbols_bfd_is_local_label
+#define binary_bfd_is_local_label bfd_generic_is_local_label
 #define binary_get_lineno _bfd_nosymbols_get_lineno
 #define binary_find_nearest_line _bfd_nosymbols_find_nearest_line
 #define binary_bfd_make_debug_symbol _bfd_nosymbols_bfd_make_debug_symbol
 
+#define binary_get_reloc_upper_bound \
+  ((long (*) PARAMS ((bfd *, asection *))) bfd_0l)
+#define binary_canonicalize_reloc \
+  ((long (*) PARAMS ((bfd *, asection *, arelent **, asymbol **))) bfd_0l)
+#define binary_bfd_reloc_type_lookup _bfd_norelocs_bfd_reloc_type_lookup
+
+#define binary_bfd_get_relocated_section_contents \
+  bfd_generic_get_relocated_section_contents
+#define binary_bfd_relax_section bfd_generic_relax_section
+#define binary_bfd_link_hash_table_create _bfd_generic_link_hash_table_create
+#define binary_bfd_link_add_symbols _bfd_generic_link_add_symbols
+#define binary_bfd_final_link _bfd_generic_final_link
+
 /* We do have to provide a routine to make an empty symbol.  */
 
 static asymbol *
@@ -108,6 +128,176 @@
   return _bfd_generic_set_section_contents (abfd, sec, data, offset, size);
 }
 
+/* Check whether an existing file is a binary file.
+   Pretty easy - _every_ file is as far as we're concerned. :-)
+   However, only "recognize" the file
+   if the input target was explicitly set to "binary",
+   not if we're doing an automatic target search.  */
+
+static const bfd_target *
+binary_object_p (abfd)
+     bfd *abfd;
+{
+  long bytes;
+
+  if (abfd->target_defaulted)
+    return NULL;
+
+  abfd->symcount = BIN_SYMS;
+
+  /* Find the file size.  XXX big kludge,
+     because bfd_seek doesn't like SEEK_END.  */
+  {
+    bfd_byte c;
+
+    if (bfd_seek (abfd, (file_ptr) 0, SEEK_SET) != 0)
+      return NULL;
+
+    bytes = 0;
+    while (bfd_read (&c, 1, 1, abfd) == 1)
+      bytes++;
+
+    if (bfd_get_error () != bfd_error_file_truncated)
+      return NULL;
+  }
+
+  /* One data section.  */
+  {
+    asection *sec;
+    char *secname;
+
+    secname = (char *) bfd_alloc (abfd, strlen (".data") + 1);
+    strcpy (secname, ".data");
+    sec = bfd_make_section (abfd, secname);
+    if (sec == NULL)
+      return NULL;
+    sec->flags = SEC_ALLOC | SEC_LOAD | SEC_DATA | SEC_HAS_CONTENTS;
+    sec->vma = 0;
+    sec->_raw_size = bytes;
+    sec->filepos = 0;
+
+    abfd->tdata.any = (PTR)sec;
+  }
+
+  return abfd->xvec;
+}
+
+/* Get the contents of "the" section.  */
+
+static boolean
+binary_get_section_contents (abfd, section, location, offset, count)
+     bfd *abfd;
+     asection *section;
+     PTR location;
+     file_ptr offset;
+     bfd_size_type count;
+{
+  if ((bfd_seek (abfd, offset, SEEK_SET) != 0)
+      || (bfd_read (location, 1, count, abfd) != count))
+    return false;
+  return true;
+}
+
+/* Return the amount of memory needed to read the symbol table.  */
+
+static long
+binary_get_symtab_upper_bound (abfd)
+     bfd *abfd;
+{
+  return (BIN_SYMS + 1) * sizeof (asymbol *);
+}
+
+void
+binary_get_symbol_info (ignore_abfd, symbol, ret)
+     bfd *ignore_abfd;
+     asymbol *symbol;
+     symbol_info *ret;
+{
+  bfd_symbol_info (symbol, ret);
+}
+
+/* Create a symbol name based on the bfd's filename.  */
+static char *mangle_name(abfd, suffix)
+     bfd *abfd;
+     char *suffix;
+{
+  int size = strlen(bfd_get_filename(abfd)) + strlen(suffix) + 10;
+  char *buf = (char*) bfd_alloc (abfd, size);
+  char *p;
+
+  if (buf == NULL)
+    {
+      bfd_set_error (bfd_error_no_memory);
+      return false;
+    }
+
+  sprintf(buf, "_binary_%s_%s", bfd_get_filename(abfd), suffix);
+
+  /* Change any non-alphanumeric characters to underscores.  */
+  for (p = buf; *p; p++)
+    if (!isalnum(*p))
+      *p = '_';
+
+  return buf;
+}
+
+/* Return the symbol table.  */
+
+static long
+binary_get_symtab (abfd, alocation)
+     bfd *abfd;
+     asymbol **alocation;
+{
+  asection *sec = (asection*)abfd->tdata.any;
+  asymbol *syms;
+  unsigned int i;
+
+  syms = (asymbol *) bfd_alloc (abfd, BIN_SYMS * sizeof (asymbol));
+  if (syms == NULL)
+    {
+      bfd_set_error (bfd_error_no_memory);
+      return false;
+    }
+
+  /* Start symbol.  */
+  syms[0].the_bfd = abfd;
+  syms[0].name = mangle_name(abfd, "start");
+  syms[0].value = 0;
+  syms[0].flags = BSF_GLOBAL;
+  syms[0].section = sec;
+  syms[0].udata.p = NULL;
+
+  /* End symbol.  */
+  syms[1].the_bfd = abfd;
+  syms[1].name = mangle_name(abfd, "end");
+  syms[1].value = sec->_raw_size;
+  syms[1].flags = BSF_GLOBAL;
+  syms[1].section = sec;
+  syms[1].udata.p = NULL;
+
+  /* End symbol.  */
+  syms[2].the_bfd = abfd;
+  syms[2].name = mangle_name(abfd, "size");
+  syms[2].value = sec->_raw_size;
+  syms[2].flags = BSF_GLOBAL;
+  syms[2].section = bfd_abs_section_ptr;
+  syms[2].udata.p = NULL;
+
+  for (i = 0; i < BIN_SYMS; i++)
+    *alocation++ = syms++;
+  *alocation = NULL;
+
+  return BIN_SYMS;
+}
+
+static int
+binary_sizeof_headers (abfd, exec)
+     bfd *abfd;
+     boolean exec;
+{
+  return 0;
+}
+
 const bfd_target binary_vec =
 {
   "binary",			/* name */
@@ -129,7 +319,7 @@
   bfd_getb16, bfd_getb_signed_16, bfd_putb16,	/* hdrs */
   {				/* bfd_check_format */
     _bfd_dummy_target,
-    _bfd_dummy_target,
+    binary_object_p,		/* bfd_check_format */
     _bfd_dummy_target,
     _bfd_dummy_target,
   },
@@ -146,14 +336,14 @@
     bfd_false,
   },
 
-  BFD_JUMP_TABLE_GENERIC (_bfd_generic),
+  BFD_JUMP_TABLE_GENERIC (binary),
   BFD_JUMP_TABLE_COPY (_bfd_generic),
   BFD_JUMP_TABLE_CORE (_bfd_nocore),
   BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
   BFD_JUMP_TABLE_SYMBOLS (binary),
-  BFD_JUMP_TABLE_RELOCS (_bfd_norelocs),
+  BFD_JUMP_TABLE_RELOCS (binary),
   BFD_JUMP_TABLE_WRITE (binary),
-  BFD_JUMP_TABLE_LINK (_bfd_nolink),
+  BFD_JUMP_TABLE_LINK (binary),
   BFD_JUMP_TABLE_DYNAMIC (_bfd_nodynamic),
 
   NULL



From ian@cygnus.com  Mon Feb 20 08:18:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 20 Feb 1995 08:18:00 -0000
Subject: More gas/bfd patches
References: <199502201605.JAA01594@schirf.cs.utah.edu>
Message-ID: <9502201618.AA15371@tweedledumb.cygnus.com>

   Date: Mon, 20 Feb 95 09:05:36 MST
   From: Bryan Ford <baford@schirf.cs.utah.edu>

   The third is a little more interesting - it adds read support
   to the "binary" BFD backend.  Basically, if you specify "binary"
   as the format of an input file to ld or objcopy or whatever,
   the input file will be read into a data section as raw, uninterpreted bytes,
   and some symbols will be produced, based on the filename of the input file,
   marking the start and end of the data chunk.  Basically, it allows you
   to link arbitrary files into a program without all the machine-dependent,
   format-dependent "wrap-a-file-in-a-.o" kludgery that's usually needed.
   (e.g. see the Linux boot image creation mechanism. :-) )

Note that objcopy now supports the --add-section option.  It's not
quite the same thing, though, I suppose.

   BTW, this code requires a horrible kludge to find the size of the
   input file, because bfd_seek doesn't support SEEK_END, and by definition
   there's no way to find the length of an uninterpreted binary input file
   based only its contents.  (I just read through the file once and count
   the number of bytes before EOF.)

Why not just use stat?

Ian



From hjl@nynexst.com  Mon Feb 20 10:32:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 20 Feb 1995 10:32:00 -0000
Subject: Add -N support to ELF?
References: <9502201618.AA15371@tweedledumb.cygnus.com>
Message-ID: <9502201825.AA25297@titanic.nynexst.com>

I have been thinking to add -N support to ELF. The current ELF code
will put all sections into one segment if it can. It somewhat works
like -N. If the text section ends on a page boundary and the data
section starts right after it, both sections will be put into one 
big segment. That means the binary may not be sharable. The current
solution is skip a page if that happens. I was wondering if we
could change it such that:

1. When -N is not used, if the sh_flags of the current section
   is not compatible with the p_flags of the current segment, start
   a new segment.

2. When -N is used, behave just like the old way.

I can make the changes. But I don't think may changes will be
acceptable to everyone :-(. Will a new field in bfd_link_info help?

Thanks.

H.J.



From ian@cygnus.com  Mon Feb 20 11:29:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 20 Feb 1995 11:29:00 -0000
Subject: Add -N support to ELF?
References: <9502201825.AA25297@titanic.nynexst.com>
Message-ID: <9502201929.AA21317@tweedledumb.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Mon, 20 Feb 95 13:30:57 EST

   1. When -N is not used, if the sh_flags of the current section
      is not compatible with the p_flags of the current segment, start
      a new segment.

   2. When -N is used, behave just like the old way.

This seems reasonable in principle.  The trick is defining
``compatible'' is a useful fashion.  I have not been able to think of
a good definition, but I haven't thought about it all that much,
either.

   I can make the changes. But I don't think may changes will be
   acceptable to everyone :-(. Will a new field in bfd_link_info help?

A new field is not necessary.  Check the flags field of the output
field, and switch on the D_PAGED flag.  D_PAGED is set by default, and
turned off when -N (or -n) is used.  For example, the a.out backend
uses D_PAGED to determine whether the output file should be zmagic or
omagic.

Ian



From hjl@nynexst.com  Mon Feb 20 12:50:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 20 Feb 1995 12:50:00 -0000
Subject: Add -N support to ELF?
References: <9502201929.AA21317@tweedledumb.cygnus.com>
Message-ID: <9502202043.AA25460@titanic.nynexst.com>

> 
>    From: hjl@nynexst.com (H.J. Lu)
>    Date: Mon, 20 Feb 95 13:30:57 EST
> 
>    1. When -N is not used, if the sh_flags of the current section
>       is not compatible with the p_flags of the current segment, start
>       a new segment.
> 
>    2. When -N is used, behave just like the old way.
> 
> This seems reasonable in principle.  The trick is defining
> ``compatible'' is a useful fashion.  I have not been able to think of
> a good definition, but I haven't thought about it all that much,
> either.

By "compatible", I mean 

((hdr->sh_flags & SHF_WRITE) && (phdr->p_flags & PF_W))

or

((hdr->sh_flags & SHF_WRITE) == 0 && (phdr->p_flags & PF_W) == 0)

As a matter of fact, the code is already there in elfcode.h in
my source tree. But it is commented out with

/* FIXME: ctors/dtors contain the code, but are r/w. */

We have moved ctors/dtors into the data section. That won't
be the problem any more. But this may break those embedded systems.


H.J.



From hjl@nynexst.com  Mon Feb 20 13:20:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 20 Feb 1995 13:20:00 -0000
Subject: Add -N support to ELF?
References: <9502201929.AA21317@tweedledumb.cygnus.com>
Message-ID: <9502202113.AA25517@titanic.nynexst.com>

> 
>    From: hjl@nynexst.com (H.J. Lu)
>    Date: Mon, 20 Feb 95 13:30:57 EST
> 
>    1. When -N is not used, if the sh_flags of the current section
>       is not compatible with the p_flags of the current segment, start
>       a new segment.
> 
>    2. When -N is used, behave just like the old way.
> 
> This seems reasonable in principle.  The trick is defining
> ``compatible'' is a useful fashion.  I have not been able to think of
> a good definition, but I haven't thought about it all that much,
> either.
> 
>    I can make the changes. But I don't think may changes will be
>    acceptable to everyone :-(. Will a new field in bfd_link_info help?
> 
> A new field is not necessary.  Check the flags field of the output
> field, and switch on the D_PAGED flag.  D_PAGED is set by default, and
> turned off when -N (or -n) is used.  For example, the a.out backend
> uses D_PAGED to determine whether the output file should be zmagic or
> omagic.
> 
> Ian
> 

This patch is derived from some patch I got, Eric? It should work
fine. Ian, is that ok to uncomment my patch to elf.sc with this one
applied? I guess the docs should be updated to reflect the usage
of -N in ELF.

Thanks.



-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
-----
*** elfcode.h	Sat Feb 18 10:25:01 1995
--- elfcode.h.new	Mon Feb 20 16:13:22 1995
***************
*** 1968,1974 ****
--- 1968,1986 ----
        if (phdr->p_type != PT_NULL
  	  && (hdr->sh_offset - (phdr->p_offset + phdr->p_memsz)
  	      == hdr->sh_addr - (phdr->p_vaddr + phdr->p_memsz))
+ #if 1
+ 	  && (last_type != SHT_NOBITS || hdr->sh_type == SHT_NOBITS)
+ 	  /* We check to see if the binary is for demand page. We
+ 	     want to make sure the curent section is compatible with
+ 	     the current segment. Otherwise, start a new segment. We
+ 	     have to be very careful about elf.sc. Don't put any
+ 	     writable sections into the text segment. */
+ 	  && (((abfd->flags & D_PAGED) == 0)
+ 	      || (((hdr->sh_flags & SHF_WRITE) == 0 && (phdr->p_flags & PF_W) == 0)
+ 	      || ((hdr->sh_flags & SHF_WRITE) != 0 && (phdr->p_flags & PF_W) != 0))))
+ #else
  	  && (last_type != SHT_NOBITS || hdr->sh_type == SHT_NOBITS))
+ #endif
  	{
  	  bfd_size_type adjust;
  



From ian@cygnus.com  Mon Feb 20 14:03:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 20 Feb 1995 14:03:00 -0000
Subject: Add -N support to ELF?
References: <9502202113.AA25517@titanic.nynexst.com>
Message-ID: <9502202203.AA27479@tweedledumb.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Mon, 20 Feb 95 16:18:38 EST

   This patch is derived from some patch I got, Eric? It should work
   fine. Ian, is that ok to uncomment my patch to elf.sc with this one
   applied? I guess the docs should be updated to reflect the usage
   of -N in ELF.

The basic problem with this approach is that I believe it will cause
the linker to unexpectedly abort if, say, one of the input files has a
writable .text section.  Try it.

The linker already aborts unexpectedly far too often, and I would
prefer not to introduce another possibility.  If you can write the
patch in such a fashion that it can not cause a linker abort--perhaps
by making it retry the division of sections into segments if the first
attempt uses too many segments--I would be more willing to put this
in.  The beneficial effects of this patch are vanishingly small--it
saves one page of virtual memory address space (not virtual memory
itself, but just the address space) for a very small number of
programs--so IMHO it should only be put in if it is completely safe.

Ian



From hjl@nynexst.com  Mon Feb 20 14:44:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 20 Feb 1995 14:44:00 -0000
Subject: Add -N support to ELF?
References: <9502202203.AA27479@tweedledumb.cygnus.com>
Message-ID: <9502202236.AA25617@titanic.nynexst.com>

> 
>    From: hjl@nynexst.com (H.J. Lu)
>    Date: Mon, 20 Feb 95 16:18:38 EST
> 
>    This patch is derived from some patch I got, Eric? It should work
>    fine. Ian, is that ok to uncomment my patch to elf.sc with this one
>    applied? I guess the docs should be updated to reflect the usage
>    of -N in ELF.
> 
> The basic problem with this approach is that I believe it will cause
> the linker to unexpectedly abort if, say, one of the input files has a
> writable .text section.  Try it.

I know. That is why I put those comments there and why Eric commented
it out at the first place. At that time, ctors/dtors were in the
.text segment.

> 
> The linker already aborts unexpectedly far too often, and I would
> prefer not to introduce another possibility.  If you can write the
> patch in such a fashion that it can not cause a linker abort--perhaps
> by making it retry the division of sections into segments if the first


I think it is wrong to put the writable section into the .text section.
It will break any schemes which uses the .text section like

const char * const foo = "You should die if you modify it.";

There must be a bug in somewhere else if ld dies. It is not my
patch's fault.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From ian@cygnus.com  Mon Feb 20 15:48:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 20 Feb 1995 15:48:00 -0000
Subject: Add -N support to ELF?
References: <9502202236.AA25617@titanic.nynexst.com>
Message-ID: <9502202348.AA06378@tweedledumb.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Mon, 20 Feb 95 17:42:10 EST

   I think it is wrong to put the writable section into the .text section.
   It will break any schemes which uses the .text section like

   const char * const foo = "You should die if you modify it.";

>From the linker's point of view, there is nothing wrong with having a
writable .text section.  The current linker will handle it correctly,
in the sense that it will produce a program segment which is marked
writable.

   There must be a bug in somewhere else if ld dies. It is not my
   patch's fault.

The bug is that given the standard ELF linker script in elf.sc, the
linker has to know the number of program segments it is going to
generate before it assigns addresses to any of the sections.  This is
because of the use of SIZEOF_HEADERS in elf.sc, which is used as is
normal for an ELF target.  Unfortunately, the GNU linker will ask the
BFD backend for the size of the header information before it has fully
sorted out the section layout of the input files.  It has no mechanism
for adjusting the header size based on the section layout.  Therefore,
the BFD backend will guess that only two segments are required.  If
more than two segments are required, the linker must abort.

You are absolutely correct in saying that this bug is not related to
your patch.

However, look at it from my perspective.  Right now, the linker will
always work correctly given the script in elf.sc, and (thanks to some
patches from Doug Evans) it will always work given a script which does
not use SIZEOF_HEADERS.  It will currently fail when given a script
which uses SIZEOF_HEADERS which does not arrange the sections
carefully.  It will also sometimes allocate an unnecessary page of
virtual address space.

Your patch fixes the last problem.  However, if your patch is applied,
it will no longer be the case that the linker will always work
correctly given the script in elf.sc.

To my mind, that is too heavy a price to pay.  The bug you are fixing
is a rather theoretical one--I may misunderstand something, but I
think I would find it difficult to construct a program which failed to
run without your patch.  If your patch were harmless, I would put it
in.  However, I believe that it is not harmless.

I believe that the correct thing to do is to permit the linker to
adjust SIZEOF_HEADERS based on the section layout.  However, that may
be a complicated task, I have very little time, and I am not aware of
any person who has actually encountered the problem.  If I receive
patches to fix that problem, I will put your patch in at that time.

Ian



From hjl@nynexst.com  Fri Feb 24 13:53:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Fri, 24 Feb 1995 13:53:00 -0000
Subject: A Linux ELF patch for gas
Message-ID: <9502242145.AA09704@titanic.nynexst.com>

This patch allows the linker configured for ELF under Linux use
ELF as the default format.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
----
*** /dev/null	Fri Feb 24 16:31:43 1995
--- bfd/config/i386-linuxelf.mt	Fri Feb 24 16:27:33 1995
***************
*** 0 ****
--- 1,5 ----
+ # Target:  Intel 386 running linux using ELF
+ 
+ DEFAULT_VECTOR=bfd_elf32_i386_vec
+ SELECT_VECS=i386linux_vec
+ SELECT_ARCHITECTURES=bfd_i386_arch
*** bfd/config.bfd.ss	Fri Feb 24 16:26:07 1995
--- bfd/config.bfd	Fri Feb 24 16:26:26 1995
***************
*** 53,58 ****
--- 53,59 ----
    i[345]86-*-freebsd*)	bfd_name=i386-bsd strip_underscore=yes ;;
    i[345]86-*-netbsd*)	bfd_name=i386-nbsd strip_underscore=yes ;;
    i[345]86-*-netware*)	bfd_name=i386-nlm ;;
+   i[345]86-*-linuxelf)	bfd_name=i386-linuxelf strip_underscore=yes ;;
    i[345]86-*-linux*)	bfd_name=i386-linux strip_underscore=yes ;;
    i[345]86-*-lynxos*)	bfd_name=i386-lynx ;;
    i[345]86-*-gnu*)	bfd_name=i386-gnu strip_underscore=yes ;;



From hjl@nynexst.com  Fri Feb 24 14:39:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Fri, 24 Feb 1995 14:39:00 -0000
Subject: More Linux patches for gas
Message-ID: <9502242232.AA09914@titanic.nynexst.com>

I missed those two.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
----
*** ld/configure.in.ss	Fri Feb 24 17:35:26 1995
--- ld/configure.in	Fri Feb 24 17:35:43 1995
***************
*** 71,76 ****
--- 71,77 ----
    i[345]86-*-bsd386)	ld_target=i386-bsd ;;
    i[345]86-*-bsdi*)	ld_target=i386-bsd ;;
    i[345]86-*-aout)	ld_target=i386-aout ;;
+   i[345]86-*-linuxelf)	ld_target=i386-linuxelf ;;
    i[345]86-*-linux*)	ld_target=i386-linux ;;
    i[345]86-*-sysv4*)	ld_target=i386-elf ;;
    i[345]86-*-unixware)	ld_target=i386-elf ;;
*** /dev/null	Fri Feb 24 17:36:47 1995
--- ld/config/i386-linuxelf.mt	Fri Feb 24 17:35:01 1995
***************
*** 0 ****
--- 1,2 ----
+ EMUL=elf_i386
+ EMUL_EXTRA1=i386linux



From hjl@nynexst.com  Sat Feb 25 14:08:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Sat, 25 Feb 1995 14:08:00 -0000
Subject: elf.sc and shared library for binutils
Message-ID: <9502252200.AA11678@titanic.nynexst.com>

Here are some comments from elf.sc:

  /* Adjust the address for the data segment.  We want to adjust up to
     the same address within the page on the next page up.  It would
     be more correct to do this:
       ${RELOCATING+. = ${DATA_ADDR-ALIGN(${MAXPAGESIZE})
		+ ((ALIGN(8) + ${MAXPAGESIZE} - ALIGN(${MAXPAGESIZE}))
		   & (${MAXPAGESIZE} - 1)};}

I think the correct one should be

       ${RELOCATING+. = ALIGN(${MAXPAGESIZE})
		+ ((ALIGN(8) + ${MAXPAGESIZE} - ALIGN(${MAXPAGESIZE}))
		   & (${MAXPAGESIZE} - 1)};}

It should be independent of DATA_ADDR.

I have been adding the ELF shared library support for binutils under
Linux for a while. Any chance to support it in the official source?

H.J.



From eric@aib.com  Sat Feb 25 14:10:00 1995
From: eric@aib.com (Eric Youngdale)
Date: Sat, 25 Feb 1995 14:10:00 -0000
Subject: elf.sc and shared library for binutils
References: <9502252200.AA11678@titanic.nynexst.com>
Message-ID: <9502252141.ZM515@aib.com>

On Feb 25,  5:06pm, H.J. Lu wrote:
> Subject: elf.sc and shared library for binutils
> Here are some comments from elf.sc:
>
>   /* Adjust the address for the data segment.  We want to adjust up
to
>      the same address within the page on the next page up.  It
would
>      be more correct to do this:

	Maybe I am missing something, but why is this so important.
 All we
end up doing is wasting one page of VM (not physical memory, just
virtual memory).
Is there something else here?

-Eric


-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."



From ian@cygnus.com  Sat Feb 25 14:17:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Sat, 25 Feb 1995 14:17:00 -0000
Subject: elf.sc and shared library for binutils
References: <9502252200.AA11678@titanic.nynexst.com>
Message-ID: <199502252217.OAA27441@rtl.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Sat, 25 Feb 95 17:06:41 EST

   Here are some comments from elf.sc:

     /* Adjust the address for the data segment.  We want to adjust up to
	the same address within the page on the next page up.  It would
	be more correct to do this:
	  ${RELOCATING+. = ${DATA_ADDR-ALIGN(${MAXPAGESIZE})
		   + ((ALIGN(8) + ${MAXPAGESIZE} - ALIGN(${MAXPAGESIZE}))
		      & (${MAXPAGESIZE} - 1)};}

   I think the correct one should be

	  ${RELOCATING+. = ALIGN(${MAXPAGESIZE})
		   + ((ALIGN(8) + ${MAXPAGESIZE} - ALIGN(${MAXPAGESIZE}))
		      & (${MAXPAGESIZE} - 1)};}

   It should be independent of DATA_ADDR.

I believe that it should depend upon DATA_ADDR if it is set.  Note
that most targets do not set DATA_ADDR.  However, Irix 5 does set
DATA_ADDR.  On Irix 5, unlike most ELF targets, the .data section
always starts at 0x10000000.  I think the GNU linker may as well be
compatible.

In any case, since DATA_ADDR is not normally set, why bother to make
this change?

   I have been adding the ELF shared library support for binutils under
   Linux for a while. Any chance to support it in the official source?

Yes, I would think so.  I was not aware that there was any shared
library support that was not in the FSF sources.  What sort of stuff
is it?

Ian



From meissner@cygnus.com  Mon Feb 27 06:54:00 1995
From: meissner@cygnus.com (Mike Meissner)
Date: Mon, 27 Feb 1995 06:54:00 -0000
Subject: elf.sc and shared library for binutils
References: <9502252200.AA11678@titanic.nynexst.com> <9502252141.ZM515@aib.com> <9502252141.ZM515@aib.com>
Message-ID: <199502271454.JAA00408@tiktok.cygnus.com>

| On Feb 25,  5:06pm, H.J. Lu wrote:
| > Subject: elf.sc and shared library for binutils
| > Here are some comments from elf.sc:
| >
| >   /* Adjust the address for the data segment.  We want to adjust up
| to
| >      the same address within the page on the next page up.  It
| would
| >      be more correct to do this:
| 
| 	Maybe I am missing something, but why is this so important.
|  All we
| end up doing is wasting one page of VM (not physical memory, just
| virtual memory).
| Is there something else here?

If you don't do this, each program will be one physical page larger,
since the pages in the data area would start on a new page, leaving a
hole in the program file as it exists on disk between the text and
data.

This is why V.4 specifies this behavior.

-- 
Michael Meissner, Cygnus Support (East Coast)
Suite 105, 48 Grove Street, Somerville, MA 02144, USA
meissner@cygnus.com,	617-629-3016 (office),	617-629-3010 (fax)



From baford@schirf.cs.utah.edu  Mon Feb 27 12:18:00 1995
From: baford@schirf.cs.utah.edu (Bryan Ford)
Date: Mon, 27 Feb 1995 12:18:00 -0000
Subject: Updated patch
Message-ID: <199502272020.NAA28280@schirf.cs.utah.edu>

Here's an updated version of the patch I sent a few days ago;
it fixes the file size kludge and a few other minor problems.
This patch is based on yesterday's snapshot.  Also, I included
ChangeLog entries this time.  (Sorry I missed that before.)
Please try to get this in ASAP; Mach now depends on it.

Thanks!

				Bryan

diff -ur gas-950226/bfd/ChangeLog gas-950226-new/bfd/ChangeLog
--- gas-950226/bfd/ChangeLog	Sun Feb 26 08:16:25 1995
+++ gas-950226-new/bfd/ChangeLog	Mon Feb 27 13:12:23 1995
@@ -1,3 +1,18 @@
+Mon Feb 27 08:36:39 1995  Bryan Ford  <baford@cs.utah.edu>
+
+	* binary.c: Add support for reading binary files.
+	Loads the raw contents of the file into a data section
+	and wraps some symbols around it.  '_binary_<filename>_start'
+	and '_binary_<filename>_end' indicate the start and end
+	of the data, while '_binary_<filename>_size' is an
+	absolute symbol whose value is the size of the data.
+	<filename> is the name of the binary input file,
+	with all non-alphanumeric characters converted to underscores.
+
+	* archures.c: When checking for architecture compatibility,
+	assume the user knows what he's doing if one of the architectures
+	is 'unknown', instead of producing a bogus error.
+
 Wed Feb 22 14:40:26 1995  Ian Lance Taylor  <ian@cygnus.com>
 
 	* libaout.h (NAME(aout,slurp_reloc_table)): Change declaration to
diff -ur gas-950226/bfd/archures.c gas-950226-new/bfd/archures.c
--- gas-950226/bfd/archures.c	Sun Feb 26 08:16:26 1995
+++ gas-950226-new/bfd/archures.c	Mon Feb 27 09:20:18 1995
@@ -238,6 +238,14 @@
      CONST bfd *abfd;
      CONST bfd *bbfd;
 {
+  /* If either architecture is unknown,
+     then all we can do is assume the user knows what he's doing.  */
+  if (abfd->arch_info->arch == bfd_arch_unknown)
+  	return bbfd->arch_info;
+  if (bbfd->arch_info->arch == bfd_arch_unknown)
+  	return abfd->arch_info;
+
+  /* Otherwise architecture-specific code has to decide.  */
   return  abfd->arch_info->compatible(abfd->arch_info,bbfd->arch_info);
 }
 
diff -ur gas-950226/bfd/binary.c gas-950226-new/bfd/binary.c
--- gas-950226/bfd/binary.c	Wed Oct 19 12:08:55 1994
+++ gas-950226-new/bfd/binary.c	Mon Feb 27 08:40:42 1995
@@ -31,10 +31,16 @@
    the file.  objcopy cooperates by specially setting the start
    address to zero by default.  */
 
+#include <ctype.h>
+
 #include "bfd.h"
 #include "sysdep.h"
 #include "libbfd.h"
 
+/* Any bfd we create by reading a binary file has three symbols:
+   a start symbol, an end symbol, and an absolute length symbol.  */
+#define BIN_SYMS 3
+
 static boolean binary_mkobject PARAMS ((bfd *));
 static asymbol *binary_make_empty_symbol PARAMS ((bfd *));
 static boolean binary_set_section_contents
@@ -50,15 +56,29 @@
 }
 
 /* Most of the symbol routines can just return an error.  */
-#define binary_get_symtab_upper_bound _bfd_nosymbols_get_symtab_upper_bound
-#define binary_get_symtab _bfd_nosymbols_get_symtab
+#define	binary_close_and_cleanup _bfd_generic_close_and_cleanup
+#define binary_bfd_free_cached_info _bfd_generic_bfd_free_cached_info
+#define binary_new_section_hook _bfd_generic_new_section_hook
+
 #define binary_print_symbol _bfd_nosymbols_print_symbol
-#define binary_get_symbol_info _bfd_nosymbols_get_symbol_info
-#define binary_bfd_is_local_label _bfd_nosymbols_bfd_is_local_label
+#define binary_bfd_is_local_label bfd_generic_is_local_label
 #define binary_get_lineno _bfd_nosymbols_get_lineno
 #define binary_find_nearest_line _bfd_nosymbols_find_nearest_line
 #define binary_bfd_make_debug_symbol _bfd_nosymbols_bfd_make_debug_symbol
 
+#define binary_get_reloc_upper_bound \
+  ((long (*) PARAMS ((bfd *, asection *))) bfd_0l)
+#define binary_canonicalize_reloc \
+  ((long (*) PARAMS ((bfd *, asection *, arelent **, asymbol **))) bfd_0l)
+#define binary_bfd_reloc_type_lookup _bfd_norelocs_bfd_reloc_type_lookup
+
+#define binary_bfd_get_relocated_section_contents \
+  bfd_generic_get_relocated_section_contents
+#define binary_bfd_relax_section bfd_generic_relax_section
+#define binary_bfd_link_hash_table_create _bfd_generic_link_hash_table_create
+#define binary_bfd_link_add_symbols _bfd_generic_link_add_symbols
+#define binary_bfd_final_link _bfd_generic_final_link
+
 /* We do have to provide a routine to make an empty symbol.  */
 
 static asymbol *
@@ -108,6 +128,164 @@
   return _bfd_generic_set_section_contents (abfd, sec, data, offset, size);
 }
 
+/* Check whether an existing file is a binary file.
+   Pretty easy - _every_ file is as far as we're concerned. :-)
+   However, only "recognize" the file
+   if the input target was explicitly set to "binary",
+   not if we're doing an automatic target search.  */
+
+static const bfd_target *
+binary_object_p (abfd)
+     bfd *abfd;
+{
+  struct stat statbuf;
+
+  if (abfd->target_defaulted)
+    return NULL;
+
+  abfd->symcount = BIN_SYMS;
+
+  /* Find the file size.  */
+  if (bfd_stat (abfd, &statbuf) < 0)
+    return NULL;
+
+  /* One data section.  */
+  {
+    asection *sec;
+    char *secname;
+
+    secname = (char *) bfd_alloc (abfd, strlen (".data") + 1);
+    strcpy (secname, ".data");
+    sec = bfd_make_section (abfd, secname);
+    if (sec == NULL)
+      return NULL;
+    sec->flags = SEC_ALLOC | SEC_LOAD | SEC_DATA | SEC_HAS_CONTENTS;
+    sec->vma = 0;
+    sec->_raw_size = statbuf.st_size;
+    sec->filepos = 0;
+
+    abfd->tdata.any = (PTR)sec;
+  }
+
+  return abfd->xvec;
+}
+
+/* Get the contents of "the" section.  */
+
+static boolean
+binary_get_section_contents (abfd, section, location, offset, count)
+     bfd *abfd;
+     asection *section;
+     PTR location;
+     file_ptr offset;
+     bfd_size_type count;
+{
+  if ((bfd_seek (abfd, offset, SEEK_SET) != 0)
+      || (bfd_read (location, 1, count, abfd) != count))
+    return false;
+  return true;
+}
+
+/* Return the amount of memory needed to read the symbol table.  */
+
+static long
+binary_get_symtab_upper_bound (abfd)
+     bfd *abfd;
+{
+  return (BIN_SYMS + 1) * sizeof (asymbol *);
+}
+
+void
+binary_get_symbol_info (ignore_abfd, symbol, ret)
+     bfd *ignore_abfd;
+     asymbol *symbol;
+     symbol_info *ret;
+{
+  bfd_symbol_info (symbol, ret);
+}
+
+/* Create a symbol name based on the bfd's filename.  */
+static char *mangle_name(abfd, suffix)
+     bfd *abfd;
+     char *suffix;
+{
+  int size = strlen(bfd_get_filename(abfd)) + strlen(suffix) + 10;
+  char *buf = (char*) bfd_alloc (abfd, size);
+  char *p;
+
+  if (buf == NULL)
+    {
+      bfd_set_error (bfd_error_no_memory);
+      return false;
+    }
+
+  sprintf(buf, "_binary_%s_%s", bfd_get_filename(abfd), suffix);
+
+  /* Change any non-alphanumeric characters to underscores.  */
+  for (p = buf; *p; p++)
+    if (!isalnum(*p))
+      *p = '_';
+
+  return buf;
+}
+
+/* Return the symbol table.  */
+
+static long
+binary_get_symtab (abfd, alocation)
+     bfd *abfd;
+     asymbol **alocation;
+{
+  asection *sec = (asection*)abfd->tdata.any;
+  asymbol *syms;
+  unsigned int i;
+
+  syms = (asymbol *) bfd_alloc (abfd, BIN_SYMS * sizeof (asymbol));
+  if (syms == NULL)
+    {
+      bfd_set_error (bfd_error_no_memory);
+      return false;
+    }
+
+  /* Start symbol.  */
+  syms[0].the_bfd = abfd;
+  syms[0].name = mangle_name(abfd, "start");
+  syms[0].value = 0;
+  syms[0].flags = BSF_GLOBAL;
+  syms[0].section = sec;
+  syms[0].udata.p = NULL;
+
+  /* End symbol.  */
+  syms[1].the_bfd = abfd;
+  syms[1].name = mangle_name(abfd, "end");
+  syms[1].value = sec->_raw_size;
+  syms[1].flags = BSF_GLOBAL;
+  syms[1].section = sec;
+  syms[1].udata.p = NULL;
+
+  /* End symbol.  */
+  syms[2].the_bfd = abfd;
+  syms[2].name = mangle_name(abfd, "size");
+  syms[2].value = sec->_raw_size;
+  syms[2].flags = BSF_GLOBAL;
+  syms[2].section = bfd_abs_section_ptr;
+  syms[2].udata.p = NULL;
+
+  for (i = 0; i < BIN_SYMS; i++)
+    *alocation++ = syms++;
+  *alocation = NULL;
+
+  return BIN_SYMS;
+}
+
+static int
+binary_sizeof_headers (abfd, exec)
+     bfd *abfd;
+     boolean exec;
+{
+  return 0;
+}
+
 const bfd_target binary_vec =
 {
   "binary",			/* name */
@@ -129,7 +307,7 @@
   bfd_getb16, bfd_getb_signed_16, bfd_putb16,	/* hdrs */
   {				/* bfd_check_format */
     _bfd_dummy_target,
-    _bfd_dummy_target,
+    binary_object_p,		/* bfd_check_format */
     _bfd_dummy_target,
     _bfd_dummy_target,
   },
@@ -146,14 +324,14 @@
     bfd_false,
   },
 
-  BFD_JUMP_TABLE_GENERIC (_bfd_generic),
+  BFD_JUMP_TABLE_GENERIC (binary),
   BFD_JUMP_TABLE_COPY (_bfd_generic),
   BFD_JUMP_TABLE_CORE (_bfd_nocore),
   BFD_JUMP_TABLE_ARCHIVE (_bfd_noarchive),
   BFD_JUMP_TABLE_SYMBOLS (binary),
-  BFD_JUMP_TABLE_RELOCS (_bfd_norelocs),
+  BFD_JUMP_TABLE_RELOCS (binary),
   BFD_JUMP_TABLE_WRITE (binary),
-  BFD_JUMP_TABLE_LINK (_bfd_nolink),
+  BFD_JUMP_TABLE_LINK (binary),
   BFD_JUMP_TABLE_DYNAMIC (_bfd_nodynamic),
 
   NULL
diff -ur gas-950226/include/opcode/ChangeLog gas-950226-new/include/opcode/ChangeLog
--- gas-950226/include/opcode/ChangeLog	Sun Feb 26 08:20:21 1995
+++ gas-950226-new/include/opcode/ChangeLog	Mon Feb 27 08:44:01 1995
@@ -1,3 +1,7 @@
+Mon Feb 27 08:36:39 1995  Bryan Ford  <baford@cs.utah.edu>
+
+	* i386.h: added missing Data16/Data32 flags to a few instructions.
+
 Fri Feb 24 19:13:37 1995  Ian Lance Taylor  <ian@cygnus.com>
 
 	* mips.h (M_DLA_AB, M_DLI): Define.
diff -ur gas-950226/include/opcode/i386.h gas-950226-new/include/opcode/i386.h
--- gas-950226/include/opcode/i386.h	Mon Feb  6 12:00:43 1995
+++ gas-950226-new/include/opcode/i386.h	Mon Feb 27 08:32:07 1995
@@ -101,6 +101,8 @@
 {"sahf", 0, 0x9e, _, NoModrm, { 0, 0, 0} },
 {"pushf", 0, 0x9c, _, NoModrm|Data32, { 0, 0, 0} },
 {"popf", 0, 0x9d, _, NoModrm|Data32, { 0, 0, 0} },
+{"pushfl", 0, 0x9c, _, NoModrm|Data32, { 0, 0, 0} },
+{"popfl", 0, 0x9d, _, NoModrm|Data32, { 0, 0, 0} },
 {"pushfw", 0, 0x9c, _, NoModrm|Data16, { 0, 0, 0} },
 {"popfw", 0, 0x9d, _, NoModrm|Data16, { 0, 0, 0} },
 {"stc", 0, 0xf9, _, NoModrm, { 0, 0, 0} },
@@ -280,8 +282,10 @@
 {"lret", 1, 0xca, _, NoModrm|Data32, { Imm16, 0, 0} },
 {"lretw", 0, 0xcb, _, NoModrm|Data16, { 0, 0, 0} },
 {"lretw", 1, 0xca, _, NoModrm|Data16, { Imm16, 0, 0} },
-{"enter", 2, 0xc8, _, NoModrm, { Imm16, Imm8, 0} },
-{"leave", 0, 0xc9, _, NoModrm, { 0, 0, 0} },
+{"enter", 2, 0xc8, _, NoModrm|Data32, { Imm16, Imm8, 0} },
+{"leave", 0, 0xc9, _, NoModrm|Data32, { 0, 0, 0} },
+{"enterw", 2, 0xc8, _, NoModrm|Data16, { Imm16, Imm8, 0} },
+{"leavew", 0, 0xc9, _, NoModrm|Data16, { 0, 0, 0} },
 
 /* conditional jumps */
 {"jo", 1, 0x70, _, Jump, { Disp, 0, 0} },






From hjl@nynexst.com  Mon Feb 27 17:02:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 27 Feb 1995 17:02:00 -0000
Subject: ss-950222 has trouble with PIC in ELF
Message-ID: <9502280003.AA17871@titanic.nynexst.com>

Hi,

I have been trying to compile the shared ELF Linux C library with
gas-9502222 unsuccessfully. It seems that gas in gas-9502222 outputs
some weird object files given the same asm source files. But I couldn't
pinpoint which files were misassembled. It may be related to my
last PIC/ELF bug report.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From ian@cygnus.com  Mon Feb 27 21:39:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 27 Feb 1995 21:39:00 -0000
Subject: elf.sc and shared library for binutils
References: <199502271454.JAA00408@tiktok.cygnus.com>
Message-ID: <9502280539.AA27346@tweedledumb.cygnus.com>

   From: Mike Meissner <meissner@cygnus.com>
   Date: Mon, 27 Feb 1995 09:54:13 -0500

   If you don't do this, each program will be one physical page larger,
   since the pages in the data area would start on a new page, leaving a
   hole in the program file as it exists on disk between the text and
   data.

The linker already does this.  The issue at hand is more subtle.  It
is how to handle a program whose text segment ends precisely on a page
boundary.  Ideally the data segment should start on the next page,
immediately following the text segment.  Currently the linker will
skip a page, wasting a page of virtual memory address space.  Fixing
this is complex; see the comment in ld/scripttempl/elf.sc.

Ian



From hjl@nynexst.com  Mon Feb 27 22:20:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 27 Feb 1995 22:20:00 -0000
Subject: The new x86 gas in binutils.
Message-ID: <9502280612.AA18703@titanic.nynexst.com>

Hi,

I have been trying to compile the new binutils snapshot under Linux
for a while now. I am usung gas-950222. I have found the following
things:

1. Some 16 bit supports were added to the binutils. Some assembly
   codes in the Linux C library had to be modified to assembler.
   One example is I had to change "popfl" to just "popf". There
   may be more in the Linux kernel code. I am not sure if that is
   a feature or a bug :-(.
2. The new binutils are very unstable for ELF with PIC. I couldn't
   use gas/ld in gas-950222 to make a shared Linux C library in
   ELF. I had to go back to my private version, 2.5.2.7.

I am afraid the current new binutils are not usable for Linux and
once when they get fixed some asm code in the Linux kernel may
have to be modified.



-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From davem@caip.rutgers.edu  Sat Mar  4 15:05:00 1995
From: davem@caip.rutgers.edu (David S. Miller)
Date: Sat, 04 Mar 1995 15:05:00 -0000
Subject: Binutils-2.5.2 on SGI-irix4
Message-ID: <199503042305.SAA29569@firefox.rutgers.edu>

A local friend provided this bug report for me.  I hope you find it
useful in some way.

----------------------------------------------------------------
Date: Sat, 4 Mar 1995 17:57:09 -0500
From: Adrian Rodriguez <adrian@romulus.rutgers.edu>

You may want to pass this on to your friends at Cygnus.

Software:    Binutils 2.5.2
Source:      ftp://prep.ai.mit.edu/pub/gnu/binutils-2.5.2.tar.gz
Host:        SGI Indigo
OS:          Irix 4.0.5F
Bug:         configure forces use of cc
Description:
   It appears that there is no way to use gcc to build binutils short of
   changing the definition of CC in binutils-2.5.2/config/mh-irix4.  The
   configure script provided ignores the environment variable CC and the
   command line options --with-gcc and --with-gnu-c.  Binutils will not
   build with the version of SGI's C compiler on this machine.  I want to
   do this because SGI's compiler barfs on targ-cpu.c with errors I can
   provide if you are interested.



From hjl@nynexst.com  Mon Mar  6 06:15:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 06 Mar 1995 06:15:00 -0000
Subject: Patches for i386.h in the gas snapshot
Message-ID: <9503050450.AA09502@titanic.nynexst.com>

Hi,

Does it look ok?

H.J.
-----
Forwarded message:
>From owner-gcc@vger.rutgers.edu Tue Feb 28 02:37:11 1995
Message-Id: <m0rjLwm-0002WkC@sunny>
From: alan@spri.levels.unisa.edu.au (Alan Modra)
Subject: Re: The new x86 gas in binutils.
To: hjl@nynexst.com (H.J. Lu)
Date: Tue, 28 Feb 1995 17:32:15 +1030 (CST)
Cc: raeburn@cygnus.com (Ken Raeburn), linux-gcc@vger.rutgers.edu
In-Reply-To: < 9502280612.AA18703@titanic.nynexst.com > from "H.J. Lu" at Feb 28, 95 01:18:13 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 1831      
Sender: owner-gcc@vger.rutgers.edu
Precedence: bulk

> 
> Hi,
> 
> I have been trying to compile the new binutils snapshot under Linux
> for a while now. I am usung gas-950222. I have found the following
> things:
> 
> 1. Some 16 bit supports were added to the binutils. Some assembly
>    codes in the Linux C library had to be modified to assembler.
>    One example is I had to change "popfl" to just "popf". There
>    may be more in the Linux kernel code. I am not sure if that is
>    a feature or a bug :-(.

Try the following.  It fixes the push/pop problem.

diff -ur gas-950214/include/opcode/i386.h ./include/opcode/i386.h
--- gas-950214/include/opcode/i386.h	Thu Feb 16 09:58:43 1995
+++ ./include/opcode/i386.h	Wed Feb 15 14:09:09 1995
@@ -99,10 +99,12 @@
 {"cmc", 0, 0xf5, _, NoModrm, { 0, 0, 0} },
 {"lahf", 0, 0x9f, _, NoModrm, { 0, 0, 0} },
 {"sahf", 0, 0x9e, _, NoModrm, { 0, 0, 0} },
-{"pushf", 0, 0x9c, _, NoModrm|Data32, { 0, 0, 0} },
-{"popf", 0, 0x9d, _, NoModrm|Data32, { 0, 0, 0} },
+{"pushfl", 0, 0x9c, _, NoModrm|Data32, { 0, 0, 0} },
+{"popfl", 0, 0x9d, _, NoModrm|Data32, { 0, 0, 0} },
 {"pushfw", 0, 0x9c, _, NoModrm|Data16, { 0, 0, 0} },
 {"popfw", 0, 0x9d, _, NoModrm|Data16, { 0, 0, 0} },
+{"pushf", 0, 0x9c, _, NoModrm, { 0, 0, 0} },
+{"popf", 0, 0x9d, _, NoModrm, { 0, 0, 0} },
 {"stc", 0, 0xf9, _, NoModrm, { 0, 0, 0} },
 {"std", 0, 0xfd, _, NoModrm, { 0, 0, 0} },
 {"sti", 0, 0xfb, _, NoModrm, { 0, 0, 0} },


> 2. The new binutils are very unstable for ELF with PIC. I couldn't
>    use gas/ld in gas-950222 to make a shared Linux C library in
>    ELF. I had to go back to my private version, 2.5.2.7.
> 
> I am afraid the current new binutils are not usable for Linux and
> once when they get fixed some asm code in the Linux kernel may
> have to be modified.
> 
> 
> 
> -- 
> H.J. Lu
> NYNEX Science and Technology, Inc.			hjl@nynexst.com
> 



-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From hjl@nynexst.com  Mon Mar  6 06:15:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 06 Mar 1995 06:15:00 -0000
Subject: Patches to build a shared ELF libbfd.so
Message-ID: <9503051555.AA10263@titanic.nynexst.com>

Hi,

I have a patch for gas-950304 to build a shared ELF library,
libbfd.so, which contains both libbfd and libopcode. It cuts
down the sizes of each ELF binary by several hundred Ks on x86.

But my patch is just a hack since there is no shared library
support in binutils. If anyone is interested, I will post
my patch. BTW, I think it is a very good test for the ELF
support in binutils if you use the binutils to assembler
and link itself.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From meissner@cygnus.com  Mon Mar  6 06:55:00 1995
From: meissner@cygnus.com (Mike Meissner)
Date: Mon, 06 Mar 1995 06:55:00 -0000
Subject: Patches to build a shared ELF libbfd.so
References: <9503051555.AA10263@titanic.nynexst.com> <9503051555.AA10263@titanic.nynexst.com>
Message-ID: <199503061455.JAA01039@tiktok.cygnus.com>

| Hi,
| 
| I have a patch for gas-950304 to build a shared ELF library,
| libbfd.so, which contains both libbfd and libopcode. It cuts
| down the sizes of each ELF binary by several hundred Ks on x86.
| 
| But my patch is just a hack since there is no shared library
| support in binutils. If anyone is interested, I will post
| my patch. BTW, I think it is a very good test for the ELF
| support in binutils if you use the binutils to assembler
| and link itself.

As I recall, this was discussed last summer.  The problem with making
bfd a shared library is that the interfaces aren't as cut and dried as
one would like.  For example, when I was at OSF, we tried to shared
gdb's bfd with gas/ld in the OSF ODE build evironment.  However,
because we had not rev'ed GDB for awhile, the calling sequence for the
disassembling functions had changed, even though the name was the
same.  In the interest of expediency, I kept gdb's version of bfd in
the tree along with the assembler and linkers.

-- 
Michael Meissner, Cygnus Support (East Coast)
Suite 105, 48 Grove Street, Somerville, MA 02144, USA
meissner@cygnus.com,	617-629-3016 (office),	617-629-3010 (fax)



From hjl@nynexst.com  Mon Mar  6 07:04:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 06 Mar 1995 07:04:00 -0000
Subject: Patches to build a shared ELF libbfd.so
References: <199503061455.JAA01039@tiktok.cygnus.com>
Message-ID: <9503061456.AA12598@titanic.nynexst.com>

> 
> | Hi,
> | 
> | I have a patch for gas-950304 to build a shared ELF library,
> | libbfd.so, which contains both libbfd and libopcode. It cuts
> | down the sizes of each ELF binary by several hundred Ks on x86.
> | 
> | But my patch is just a hack since there is no shared library
> | support in binutils. If anyone is interested, I will post
> | my patch. BTW, I think it is a very good test for the ELF
> | support in binutils if you use the binutils to assembler
> | and link itself.
> 
> As I recall, this was discussed last summer.  The problem with making
> bfd a shared library is that the interfaces aren't as cut and dried as

That is one reason why I said "there is no shared library support in
binutils." :-(.

> one would like.  For example, when I was at OSF, we tried to shared
> gdb's bfd with gas/ld in the OSF ODE build evironment.  However,
> because we had not rev'ed GDB for awhile, the calling sequence for the
> disassembling functions had changed, even though the name was the
> same.  In the interest of expediency, I kept gdb's version of bfd in
> the tree along with the assembler and linkers.
> 

Drop me a line if you are interested in fixing it. Hint: proper use of
bfd/VERSION and -soname.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From ian@cygnus.com  Mon Mar  6 07:42:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 06 Mar 1995 07:42:00 -0000
Subject: Patches to build a shared ELF libbfd.so
References: <9503051555.AA10263@titanic.nynexst.com>
Message-ID: <199503061542.KAA00014@sanguine.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Sun, 5 Mar 95 11:01:29 EST

   BTW, I think it is a very good test for the ELF
   support in binutils if you use the binutils to assembler
   and link itself.

These are part of the standard tests of the assembler and linker,
incidentally, for those who are interested in running them.

In gas, do ``make bootstrap''.  CC must run gcc.  This runs a three
stage bootstrap.

In ld, do ``make check''.  You must have DejaGnu installed.  This runs
various tests, including three stage bootstraps using various
different options, and several shared library checks.

I run these tests regularly on ELF, and other, systems.

Ian



From hjl@nynexst.com  Mon Mar  6 20:32:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 06 Mar 1995 20:32:00 -0000
Subject: ld -V against LDEMULATION
References: <9503062131.AA14741@gnu.mc.xerox.com>
Message-ID: <9503070423.AA18283@titanic.nynexst.com>

> 
> 
> In binutils 2.5.2.7 (the Linux elf release)
> 
> If you specifiy LDEMULATION wrong, then try to
> do a ld -V, you get nothing...
> 
> ld -V should always print something useful.
> 
> leisner@thingy$ export LDEMULATION=i386_elf
> leisner@thingy$ ld -V
> ld: unrecognised emulation mode: i386_elf
> leisner@thingy$ ld -V
> ld: unrecognised emulation mode: i386_elf
> leisner@thingy$ unset LDEMULATION
> leisner@thingy$ ld -V
> ld version 2.5.2.7 (with BFD 2.5)
>   Supported emulations:
>    i386linux 
>    elf_i386 
>    i386aout 
>    i386bsd 
>    i386coff 
>    i386mach 
> leisner@thingy$ LDEMULATION=elf_i386
> leisner@thingy$ ld -V
> ld version 2.5.2.7 (with BFD 2.5)
>   Supported emulations:
>    i386linux 
>    elf_i386 
>    i386aout 
>    i386bsd 
>    i386coff 
>    i386mach 
> leisner@thingy$ 
> 
> 
> 
> marty		leisner@sdsp.mc.xerox.com   
> Member of the League for Programming Freedom ( http://www.lpf.org )
> Any sufficiently advanced technology is indistinguishable from magic
>         Arthur C. Clarke, The Lost Worlds of 2001
> 

Please apply this patch. It will be included in the next Linux version
if it is not in the snapshot.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
-----
===================================================================
RCS file: /home/cvs/gnu/binutils/ld/ldmain.c,v
retrieving revision 1.1.1.2
diff -c -r1.1.1.2 ldmain.c
*** 1.1.1.2	1995/02/22 02:02:32
--- ldmain.c	1995/03/07 04:27:40
***************
*** 353,358 ****
--- 353,359 ----
       char **argv;
  {
    char *emulation;
+   ld_emulation_xfer_type **ptr;
    int i;
  
    emulation = (char *) getenv (EMULATION_ENVIRON);
***************
*** 402,408 ****
  	}
      }
  
!   return emulation;
  }
  
  /* If directory DIR contains an "ldscripts" subdirectory,
--- 403,419 ----
  	}
      }
  
!   /* Check if emulation is valid. */
!   for (ptr = ld_emulations; *ptr; ptr++)
!   {
!     if (!strcmp (emulation, (*ptr)->emulation_name))
!     {
!       return emulation;
!     }
!   }
!   einfo("%P: unknown emulation: `%s'\n", emulation); 
!   ldversion (1);
!   xexit (1);
  }
  
  /* If directory DIR contains an "ldscripts" subdirectory,



From John_Atkinson@NeXT.COM  Wed Mar  8 12:53:00 1995
From: John_Atkinson@NeXT.COM (John Atkinson)
Date: Wed, 08 Mar 1995 12:53:00 -0000
Subject: subscribe
Message-ID: <9503082053.AA21683@oz.NeXT.COM>

Hello:

I am working on gas for our Portable Distributed Objects system.   
We are currently using gas-2.3 but I have run into some problems  
under hp/ux, which require the fixes in the latest snapshot.  Also,  
I have some mods to support quoted the use of quoted labels which  
could be integrated into the latest source.  Therefore, may I  
subscribe to this mailing list, and could someone instruct me on how  
to pick up the current snapshot.

	Thanks,

	John C. Atkinson

Begin forwarded message:

To: John Atkinson <John_Atkinson@NeXT.COM>
Subject: Re: hppa setjmp clobbers float registers in 2.6.3
Reply-To: law@cs.utah.edu
In-Reply-To: Your message of Wed, 08 Mar 95 11:51:05 PST.  
<9503081951.AA20427@oz.NeXT.COM>
Date: Wed, 08 Mar 95 12:53:10 MST
From: Jeffrey A Law <law@snake.cs.utah.edu>

  In message <9503081951.AA20427@oz.NeXT.COM> you write:
  > Wuold you point me to the appropriate ftp site to pick this up?  I  
  > have ss-950305 but that does not have any gas source.
You'll need to get on the gas2 developers list.  gas2@cygnus.com.

JEff



From raeburn@cygnus.com  Wed Mar  8 15:24:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Wed, 08 Mar 1995 15:24:00 -0000
Subject: subscribe
References: <9503082053.AA21683@oz.NeXT.COM>
Message-ID: <9503082324.AA02611@cujo.cygnus.com>

To pick up the latest snapshot, ftp to ftp.cygnus.com, log in as
"anonymous" or "ftp", and cd to "private/gas".  In there you'll find
the recent daily and weekly snapshots and diffs.

To get onto the mailing list, send to gas2-request@cygnus.com.

Ken



From hjl@nynexst.com  Mon Mar 13 13:17:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 13 Mar 1995 13:17:00 -0000
Subject: A patch for gas-950313
Message-ID: <9503132109.AA27504@titanic.nynexst.com>

There are two patches. One fixed a bug for SunOS. The other added the
SunOS style of searching .so files to ELF.

-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
---
*** sunos.em.orig	Fri Dec  2 17:25:52 1994
--- sunos.em	Mon Mar 13 16:00:59 1995
***************
*** 116,121 ****
--- 116,123 ----
      len = strlen (filename);
    else
      {
+       /* Get the major number */
+       force_maj = strtoul (dot [1], NULL, 10);
        len = dot - filename;
        alc = (char *) alloca (len + 1);
        strncpy (alc, filename, len);
*** elf32.em.orig	Mon Mar 13 08:35:46 1995
--- elf32.em	Mon Mar 13 16:01:02 1995
***************
*** 43,48 ****
--- 43,55 ----
  #include "ldlang.h"
  #include "ldgram.h"
  
+  
+ /* FIXME: On some hosts we will need to include a different file.
+    This is correct for ELF/SVR4, which is the only place this file will
+    typically be compiled.  However, if somebody configures the linker
+    for all targets, they will run into trouble here.  */
+ #include <dirent.h>
+ 
  static void gld${EMULATION_NAME}_before_parse PARAMS ((void));
  static boolean gld${EMULATION_NAME}_open_dynamic_archive
    PARAMS ((const char *, lang_input_statement_type *));
***************
*** 63,68 ****
--- 70,220 ----
    config.dynamic_link = ${DYNAMIC_LINK-true};
  }
  
+ /* Try to open a BFD for a lang_input_statement.  */
+ 
+ static boolean
+ try_open_bfd (attempt, entry)
+      const char *attempt;
+      lang_input_statement_type *entry;
+ {
+   entry->the_bfd = bfd_openr (attempt, entry->target);
+ 
+   if (trace_file_tries)
+     info_msg ("attempt to open %s %s\n", attempt,
+ 	      entry->the_bfd == NULL ? "failed" : "succeeded");
+ 
+   if (entry->the_bfd != NULL)
+     return true;
+   else
+     return false;
+ }
+ 
+ /* Search for and open the .so file specified by ENTRY. */
+ 
+ static boolean
+ gld${EMULATION_NAME}_find_so (entry)
+      lang_input_statement_type *entry;
+ {
+   search_dirs_type *search;
+   int max_maj, max_min, max_patch;
+   int force_maj;
+   const char *filename;
+   const char *dot;
+   char *alc;
+   unsigned int len;
+ #ifndef PATH_MAX
+ #ifdef MAXPATHLEN
+ #define PATH_MAX MAXPATHLEN
+ #else
+ #define PATH_MAX 1024
+ #endif
+ #endif
+   char string [PATH_MAX + 4];
+   char found [PATH_MAX + 4];
+ 
+   force_maj = -1;
+   filename = entry->filename;
+   dot = strchr (filename, '.');
+   if (dot == NULL)
+     len = strlen (filename);
+   else
+   {
+     /* Get the major number */
+     force_maj = strtoul (dot [1], NULL, 10);
+     len = dot - filename;
+     alc = (char *) alloca (len + 1);
+     strncpy (alc, filename, len);
+     alc[len] = '\0';
+     filename = alc;
+   }
+ 
+   found [0] = '\0';
+   max_maj = max_min = max_patch = 0;
+   for (search = search_head;
+        search != (search_dirs_type *)NULL;
+        search = search->next) 
+     {
+       DIR *dir;
+       struct dirent *ent;
+ 
+       /* No forced major release number. */
+       if (dot == NULL)
+       {
+ 	sprintf (string, "%s/lib%s.so", search->name, filename);
+ 
+ 	/* First try the straight .so file. */
+ 	if (try_open_bfd (string, entry))
+ 	{
+ 	  entry->filename = strdup (string);
+ 	  return true;
+ 	}
+       }
+ 
+       /* Then we try the fancy ones. */
+       dir = opendir (search->name);
+       if (dir == NULL)
+ 	continue;
+ 
+       while ((ent = readdir (dir)) != NULL)
+       {
+ 	int found_maj, found_min, found_patch;
+ 
+ 	/* We are looking for libxxxx.so.x.x.x and not libxxxx.so. */
+ 	if (ent->d_name [6 + len] == '\0'
+ 	    || strncmp (ent->d_name, "lib", 3) != 0
+ 	    || strncmp (ent->d_name + 3, filename, len) != 0
+ 	    || strncmp (ent->d_name + 3 + len, ".so", 3) != 0)
+ 	  continue;
+ 
+ 	/* We've found a .so.x.x.x file. Work out the major, minor and 
+ 	   patch numbers. */
+ 	found_maj = found_min = found_patch = 0;
+ 	if (sscanf (ent->d_name + 3 + len, ".so.%d.%d.%d",
+ 		&found_maj, &found_min, &found_patch) <= 0)
+ 	  continue;
+ 
+ 	if (force_maj != -1 && force_maj != found_maj)
+ 	  continue;
+ 
+ 	/* We've found a match for the name we are searching for.
+ 	   See if this is the version we should use. */
+ 	if (found [0] == '\0' || (found_maj > max_maj)
+ 	    || (found_maj == max_maj
+ 		&& (found_min > max_min
+ 		    || (found_min == max_min
+ 			&& found_patch > max_patch))))
+ 	{
+ 	  strcpy (found, ent->d_name);
+ 	  max_maj = found_maj;
+ 	  max_min = found_min;
+ 	  max_patch = found_patch;
+ 	}
+       }
+ 
+       closedir (dir);
+ 
+       if (found [0] != '\0')
+       {
+         /* Give it a try */
+ 	sprintf (string, "%s/%s", search->name, found);
+ 
+ 	if (try_open_bfd (string, entry))
+ 	{
+ 	  entry->filename = strdup (string);
+ 	  return true;
+ 	}
+ 	else
+ 	{
+ 	  /* We have to start all over again. */
+ 	  found [0] = '\0';
+ 	  max_maj = max_min = max_patch = 0;
+ 	}
+       }
+     }
+ 
+   return false;
+ }
+ 
  /* Try to open a dynamic archive.  This is where we know that ELF
     dynamic libraries have an extension of .so.  */
  
***************
*** 75,81 ****
  
    filename = entry->filename;
  
!   if (! ldfile_open_file_search (arch, entry, "lib", ".so"))
      return false;
  
    /* We have found a dynamic object to include in the link.  The ELF
--- 227,233 ----
  
    filename = entry->filename;
  
!   if (! gld${EMULATION_NAME}_find_so (entry))
      return false;
  
    /* We have found a dynamic object to include in the link.  The ELF



From eric@aib.com  Mon Mar 13 15:18:00 1995
From: eric@aib.com (Eric Youngdale)
Date: Mon, 13 Mar 1995 15:18:00 -0000
Subject: A patch for gas-950313
References: <9503132109.AA27504@titanic.nynexst.com>
Message-ID: <9503132245.ZM5372@aib.com>

>There are two patches. One fixed a bug for SunOS. The other added
the
>SunOS style of searching .so files to ELF.

	I must have missed something.  Why do we want SunOS style
library searching built into the linker in the first place?

-Eric

-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."



From jbrooks@ea.com  Tue Mar 14 14:38:00 1995
From: jbrooks@ea.com (Brooks, John)
Date: Tue, 14 Mar 1995 14:38:00 -0000
Subject: Warning about backwards Orgs
Message-ID: <2F661AC6@pcsmtp.ea.com>

    I have a patch for gas (made to the version released with 
binutils-2.5.2) which displays a warning when an Org fails (due to trying
to org backwards).

    I am unfamiliar with patch submission protocol, but the patch follows
for those who are interested:


FILE:      write.c
FUNCTION:  cvt_frag_to_fill


ORIGINAL CODE:

    case rs_org:
#ifdef HANDLE_ALIGN
      HANDLE_ALIGN (fragP);
#endif
      fragP->fr_type = rs_fill;
      know (fragP->fr_next != NULL);


PATCHED CODE:

    case rs_org:
#ifdef HANDLE_ALIGN
      HANDLE_ALIGN (fragP);
#endif
      know (fragP->fr_next != NULL);
   if ( fragP->fr_type == rs_org)
   {
   if ( fragP->fr_offset < fragP->fr_next->fr_address)
    as_warn ("Org failed! Org address changed from 0x%08X to 0x%08X\n",
       fragP->fr_offset, fragP->fr_next->fr_address);
   }
      fragP->fr_type = rs_fill;


-----------------------------------------------------------------------
John Brooks                                      email:  jbrooks@ea.com 
Technical Director - Coin-Op Division            Phone:  415-513-7736
Electronic Arts                                  Fax:    
415-513-7449



From raeburn@cygnus.com  Tue Mar 14 15:08:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Tue, 14 Mar 1995 15:08:00 -0000
Subject: Warning about backwards Orgs
Message-ID: <9503142308.AA13562@cujo.cygnus.com>

The best way to submit a patch is with the UNIX "diff" utility -- make
"context" or "unified" diffs, which note exactly which lines are
changed, old versions and new, as well as the surrounding context --
and to base your changes on a recent snapshot of the development
version on ftp.cygnus.com in ~ftp/private/gas.

In this case, your "original code" section doesn't match what's in the
current sources, so I have to do a bit more work to integrate your
changes with the other changes that have taken place in that code.
This is a small piece of code, though, so it's not that much work.  I
have to shut down my workstation momentarily, but I should be able to
look at it more closely later.

Ken



From hjl@nynexst.com  Thu Mar 16 19:36:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Thu, 16 Mar 1995 19:36:00 -0000
Subject: How to fix the ELF linker?
Message-ID: <9503170327.AA13718@titanic.nynexst.com>

Hi,

When you do

# gcc foo.c -lc

the ELF linker will load libc.so twice. But the dynamic linker will
only map libc.so into the address space once. The prolem comes
up if the ELF linker uses both instances of libc.so to resolve
the references. Some symbols may be referenced from the second libc.so.
That causes some trouble for Linux/ELF with the latest shared ELF
C library. The old libraries work fine. I don't know how the
ELF linker determines which libc.so to use for symbols. I have
checked that you seem to be able to just use one -lfoo if libfoo
is a shared library. I am not sure what the right fix is. I can
image the followings:

1. Before loading a shared library always check if it has been
   loaded before. Or
2. Always use the same shared library for symbols.

Any ideas?

Thanks.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From hjl@nynexst.com  Thu Mar 16 20:13:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Thu, 16 Mar 1995 20:13:00 -0000
Subject: More info on the ELF linker
Message-ID: <9503170404.AA13978@titanic.nynexst.com>

Hi,

It look like two symobls, ___brk_addr and __fpu_control, referenced
by crt1.o got corrupted. They are the only symbols in the .dynbss
section.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From rms@gnu.ai.mit.edu  Fri Mar 17 00:10:00 1995
From: rms@gnu.ai.mit.edu (Richard Stallman)
Date: Fri, 17 Mar 1995 00:10:00 -0000
Subject: How to fix the ELF linker?
References: <9503170327.AA13718@titanic.nynexst.com>
Message-ID: <199503170810.DAA06499@mole.gnu.ai.mit.edu>

Linking in a shared library really always loads the whole library.
So if anything subsequently linked refers to any symbols from the
shared library, it ought to be resolved with the copy of the library
that was already linked.

So linking the same shared library a second time might as well be
a no-op.



From hjl@nynexst.com  Fri Mar 17 06:31:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Fri, 17 Mar 1995 06:31:00 -0000
Subject: How to fix the ELF linker?
References: <199503170810.DAA06499@mole.gnu.ai.mit.edu>
Message-ID: <9503171422.AA15591@titanic.nynexst.com>

> 
> Linking in a shared library really always loads the whole library.
> So if anything subsequently linked refers to any symbols from the
> shared library, it ought to be resolved with the copy of the library
> that was already linked.
> 
> So linking the same shared library a second time might as well be
> a no-op.
> 

The ld in gas-950313 will load the same shared library twice. Has
anyone worked on it? If noone does, I may take a shot at it. I
don't know if my fix will be correct or not since I am not that
familiar with ld and bfd. BTW, I have some simple code which checks
if a shared library is already loaded or not. But I don't know how
to skip the second one. It seems to need changes in many places.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From ian@cygnus.com  Fri Mar 17 08:50:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Fri, 17 Mar 1995 08:50:00 -0000
Subject: How to fix the ELF linker?
References: <9503170327.AA13718@titanic.nynexst.com>
Message-ID: <199503171650.LAA01210@sanguine.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Thu, 16 Mar 95 22:35:08 EST

   When you do

   # gcc foo.c -lc

   the ELF linker will load libc.so twice. But the dynamic linker will
   only map libc.so into the address space once. The prolem comes
   up if the ELF linker uses both instances of libc.so to resolve
   the references. 

I don't see how this can happen.  The symbols are loaded the first
time, and the second time around the symbols should just be ignored.
I can't recreate this problem at all.

I can detect exactly one symptom from linking a dynamic object in more
than once: two DT_NEEDED entries are created.  Since that is
undesirable, since it may force the runtime loader to do extra work,
this patch will avoid the problem.  It will probably also fix whatever
problem you are encountering.

Ian

Index: elfcode.h
===================================================================
RCS file: /rel/cvsfiles/devo/bfd/elfcode.h,v
retrieving revision 1.179
diff -p -r1.179 elfcode.h
*** elfcode.h	1995/03/13 21:55:57	1.179
--- elfcode.h	1995/03/17 16:45:58
*************** elf_link_add_object_symbols (abfd, info)
*** 4215,4220 ****
--- 4215,4221 ----
      {
        asection *s;
        const char *name;
+       bfd_size_type oldsize;
        bfd_size_type strindex;
  
        dynamic = true;
*************** elf_link_add_object_symbols (abfd, info)
*** 4301,4310 ****
--- 4302,4344 ----
  	}
  
        /* Add a DT_NEEDED entry for this dynamic object.  */
+       oldsize = _bfd_stringtab_size (elf_hash_table (info)->dynstr);
        strindex = _bfd_stringtab_add (elf_hash_table (info)->dynstr, name,
  				     true, false);
        if (strindex == (bfd_size_type) -1)
  	goto error_return;
+ 
+       if (oldsize == _bfd_stringtab_size (elf_hash_table (info)->dynstr))
+ 	{
+ 	  asection *sdyn;
+ 	  Elf_External_Dyn *dyncon, *dynconend;
+ 
+ 	  /* The hash table size did not change, which means that the
+              dynamic object name was already entered.  If we have
+              already included this dynamic object in the link, just
+              ignore it.  There is no reason to include a particular
+              dynamic object more than once.  */
+ 	  sdyn = bfd_get_section_by_name (elf_hash_table (info)->dynobj,
+ 					  ".dynamic");
+ 	  BFD_ASSERT (sdyn != NULL);
+ 
+ 	  dyncon = (Elf_External_Dyn *) sdyn->contents;
+ 	  dynconend = (Elf_External_Dyn *) (sdyn->contents + sdyn->_raw_size);
+ 	  for (; dyncon < dynconend; dyncon++)
+ 	    {
+ 	      Elf_Internal_Dyn dyn;
+ 
+ 	      elf_swap_dyn_in (elf_hash_table (info)->dynobj, dyncon, &dyn);
+ 	      if (dyn.d_tag == DT_NEEDED
+ 		  && dyn.d_un.d_val == strindex)
+ 		{
+ 		  if (buf != NULL)
+ 		    free (buf);
+ 		  return true;
+ 		}
+ 	    }
+ 	}
+ 
        if (! elf_add_dynamic_entry (info, DT_NEEDED, strindex))
  	goto error_return;
      }



From rms@gnu.ai.mit.edu  Fri Mar 17 09:27:00 1995
From: rms@gnu.ai.mit.edu (Richard Stallman)
Date: Fri, 17 Mar 1995 09:27:00 -0000
Subject: How to fix the ELF linker?
References: <9503171422.AA15591@titanic.nynexst.com>
Message-ID: <199503171726.MAA07722@mole.gnu.ai.mit.edu>

    > So linking the same shared library a second time might as well be
    > a no-op.

Ignoring the second loading of the same library should be a very
simple change.

On the other hand, if the linker doesn't make all the global symbols
in the shared library available properly for references encountered
subsequently, fixing that might be a little harder.




From hjl@nynexst.com  Fri Mar 17 18:31:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Fri, 17 Mar 1995 18:31:00 -0000
Subject: A bug in nm, ar ...
Message-ID: <9503180222.AA20585@titanic.nynexst.com>

Hi,

If I configure binutils for more than one targets, ar, nm ...
will fail most of time for all but the default target. The problem
is bfd_check_format_matches () will find more than one matches
on library archives created by ar and return an error. I am not
sure how to fix it. Maybe bfd_check_format_matches () should just
return true if the input file is an archive and match any targets.
Will bfd handle those archive members right?

BTW, -DGNU960 will do the similar trick on bfd/format.c.


Thanks.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From hjl@nynexst.com  Sat Apr 15 10:30:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Sat, 15 Apr 1995 10:30:00 -0000
Subject: Only I use gas under x86?
Message-ID: <9504151729.AA19436@titanic.nynexst.com>

Hi,

After installing the new gas, my old programs assembled by the new gas
failed to work. I spent a whole night tracking it down. It turned out
the new x86 gas was broken due to a typo. Please tak a second look at
diffs-950411.gz and pay attenyion to ./gas/config/tc-i386.h. BTW,
there was no ChangeLog entry for the typo.

No, I won't provide a diff nor point out the typo. It is a very dumb
typo.

I have a feeling that not many people test the x86 gas a lot.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From roland@gnu.ai.mit.edu  Sat Apr 15 11:25:00 1995
From: roland@gnu.ai.mit.edu (Roland McGrath)
Date: Sat, 15 Apr 1995 11:25:00 -0000
Subject: Only I use gas under x86?
References: <9504151729.AA19436@titanic.nynexst.com>
Message-ID: <199504151825.OAA21677@churchy.gnu.ai.mit.edu>

I use gas on i386 all the time (target=i386-gnuelf in fact, which is
identical to i386-linux for gas).  I use the current sources, though I
don't recompile every day.  Whenever there has been a problem it has been
taken care of pretty quickly.  We cannot expect the maintainers to test
every single change on every platform; we are using development code,
certainly it would be tested on i386 before released.

However, it is a serious problem if people are making changes without
proper ChangeLog entries.  That really makes life difficult.  The rest of
us do not have access to the RCS logs to fill in the gaps in the ChangeLog
files; those files really need to be complete.  They are the first place
anyone looks to see what changed when something broke, and why.



From raeburn@cygnus.com  Sat Apr 15 11:41:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Sat, 15 Apr 1995 11:41:00 -0000
Subject: Only I use gas under x86?
References: <9504151729.AA19436@titanic.nynexst.com>
Message-ID: <9504151841.AA14152@cujo.cygnus.com>

	 BTW,
   there was no ChangeLog entry for the typo.

Actually, there was -- two change log entries for changes to
practically all the tc-*.c or .h files.

   No, I won't provide a diff nor point out the typo. It is a very dumb
   typo.

Yup, it was.

   I have a feeling that not many people test the x86 gas a lot.

My automated tests for x86 are still broken because (I think) someone
deinstalled bison from some of the Cygnus machines.  And we've only
got two in the California office I can do the automatic testing on,
running sco and unixware.  It's not a happy scene.

Once I get a few "I need a patch last week" customer bug reports out
of the way, I plan to clean up some of the problems reported in the
automatic testing.  And maybe even start catching up in my
bug-gnu-utils backlog. :-(

For the moment, yes, I think you're one of the main x86 testers of the
development code.

Maybe I'll look into some automatic testing in the Massachusetts
office; we've got a Linux box there, but network security issues make
it a little difficult to tie the testing into the snapshot process as
tightly as I'd like.  Tying in my home pc (netbsd) or laptop (linux)
would be at least as difficult.



From rms@gnu.ai.mit.edu  Sat Apr 15 11:51:00 1995
From: rms@gnu.ai.mit.edu (Richard Stallman)
Date: Sat, 15 Apr 1995 11:51:00 -0000
Subject: Only I use gas under x86?
References: <199504151825.OAA21677@churchy.gnu.ai.mit.edu>
Message-ID: <199504151851.OAA01819@mole.gnu.ai.mit.edu>

RCS log items should be copies of material from ChangeLog.
People installing changes in GAS should first write entries
in ChangeLog, then copy them for RCS checkin.

(There is one other alternative--to generate ChangeLog from the RCS
logs--but this is an all-or-nothing choice.  If the maintainers of a
program switch to that method, they must all switch at once.)



From hjl@nynexst.com  Wed Apr 19 22:36:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Wed, 19 Apr 1995 22:36:00 -0000
Subject: An ELF ld bug?
References: <199504142245.SAA13478@churchy.gnu.ai.mit.edu>
Message-ID: <9504200534.AA14268@titanic.nynexst.com>

> 
> > ctype is a bad example. Try other locale catetories.
> 
> What is wrong with ctype?  It demonstrates exactly the usage I am talking
> about.

Those ctype files will be needed for other reasons. Please try
the enclosed test case.

> 
> > > > BTW, why do you want to mark _nl_xxxxx as weak symbols?
> > > 
> > > So that if a program calls setlocale, but uses only (e.g.) the ctype data,
> > > then all the built-in "C" locale data for the other categories need not be
> > > linked in, and setlocale in fact will avoid reading the locale data files
> > > at run time for the unused categories.  It makes the program smaller (if
> > > statically linked) and faster.
> > > 
> > 
> > I am not sure if weak symbol is used for that purpose. 
> 
> I just told you I am using it for that purpose!  And it works fine!
> 
> > How does a linker know what categories a setlocal () will use?
> 
> Of course the linker doesn't know anything about it!  If the program uses
> the locale data, it will refer to _nl_current_LC_* which is defined in
> lc-*.o, and those references will be strong refs not weak ones.  Those
> references cause the necessary files to be linked in, regardless of setlocale.
> 
> This is why nl_langinfo.c goes to special pains to produce a strong
> reference to each _nl_current_LC_* symbol, because the run-time argument to
> nl_langinfo determines which categories are involved, so all the data is
> potentially needed.
> 

As of gas-950417, the ld bug was still not fixed. BTW, I couldn't find
the ChangeLog entry for that fix.



-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
------
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  Makefile bar.c foo.c main.c x.c
# Wrapped by hjl@jalod on Thu Apr 20 01:28:58 1995
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'Makefile' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'Makefile'\"
else
echo shar: Extracting \"'Makefile'\" \(281 characters\)
sed "s/^X//" >'Makefile' <<'END_OF_FILE'
XSRCS= foo.c x.c bar.c
XOBJS=$(SRCS:.c=.o)
XAR=ar
XRANLIB =ranlib
X
X.c.o:
X	$(CC) $(CFLAGS) -c $<
X
Xall: f1 f2
X
Xf1: libfoo.a
X	$(CC) -o $@ main.c -L. -lfoo
X
Xf2: libfoo.a
X	$(CC) -o $@ main.c x.o -L. -lfoo
X
Xlibfoo.a:$(OBJS)
X	$(AR) ucvr $@ $(OBJS)
X	$(RANLIB) $@
X
Xclean:
X	-rm -f *.o *.a f1 f2
END_OF_FILE
if test 281 -ne `wc -c <'Makefile'`; then
    echo shar: \"'Makefile'\" unpacked with wrong size!
fi
# end of 'Makefile'
fi
if test -f 'bar.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'bar.c'\"
else
echo shar: Extracting \"'bar.c'\" \(68 characters\)
sed "s/^X//" >'bar.c' <<'END_OF_FILE'
X#include <stdio.h>
X
Xextern int x;
X
Xbar ()
X{
X  printf ("%d\n", x);
X}
END_OF_FILE
if test 68 -ne `wc -c <'bar.c'`; then
    echo shar: \"'bar.c'\" unpacked with wrong size!
fi
# end of 'bar.c'
fi
if test -f 'foo.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'foo.c'\"
else
echo shar: Extracting \"'foo.c'\" \(85 characters\)
sed "s/^X//" >'foo.c' <<'END_OF_FILE'
X#include <stdio.h>
X
X#pragma weak x
X
Xextern int  x;
X
Xfoo ()
X{
X  printf ("%d\n", x);
X}
END_OF_FILE
if test 85 -ne `wc -c <'foo.c'`; then
    echo shar: \"'foo.c'\" unpacked with wrong size!
fi
# end of 'foo.c'
fi
if test -f 'main.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'main.c'\"
else
echo shar: Extracting \"'main.c'\" \(32 characters\)
sed "s/^X//" >'main.c' <<'END_OF_FILE'
Xmain ()
X{
X  foo ();
X  bar ();
X}
END_OF_FILE
if test 32 -ne `wc -c <'main.c'`; then
    echo shar: \"'main.c'\" unpacked with wrong size!
fi
# end of 'main.c'
fi
if test -f 'x.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'x.c'\"
else
echo shar: Extracting \"'x.c'\" \(12 characters\)
sed "s/^X//" >'x.c' <<'END_OF_FILE'
Xint x = 20;
END_OF_FILE
if test 12 -ne `wc -c <'x.c'`; then
    echo shar: \"'x.c'\" unpacked with wrong size!
fi
# end of 'x.c'
fi
echo shar: End of shell archive.
exit 0



From hjl@nynexst.com  Mon Apr 24 14:13:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 24 Apr 1995 14:13:00 -0000
Subject: A question for ELF linker.
Message-ID: <9504242110.AA16797@titanic.nynexst.com>

Hi,

I think the search order of ELF linker is wrong. It will
search all directories for shared libraries first no matter
if there is a static one in one of the directories.

I think we can copy sunos.em for it. In the meantime, I can
even add the major/minor version support.  Should I submit
a patch?


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From raeburn@cygnus.com  Mon Apr 24 18:38:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Mon, 24 Apr 1995 18:38:00 -0000
Subject: binutils snapshots no longer build gas
References: <9504230810.AA43969@sandcastle.watson.ibm.com>
Message-ID: <9504250138.AA05613@cujo.cygnus.com>

   Date: Sun, 23 Apr 1995 04:10:10 -0400
   From: "David Edelsohn" <dje@watson.ibm.com>

	   gas has been added to the list of noconfigdirs in configure.in
   for all rs6000 and powerpc architectures.  Has gas support really
   regressed?  And "cvs" is inconsistent between the various entries: I believe
   that it is supported for all AIX configurations.

I think the problem was that gas couldn't handle certain types of
debugging information used in XCOFF format.  Maybe having to do with
inline functions from header files?  Ian knows the details, but he's
on leave.

I don't know why cvs is disabled for powerpc-*-aix* when it's enabled
for rs6000-*-aix*.  But I'll leave that for the cvs maintainers to
deal with.

	   Also, because binutils is not supported, c++filt is not
   built although it does not rely upon the rest of binutils functionality.
   Mike Stump was suppose to address this but it still is broken.

I think Jason has been working on making c++filt independent of
binutils in some form.



From dje@watson.ibm.com  Mon Apr 24 20:58:00 1995
From: dje@watson.ibm.com (David Edelsohn)
Date: Mon, 24 Apr 1995 20:58:00 -0000
Subject: binutils snapshots no longer build gas
References: <9504250138.AA05613@cujo.cygnus.com>
Message-ID: <9504250358.AA51766@sandcastle.watson.ibm.com>

>>>>> Ken Raeburn writes:

Ken> I think the problem was that gas couldn't handle certain types of
Ken> debugging information used in XCOFF format.  Maybe having to do with
Ken> inline functions from header files?  Ian knows the details, but he's on
Ken> leave.

	GAS does have some limitations with respect to XCOFF support
including the problem with included files which you mention, but I do not
understand why that is important enough to disable the AIX XCOFF
configuration of GAS.  Some support is better than no support: IBM XAS still
is distributed with AIX 4.1 so one can use that if one encounters the
debugging information limitation.

David
===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 808 879 5077                                     Yorktown Heights, NY 10598



From raeburn@cygnus.com  Mon Apr 24 23:06:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Mon, 24 Apr 1995 23:06:00 -0000
Subject: binutils snapshots no longer build gas
References: <9504250358.AA51766@sandcastle.watson.ibm.com>
Message-ID: <9504250606.AA05683@cujo.cygnus.com>

	   GAS does have some limitations with respect to XCOFF support
   including the problem with included files which you mention, but I do not
   understand why that is important enough to disable the AIX XCOFF
   configuration of GAS.  Some support is better than no support: IBM XAS still
   is distributed with AIX 4.1 so one can use that if one encounters the
   debugging information limitation.

I think it's a question of which works better, and what the default
should be for naive users.  If the native assembler is going to work
significantly better, we can't really justify shipping to customers
paying for the end result a toolchain using the inferior GNU one
instead.  If no native assembler exists (e.g., for embedded targets)
then using the GNU one makes sense.

You can of course override the top-level configure.in script and use
gas on such machines if you really want to.  Even better, you can do
that, and then send in patches to make gas and bfd work really well on
XCOFF. :-)

But does building and installing gas by default really gain the
average user anything that makes up for the problems in debugging?
Apparently Jim Kingdon -- one of the gdb maintainers -- didn't think
so.

Ken



From dje@watson.ibm.com  Mon Apr 24 23:37:00 1995
From: dje@watson.ibm.com (David Edelsohn)
Date: Mon, 24 Apr 1995 23:37:00 -0000
Subject: binutils snapshots no longer build gas
References: <9504250606.AA05683@cujo.cygnus.com>
Message-ID: <9504250637.AA35181@sandcastle.watson.ibm.com>

	The current state implies that GAS does not build or function at all.
I agree that making GAS the default system assembler may cause some
problems for users, but not building GAS at all seems to be an incorrect
solution at the opposite extreme.  At IBM Watson, I have gas from
binutils-2.5.2 installed as "gas" not "as".  I think the biggest problem
with the current distribution is that this debugging problem is hidden in
a FIXME comment instead of in the GAS documentation for the AIX XCOFF
configuration.  I would let the user/installer decide whether s/he wants
a partially functional GAS instead of implying that no functionality exists.
	Also, AIX XAS has a bug not present in GAS which prevents it from
assembling certain GCC output for the POWER/2 architecture.  XAS incorrectly
exits with an error when it see certain POWER/2 and POWER instructions
utilized in the same assembler source file believing that it is an invalid
combination.

David




From hjl@nynexst.com  Tue Apr 25 07:27:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Tue, 25 Apr 1995 07:27:00 -0000
Subject: procfs patches for Linux
References: <9504250459.AA05647@cujo.cygnus.com>
Message-ID: <9504251425.AA21877@titanic.nynexst.com>

> 
> 
> As I understand it, a.out versus ELF is not the issue.  As Mike
> explained it to me, the procfs support is at least somewhat separate
> from the a.out/ELF issue.
> 
> The problem is whether the ELF support can be compiled.  With this
> change, anyone who wants to build the gas snapshots targeted for any ELF
> configuration -- be it i386-linux or powerpc-elf or sparc-solaris or
> anything else -- has to have your latest software, only a few days old.
> 
> Because of the way BFD is set up, core file support is compiled in even
> for cross configurations.  (This is a bug, and I'll happily take patches
> to fix it.)  So the Linux core file support has to compile, because

Will you? Please take a look at below.

> people may be using Linux as a development system for a cross-assembler.


That was what I faced more than 2 years ago while bootstrapping
gcc for Linux in a cross-compile environment. One solution is:

# cd bfd
# mdkir targets
# cd targets

We move all the target stuff from bfd/hosts to bfd/targets. In
bfd/configure, we do:

2. if [ -f $srcdir/targets/target.h ]; then
	link $srcdir/targets/target.h to tsysdep.h.
	link $srcdir/hosts/host.h to hsysdep.h.
	echo include "hsysdep.h" > sysdep.h
	echo include "tsysdep.h" >> sysdep.h
   else
	link $srcdir/hosts/host.h to sysdep.h.
   fi

> 
> I'm not entirely convinced that the switch to ELF as the default for gcc
> and binutils won't screw some of those people, where version numbers
> aren't factored into it in any way.  Have you gotten into the FSF's gcc
> documentation (and, ideally, into the release announcement too) some
> notes about using "linuxaout" if people have older Linux systems?  Or do

Yes. I changed install.texi for gcc. But again, I am not sure if
they will read it.

> you just assume everyone always wants the latest development code,
> stability be damned?
> 
> I'm disabling HAVE_PROCFS for Linux in BFD for now, until you can give
> me something that supports both system environments, with sys/procfs.h
> and without.
> 

I will fix it on the linux side. How about my suggestion to
bfd?

BTW, do you need a patch for elf32.em to fix the -Lxxxx bug?


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From raeburn@cygnus.com  Tue Apr 25 09:52:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Tue, 25 Apr 1995 09:52:00 -0000
Subject: procfs patches for Linux
References: <9504251425.AA21877@titanic.nynexst.com>
Message-ID: <9504251652.AA05837@cujo.cygnus.com>

   > Because of the way BFD is set up, core file support is compiled in even
   > for cross configurations.  (This is a bug, and I'll happily take patches
   > to fix it.)  So the Linux core file support has to compile, because

   Will you? Please take a look at below.

   > people may be using Linux as a development system for a cross-assembler.


   That was what I faced more than 2 years ago while bootstrapping
   gcc for Linux in a cross-compile environment. One solution is:

   # cd bfd
   # mdkir targets
   # cd targets

   We move all the target stuff from bfd/hosts to bfd/targets. In
   bfd/configure, we do:

   2. if [ -f $srcdir/targets/target.h ]; then
	   link $srcdir/targets/target.h to tsysdep.h.
	   link $srcdir/hosts/host.h to hsysdep.h.
	   echo include "hsysdep.h" > sysdep.h
	   echo include "tsysdep.h" >> sysdep.h
      else
	   link $srcdir/hosts/host.h to sysdep.h.
      fi

The core file support is often dependent on system header files that
we don't duplicate in the binutils distribution.  Trying to include
sunos header files when building a sunos cross-assembler hosted on
linux won't work because you don't have the sunos header files.  And
you shouldn't have to copy them all over from one system to the other
just to build binutils.

In a cross configuration, it generally shouldn't be built.  There may
be cases where we do have enough information to do it, I don't know.
But I don't think that's going to be the common case.  (Currently I
don't think cross-debuggers are expected to handle core files, so it'd
be no real loss to omit the core file support altogether in cross
configurations.)

   > I'm disabling HAVE_PROCFS for Linux in BFD for now, until you can give
   > me something that supports both system environments, with sys/procfs.h
   > and without.

   I will fix it on the linux side.

Thanks.

   BTW, do you need a patch for elf32.em to fix the -Lxxxx bug?

Maybe.  I want to check it against the behavior on Solaris or some
other non-GNU ELF system.



From hjl@nynexst.com  Tue Apr 25 10:51:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Tue, 25 Apr 1995 10:51:00 -0000
Subject: procfs patches for Linux
References: <9504251652.AA05837@cujo.cygnus.com>
Message-ID: <9504251748.AA23147@titanic.nynexst.com>

>    gcc for Linux in a cross-compile environment. One solution is:
> 
>    # cd bfd
>    # mdkir targets
>    # cd targets
> 
>    We move all the target stuff from bfd/hosts to bfd/targets. In
>    bfd/configure, we do:
> 
>    2. if [ -f $srcdir/targets/target.h ]; then

Change that to

	if [ $default_target == $host and 
		-f $srcdir/targets/default_target.h ]; then

> 	   link $srcdir/targets/target.h to tsysdep.h.
> 	   link $srcdir/hosts/host.h to hsysdep.h.
> 	   echo include "hsysdep.h" > sysdep.h
> 	   echo include "tsysdep.h" >> sysdep.h
>       else
> 	   link $srcdir/hosts/host.h to sysdep.h.
>       fi
> 
> The core file support is often dependent on system header files that
> we don't duplicate in the binutils distribution.  Trying to include
> sunos header files when building a sunos cross-assembler hosted on
> linux won't work because you don't have the sunos header files.  And
> you shouldn't have to copy them all over from one system to the other
> just to build binutils.
> 
> In a cross configuration, it generally shouldn't be built.  There may
> be cases where we do have enough information to do it, I don't know.
> But I don't think that's going to be the common case.  (Currently I
> don't think cross-debuggers are expected to handle core files, so it'd
> be no real loss to omit the core file support altogether in cross
> configurations.)

How about my changes above?

> 
>    BTW, do you need a patch for elf32.em to fix the -Lxxxx bug?
> 
> Maybe.  I want to check it against the behavior on Solaris or some
> other non-GNU ELF system.
> 

I already checked SVR4.2. It doesn't have the GNU ld bug.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From baford@schirf.cs.utah.edu  Tue Apr 25 16:10:00 1995
From: baford@schirf.cs.utah.edu (Bryan Ford)
Date: Tue, 25 Apr 1995 16:10:00 -0000
Subject: .align behavior in gas
Message-ID: <199504252316.RAA09079@schirf.cs.utah.edu>

In recent gas snapshots, it seems that for some i386 targets
(e.g. i386-mach, i386-gnu), gas interprets the .align directive
as a number of bytes; whereas for other targets (e.g. i386-linux)
it is interpreted as log2(nbytes).  Has this always been the case?
Are there any other directives that perform the same function but
have a consistent behavior?  (I looked at gas/read.c, but couldn't
find anything.)  If not, it would be very useful to have a new directive
called, say, '.balign' that always takes a number of bytes, and/or a new
directive called something like '.p2align' that always takes a power of
two.  (I don't care what it is, as long as it's consistent!)   This
should be trivial to do; just a matter of adding a new line or two
to read.c, right?

Thanks!

				Bryan
---
Bryan Ford	baford@cs.utah.edu	University of Utah, CSS
`finger baford@schirf.cs.utah.edu' for PGP key and other info.



From raeburn@cygnus.com  Wed Apr 26 07:01:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Wed, 26 Apr 1995 07:01:00 -0000
Subject: .align behavior in gas
References: <199504252316.RAA09079@schirf.cs.utah.edu>
Message-ID: <9504261401.AA06654@cujo.cygnus.com>

   Date: Tue, 25 Apr 95 17:16:18 MDT
   From: Bryan Ford <baford@schirf.cs.utah.edu>

   In recent gas snapshots, it seems that for some i386 targets
   (e.g. i386-mach, i386-gnu), gas interprets the .align directive
   as a number of bytes; whereas for other targets (e.g. i386-linux)
   it is interpreted as log2(nbytes).  Has this always been the case?

Yup.

   Are there any other directives that perform the same function but
   have a consistent behavior?  (I looked at gas/read.c, but couldn't

Not yet...

   find anything.)  If not, it would be very useful to have a new directive
   called, say, '.balign' that always takes a number of bytes, and/or a new
   directive called something like '.p2align' that always takes a power of
   two.  (I don't care what it is, as long as it's consistent!)   This
   should be trivial to do; just a matter of adding a new line or two
   to read.c, right?

Plus the update to the documentation...



From meissner@cygnus.com  Wed Apr 26 07:03:00 1995
From: meissner@cygnus.com (Mike Meissner)
Date: Wed, 26 Apr 1995 07:03:00 -0000
Subject: .align behavior in gas
References: <199504252316.RAA09079@schirf.cs.utah.edu> <199504252316.RAA09079@schirf.cs.utah.edu>
Message-ID: <199504261403.KAA00551@tiktok.cygnus.com>

| In recent gas snapshots, it seems that for some i386 targets
| (e.g. i386-mach, i386-gnu), gas interprets the .align directive
| as a number of bytes; whereas for other targets (e.g. i386-linux)
| it is interpreted as log2(nbytes).  Has this always been the case?

Yes.  At least it was the case for i386-mach 6 years ago when we used
that version of gas for the i486 on OSF/1.  Elf assemblers
interpretted as log2 bytes.  I believe that in either case, gas is
attempting to be compatible with the native assembler.

| Are there any other directives that perform the same function but
| have a consistent behavior?  (I looked at gas/read.c, but couldn't
| find anything.)  If not, it would be very useful to have a new directive
| called, say, '.balign' that always takes a number of bytes, and/or a new
| directive called something like '.p2align' that always takes a power of
| two.  (I don't care what it is, as long as it's consistent!)   This
| should be trivial to do; just a matter of adding a new line or two
| to read.c, right?

Yep.

-- 
Michael Meissner, Cygnus Support (East Coast)
Suite 105, 48 Grove Street, Somerville, MA 02144, USA
meissner@cygnus.com,	617-629-3016 (office),	617-629-3010 (fax)



From baford@schirf.cs.utah.edu  Wed Apr 26 10:27:00 1995
From: baford@schirf.cs.utah.edu (Bryan Ford)
Date: Wed, 26 Apr 1995 10:27:00 -0000
Subject: .align behavior in gas 
References: <9504261401.AA06654@cujo.cygnus.com>
Message-ID: <199504261733.LAA14206@schirf.cs.utah.edu>

>   In recent gas snapshots, it seems that for some i386 targets
>   (e.g. i386-mach, i386-gnu), gas interprets the .align directive
>   as a number of bytes; whereas for other targets (e.g. i386-linux)
>   it is interpreted as log2(nbytes).  Has this always been the case?
>
>Yup.
>
>   Are there any other directives that perform the same function but
>   have a consistent behavior?  (I looked at gas/read.c, but couldn't
>
>Not yet...
>
>   find anything.)  If not, it would be very useful to have a new directive
>   called, say, '.balign' that always takes a number of bytes, and/or a new
>   directive called something like '.p2align' that always takes a power of
>   two.  (I don't care what it is, as long as it's consistent!)   This
>   should be trivial to do; just a matter of adding a new line or two
>   to read.c, right?
>
>Plus the update to the documentation...

OK, OK, I get the point - I'll do it. :-)
(Actually, it seems the documentation was pretty badly inaccurate already.)
Here's the patch...

diff -ur old/doc/as.texinfo ./doc/as.texinfo
--- old/doc/as.texinfo	Wed Apr 26 10:09:57 1995
+++ ./doc/as.texinfo	Wed Apr 26 10:37:39 1995
@@ -2650,6 +2650,8 @@
 @end ifset
 
 * Align::                       @code{.align @var{abs-expr} , @var{abs-expr}}
+* Balign::                      @code{.balign @var{abs-expr} , @var{abs-expr}}
+* P2align::                     @code{.p2align @var{abs-expr} , @var{abs-expr}}
 * App-File::                    @code{.app-file @var{string}}
 * Ascii::                       @code{.ascii "@var{string}"}@dots{}
 * Asciz::                       @code{.asciz "@var{string}"}@dots{}
@@ -2774,17 +2776,56 @@
 @cindex @code{align} directive
 Pad the location counter (in the current subsection) to a particular
 storage boundary.  The first expression (which must be absolute) is the
+alignment required, as described below.
+The second expression (also absolute) gives the value to be stored in
+the padding bytes.  It (and the comma) may be omitted.  If it is
+omitted, the padding bytes are zero.
+
+The way the required alignment is specified varies from system to system.
+For the a29k, HPPA, m86k, m88k, w65, sparc, and i386 using ELF format,
+the first expression is the
+alignment request in bytes.  For example @samp{.align 8} advances
+the location counter until it is a multiple of 8.  If the location counter
+is already a multiple of 8, no change is needed.
+
+For other systems, including the i386 using a.out format, it is the
 number of low-order zero bits the location counter must have after
 advancement.  For example @samp{.align 3} advances the location
 counter until it a multiple of 8.  If the location counter is already a
 multiple of 8, no change is needed.
 
-@ifset HPPA
-For the HPPA, the first expression (which must be absolute) is the
-alignment request in bytes.  For example @samp{.align 8} advances
+This inconsistency is due to the different behaviors of the various
+native assemblers for these systems which GAS must emulate.
+GAS also provides @code{.balign} and @code{.p2align} directives,
+described below, which have a consistent behavior across all
+architectures (but are specific to GAS).
+
+@node Balign
+@section @code{.balign @var{abs-expr} , @var{abs-expr}}
+
+@cindex padding the location counter given number of bytes
+@cindex @code{balign} directive
+Pad the location counter (in the current subsection) to a particular
+storage boundary.  The first expression (which must be absolute) is the
+alignment request in bytes.  For example @samp{.balign 8} advances
 the location counter until it is a multiple of 8.  If the location counter
 is already a multiple of 8, no change is needed.
-@end ifset
+
+The second expression (also absolute) gives the value to be stored in
+the padding bytes.  It (and the comma) may be omitted.  If it is
+omitted, the padding bytes are zero.
+
+@node P2align
+@section @code{.p2align @var{abs-expr} , @var{abs-expr}}
+
+@cindex padding the location counter given a power of two
+@cindex @code{p2align} directive
+Pad the location counter (in the current subsection) to a particular
+storage boundary.  The first expression (which must be absolute) is the
+number of low-order zero bits the location counter must have after
+advancement.  For example @samp{.p2align 3} advances the location
+counter until it a multiple of 8.  If the location counter is already a
+multiple of 8, no change is needed.
 
 The second expression (also absolute) gives the value to be stored in
 the padding bytes.  It (and the comma) may be omitted.  If it is
diff -ur old/read.c ./read.c
--- old/read.c	Wed Apr 26 10:09:36 1995
+++ ./read.c	Wed Apr 26 10:11:13 1995
@@ -193,6 +193,8 @@
 {
   {"abort", s_abort, 0},
   {"align", s_align_ptwo, 0},
+  {"balign", s_align_bytes, 0},
+  {"p2align", s_align_ptwo, 0},
   {"ascii", stringer, 0},
   {"asciz", stringer, 1},
 /* block */



From raeburn@cygnus.com  Wed Apr 26 13:03:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Wed, 26 Apr 1995 13:03:00 -0000
Subject: .align behavior in gas
References: <199504261733.LAA14206@schirf.cs.utah.edu>
Message-ID: <9504262003.AA06833@cujo.cygnus.com>

I made minor changes to keep things in alphabetical order, but it's
in.  Should be available in tomorrow morning's snapshot.

Thanks.

Ken



From raeburn@cygnus.com  Thu Apr 27 12:36:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Thu, 27 Apr 1995 12:36:00 -0000
Subject: binutils snapshots no longer build gas
References: <9504250637.AA35181@sandcastle.watson.ibm.com>
Message-ID: <9504271936.AA00439@cujo.cygnus.com>

	   The current state implies that GAS does not build or function at all.

It should only imply that we don't currently recommend using it.

   I agree that making GAS the default system assembler may cause some
   problems for users, but not building GAS at all seems to be an incorrect
   solution at the opposite extreme.  At IBM Watson, I have gas from
   binutils-2.5.2 installed as "gas" not "as".  I think the biggest problem
   with the current distribution is that this debugging problem is hidden in
   a FIXME comment instead of in the GAS documentation for the AIX XCOFF
   configuration.  I would let the user/installer decide whether s/he wants
   a partially functional GAS instead of implying that no functionality exists.

Makes sense.  But I still think the default for the relatively
clueless user should be the safer path.  In this case, not using gas.
Perhaps we could change the top-level configure.in to include gas if
"--with-gnu-as" is supplied.

	   Also, AIX XAS has a bug not present in GAS which prevents it from
   assembling certain GCC output for the POWER/2 architecture.  XAS incorrectly
   exits with an error when it see certain POWER/2 and POWER instructions
   utilized in the same assembler source file believing that it is an invalid
   combination.

Hm..  This changes things.  The user's going to lose either way.
Perhaps it's worth re-evaluating whether the gas bug can be fixed.
Mike Meissner is doing powerpc gas work at Cygnus right now; I've
asked him to take a look.

Is there a fixed assembler available from IBM?  It would be worth
mentioning in the gcc documentation whether or not gas would work.
And it would make having gas available less critical.



From hjl@nynexst.com  Fri Apr 28 18:39:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Fri, 28 Apr 1995 18:39:00 -0000
Subject: strip 04/17/95 bug (fwd)
Message-ID: <9504290136.AA19702@titanic.nynexst.com>

Forwarded message:
>From owner-gcc@vger.rutgers.edu Fri Apr 28 01:14:25 1995
From: Snow Cat <snowcat@gd.cs.CSUFresno.EDU>
Message-Id: <199504280400.VAA02101@ariel.disney.org>
Subject: strip 04/17/95 bug
To: linux-gcc@vger.rutgers.edu
Date: Thu, 27 Apr 1995 21:00:29 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL24 PGP2]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 690       
Sender: owner-gcc@vger.rutgers.edu
Precedence: bulk

Hi Net,

I just noticed that  strip is unable  to handle an executable  that is
currently in  use   and      that  has  multiple  links     (like   my
/usr/local/bin/zsh that  is also  known  as /bin/zsh).  This is  to be
expected, because  files in use can't be  opened for writing and files
with  multiple links can't  be unlinked and re-written. However, strip
doesn't show any error message - instead it  exits silently and leaves
a file named something like 'sta01267'. This is NOT  to be expected, I
think.

-- 
     Snow ^oo^ Cat <snowcat@gd.cs.CSUFresno.EDU>
      _  ->  <-    aka Oleg Kibirev <oleg@gd.cs.CSUFresno.EDU>
  ___(_)  _ _)_
 /            _)
 \_.-._
       |___/	Purr!


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From hjl@nynexst.com  Mon May  1 13:29:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 01 May 1995 13:29:00 -0000
Subject: binutils 2.5.2l.10 is released.
References: <9505012011.AA14501@gnu.mc.xerox.com>
Message-ID: <9505012026.AA04105@titanic.nynexst.com>

> 
> > I don't remember that. I understand -static will turn off the lib*.so*
> > search.
> > 
> > -- 
> > H.J. Lu
> > NYNEX Science and Technology, Inc.			hjl@nynexst.com
> 
> 
> I never got around to implementing this behavior in gcc (I complained
> about it for years...)
> 
> On Sun, the linker allows you to do:
> 
> ld *.o -lfoo1 -Bstatic -lfoo2 -Bdynamic -lfoo3
> 
> (essentially specially which libraries to link statically).
> 
> In order to get the same behavior, you need to do:
> ld *.o -lfoo1 /usr/lib/libfoo.a -lfoo3
> with gcc/ld
> 

I will implement it if noone does and I have the time. First we
have to agree on what syntax to use. -Bstatic/-Bdynamic or
-static/-dynamic?


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From leisner@sdsp.mc.xerox.com  Mon May  1 13:45:00 1995
From: leisner@sdsp.mc.xerox.com (Marty Leisner)
Date: Mon, 01 May 1995 13:45:00 -0000
Subject: binutils 2.5.2l.10 is released. 
References: <9505012026.AA04105@titanic.nynexst.com>
Message-ID: <9505012048.AA15574@gnu.mc.xerox.com>

>> 
>
>I will implement it if noone does and I have the time. First we
>have to agree on what syntax to use. -Bstatic/-Bdynamic or
>-static/-dynamic?
>
>
>-- 
>H.J. Lu
>NYNEX Science and Technology, Inc.			hjl@nynexst.com

Thanks...if you understand how gcc is organized  (I looked at this
in 1.x and saw it was a lot to understand).

This should be trivial...Use -static/-dynamic [does gnu ld understand 
this?]

(its not trivial to even see if ld works this way ;-( )

Doing this is a big win.
marty



From hjl@nynexst.com  Tue May  2 00:05:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Tue, 02 May 1995 00:05:00 -0000
Subject: -static -lfoo -dynamic -lbar
References: <9505012048.AA15574@gnu.mc.xerox.com>
Message-ID: <9505020702.AA06681@titanic.nynexst.com>

> 
> 
> >> 
> >
> >I will implement it if noone does and I have the time. First we
> >have to agree on what syntax to use. -Bstatic/-Bdynamic or
> >-static/-dynamic?
> >
> >
> >-- 
> >H.J. Lu
> >NYNEX Science and Technology, Inc.			hjl@nynexst.com
> 
> Thanks...if you understand how gcc is organized  (I looked at this
> in 1.x and saw it was a lot to understand).
> 

gcc/gnu getopt liks to reorder options and I cannot use -dynamic
nor -Bxxxxx. You have to use -Wl,-xxxxxx for the time being.

> This should be trivial...Use -static/-dynamic [does gnu ld understand 
> this?]
> 

No. Use -Bstatic/-Bdynamic.

> (its not trivial to even see if ld works this way ;-( )
> 

Try this one on top of binutils 2.5.2l.11. I have included this
in binutils 2.5.2l.12. You have to use:

# gcc -v foo.o -Wl,-Bstatic -lm -Wl,-Bdynamic 

Please let me know if it works for you. BTW, it may work with
the current snapshot.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
----
RCS file: /home/cvs/gnu/binutils/ld/ldfile.c,v
retrieving revision 1.5
diff -c -r1.5 ldfile.c
*** 1.5	1995/04/27 03:24:16
--- ldfile.c	1995/05/02 06:45:45
***************
*** 183,189 ****
  	   arch != (search_arch_type *) NULL;
  	   arch = arch->next)
  	{
! 	  if (config.dynamic_link)
  	    {
  	      if (ldemul_open_dynamic_archive (arch->name, entry))
  		return;
--- 183,189 ----
  	   arch != (search_arch_type *) NULL;
  	   arch = arch->next)
  	{
! 	  if (entry->dynamic_link)
  	    {
  	      if (ldemul_open_dynamic_archive (arch->name, entry))
  		return;
===================================================================
RCS file: /home/cvs/gnu/binutils/ld/ldlang.h,v
retrieving revision 1.1.1.2
diff -c -r1.1.1.2 ldlang.h
*** 1.1.1.2	1995/02/22 02:02:31
--- ldlang.h	1995/05/02 06:45:45
***************
*** 229,234 ****
--- 229,237 ----
    asection *common_section;
    asection *common_output_section;
    boolean complained;
+ 
+   /* This is used to overwrite the global one. */
+   boolean dynamic_link;
  } lang_input_statement_type;
  
  typedef struct
===================================================================
RCS file: /home/cvs/gnu/binutils/ld/lexsup.c,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 lexsup.c
*** 1.1.1.3	1995/03/24 02:20:43
--- lexsup.c	1995/05/02 06:45:45
***************
*** 53,58 ****
--- 53,62 ----
  {
    int ingroup = 0;
  
+   int use_last_link_config = 0;
+   boolean last_is_dynamic_link;
+   lang_input_statement_type * library;
+ 
    /* Starting the short option string with '-' is for programs that
       expect options and other ARGV-elements in any order and that care about
       the ordering of the two.  We describe each non-option ARGV-element
***************
*** 193,201 ****
--- 197,209 ----
  	  break;
  	case OPTION_CALL_SHARED:
  	  config.dynamic_link = true;
+ 	  use_last_link_config = 1;
+ 	  last_is_dynamic_link = true;
  	  break;
  	case OPTION_NON_SHARED:
  	  config.dynamic_link = false;
+ 	  use_last_link_config = 1;
+ 	  last_is_dynamic_link = false;
  	  break;
  	case 'd':
  	  command_line.force_common_definition = true;
***************
*** 245,252 ****
  	  ldfile_add_library_path (optarg, true);
  	  break;
  	case 'l':
! 	  lang_add_input_file (optarg, lang_input_file_is_l_enum,
! 			       (char *) NULL);
  	  break;
  	case 'M':
  	  config.map_filename = "-";
--- 253,263 ----
  	  ldfile_add_library_path (optarg, true);
  	  break;
  	case 'l':
! 	  library = lang_add_input_file (optarg,
! 					 lang_input_file_is_l_enum,
! 					 (char *) NULL);
! 	  library->dynamic_link = use_last_link_config ?
! 		last_is_dynamic_link : config.dynamic_link;
  	  break;
  	case 'M':
  	  config.map_filename = "-";



From meissner@cygnus.com  Tue May  2 10:27:00 1995
From: meissner@cygnus.com (Mike Meissner)
Date: Tue, 02 May 1995 10:27:00 -0000
Subject: -static -lfoo -dynamic -lbar
References: <9505012048.AA15574@gnu.mc.xerox.com> <9505020702.AA06681@titanic.nynexst.com> <9505020702.AA06681@titanic.nynexst.com>
Message-ID: <199505021727.NAA01041@tiktok.cygnus.com>

| No. Use -Bstatic/-Bdynamic.

Except that GCC uses -B for other purposes.

-- 
Michael Meissner, Cygnus Support (East Coast)
Suite 105, 48 Grove Street, Somerville, MA 02144, USA
meissner@cygnus.com,	617-629-3016 (office),	617-629-3010 (fax)



From hjl@nynexst.com  Tue May  2 10:57:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Tue, 02 May 1995 10:57:00 -0000
Subject: -static -lfoo -dynamic -lbar
References: <199505021727.NAA01041@tiktok.cygnus.com>
Message-ID: <9505021753.AA09539@titanic.nynexst.com>

> 
> | No. Use -Bstatic/-Bdynamic.
> 
> Except that GCC uses -B for other purposes.

And gcc may reorder flags. That is why I said -Wl,xxxxxx.

> 

BTW, one should not make changes at 2:00am in the morning. I will
make a new simpler patch when I get home today.

-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From hjl@nynexst.com  Tue May  2 21:23:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Tue, 02 May 1995 21:23:00 -0000
Subject: A new ld patch
Message-ID: <9505030420.AA12567@titanic.nynexst.com>

This patch added the support fo -Bstatic -lfoo -Bdynamic -lbar. It
also fixed the -Lxxxxx bug.


H.J.
------
Tue May  2 00:22:54 1995  H.J. Lu (hjl@nynexst.com)

	* Makefile.in: fix a typo in comments.
	  (NO_DEFAULT_WRITABLE_TEXT_SEGMENT): unset.
	  (GENSCRIPTS): add "${NO_DEFAULT_WRITABLE_TEXT_SEGMENT}"
	  and "${LIB_PATH}".

	* genscripts.sh (LIB_PATH): set to $7.
	  (NO_DEFAULT_WRITABLE_TEXT_SEGMENT): set to $8.
	  (EMULATION_NAME): set to $9.
	  don't include the native ${LIB_PATH} for non-native
	  emulation.

	* ldfile.c (try_open_bfd): make it global.
	  (ldfile_open_file): check entry->dynamic_link instead of
	  config.dynamic_link.

	* ldlang.h (lang_input_statement_type): add 

		boolean dynamic_link;

	* lexsup.c (parse_args): add

		boolean last_is_dynamic_link = config.dynamic_link;

	  (OPTION_CALL_SHARED): set

		last_is_dynamic_link = true;

	  (OPTION_NON_SHARED): set

		last_is_dynamic_link = false;

	  ('l'): set the dynamic_link field of the library entry
	  to last_is_dynamic_link.
	  Those changes add the -Bstaic -lfoo -Bdynamic -lbar support
	  to ld.

	* config/i386-linux.mt (NO_DEFAULT_WRITABLE_TEXT_SEGMENT): set
	  to y.

	* emultempl/elf32.em: add

		#include <dirent.h>.

	  (libcmp): new function, compare two shared libraries and
	  return the order.
	  (gld${EMULATION_NAME}_find_so): new, static. search for
	  open the .so file specified by ENTRY until a match .so or .a
	  file is found.
	  (gld${EMULATION_NAME}_open_dynamic_archive): call
	  gld${EMULATION_NAME}_find_so () to find the shared
	  library.
	  use entry->filename for needed_name.

	* scripttempl/elf.sc (DATA_ALIGN): if
	  NO_DEFAULT_WRITABLE_TEXT_SEGMENT is 'y' or 'Y', set to

		${DATA_ADDR-ALIGN(${MAXPAGESIZE}) + \
		((ALIGN(8) + ${MAXPAGESIZE} - \
		ALIGN(${MAXPAGESIZE})) & (${MAXPAGESIZE} - 1))}

	  or set to

		${DATA_ADDR- ALIGN(8) + ${MAXPAGESIZE}}

===================================================================
RCS file: /home/cvs/gnu/binutils/ld/Makefile.in,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 Makefile.in
*** 1.1.1.3	1995/04/17 23:41:03
--- Makefile.in	1995/05/03 02:50:15
***************
*** 66,74 ****
  BISON = `if [ -f ../bison/bison ] ; then echo ../bison/bison -y -L../bison/bison ; else echo bison -y ; fi`
  LEX = `if [ -f ../flex/flex ] ; then echo ../flex/flex ;  else echo flex ; fi`
  
  # Seach path to override the default search path for -lfoo libraries.
  # If LIB_PATH is empty, the ones in the script (if any) are left alone.
! # (The default is usually /lib:usr/lib:/usr/local/lib, unless building
  # a cross-linker, in which case the default is empty.  See genscripts.sh.)
  # Otherwise, they are replaced with the ones given in LIB_PATH,
  # which may have the form: LIB_PATH=/lib:/usr/local/lib
--- 66,77 ----
  BISON = `if [ -f ../bison/bison ] ; then echo ../bison/bison -y -L../bison/bison ; else echo bison -y ; fi`
  LEX = `if [ -f ../flex/flex ] ; then echo ../flex/flex ;  else echo flex ; fi`
  
+ # This is for the ELF emulation scripts.
+ NO_DEFAULT_WRITABLE_TEXT_SEGMENT=
+ 
  # Seach path to override the default search path for -lfoo libraries.
  # If LIB_PATH is empty, the ones in the script (if any) are left alone.
! # (The default is usually /lib:/usr/lib:/usr/local/lib, unless building
  # a cross-linker, in which case the default is empty.  See genscripts.sh.)
  # Otherwise, they are replaced with the ones given in LIB_PATH,
  # which may have the form: LIB_PATH=/lib:/usr/local/lib
***************
*** 273,279 ****
  
  # These all start with e so 'make clean' can find them.
  
! GENSCRIPTS = $(SHELL) $(srcdir)/genscripts.sh ${srcdir} ${libdir} ${host_alias} ${target_alias} ${EMUL} "$(NATIVE_LIB_DIRS)"
  GEN_DEPENDS = $(srcdir)/genscripts.sh $(srcdir)/emultempl/stringify.sed
  
  esun4.c: $(srcdir)/emulparams/sun4.sh \
--- 276,282 ----
  
  # These all start with e so 'make clean' can find them.
  
! GENSCRIPTS = $(SHELL) $(srcdir)/genscripts.sh ${srcdir} ${libdir} ${host_alias} ${target_alias} ${EMUL} "$(NATIVE_LIB_DIRS)" "${LIB_PATH}" "${NO_DEFAULT_WRITABLE_TEXT_SEGMENT}"
  GEN_DEPENDS = $(srcdir)/genscripts.sh $(srcdir)/emultempl/stringify.sed
  
  esun4.c: $(srcdir)/emulparams/sun4.sh \
===================================================================
RCS file: /home/cvs/gnu/binutils/ld/genscripts.sh,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 genscripts.sh
*** 1.1.1.3	1995/03/24 02:20:37
--- genscripts.sh	1995/05/03 02:50:15
***************
*** 15,21 ****
  target_alias=$4
  DEFAULT_EMULATION=$5
  NATIVE_LIB_DIRS=$6
! EMULATION_NAME=$7
  
  # Include the emulation-specific parameters:
  . ${srcdir}/emulparams/${EMULATION_NAME}.sh
--- 15,23 ----
  target_alias=$4
  DEFAULT_EMULATION=$5
  NATIVE_LIB_DIRS=$6
! LIB_PATH=$7
! NO_DEFAULT_WRITABLE_TEXT_SEGMENT=$8
! EMULATION_NAME=$9
  
  # Include the emulation-specific parameters:
  . ${srcdir}/emulparams/${EMULATION_NAME}.sh
***************
*** 52,58 ****
  fi
  
  # Always search $(tooldir)/lib, aka /usr/local/TARGET/lib.
! LIB_PATH=${LIB_PATH}:`echo ${libdir} | sed -e s'|/lib$||'`/${target_alias}/lib
  
  LIB_SEARCH_DIRS=`echo ${LIB_PATH} | tr ':' ' ' | sed -e 's/\([^ ][^ ]*\)/SEARCH_DIR(\1);/g'`
  
--- 54,65 ----
  fi
  
  # Always search $(tooldir)/lib, aka /usr/local/TARGET/lib.
! if [ $DEFAULT_EMULATION = $EMULATION_NAME ]; then
!   LIB_PATH=${LIB_PATH}:`echo ${libdir} | sed -e s'|/lib$||'`/${target_alias}/lib
! else
!   # This is not correct one since this is for a different target.
!   LIB_PATH=`echo ${libdir} | sed -e s'|/lib$||'`/${target_alias}/lib
! fi
  
  LIB_SEARCH_DIRS=`echo ${LIB_PATH} | tr ':' ' ' | sed -e 's/\([^ ][^ ]*\)/SEARCH_DIR(\1);/g'`
  
===================================================================
RCS file: /home/cvs/gnu/binutils/ld/ldfile.c,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 ldfile.c
*** 1.1.1.3	1995/04/15 00:06:18
--- ldfile.c	1995/05/03 00:46:00
***************
*** 68,74 ****
  static search_arch_type *search_arch_head;
  static search_arch_type **search_arch_tail_ptr = &search_arch_head;
   
! static boolean try_open_bfd PARAMS ((const char *attempt,
  				     lang_input_statement_type *entry));
  static FILE *try_open PARAMS ((const char *name, const char *exten));
  
--- 68,74 ----
  static search_arch_type *search_arch_head;
  static search_arch_type **search_arch_tail_ptr = &search_arch_head;
   
! boolean try_open_bfd PARAMS ((const char *attempt,
  				     lang_input_statement_type *entry));
  static FILE *try_open PARAMS ((const char *name, const char *exten));
  
***************
*** 89,95 ****
  
  /* Try to open a BFD for a lang_input_statement.  */
  
! static boolean
  try_open_bfd (attempt, entry)
       const char *attempt;
       lang_input_statement_type *entry;
--- 89,95 ----
  
  /* Try to open a BFD for a lang_input_statement.  */
  
! boolean
  try_open_bfd (attempt, entry)
       const char *attempt;
       lang_input_statement_type *entry;
***************
*** 183,189 ****
  	   arch != (search_arch_type *) NULL;
  	   arch = arch->next)
  	{
! 	  if (config.dynamic_link)
  	    {
  	      if (ldemul_open_dynamic_archive (arch->name, entry))
  		return;
--- 183,189 ----
  	   arch != (search_arch_type *) NULL;
  	   arch = arch->next)
  	{
! 	  if (entry->dynamic_link)
  	    {
  	      if (ldemul_open_dynamic_archive (arch->name, entry))
  		return;
===================================================================
RCS file: /home/cvs/gnu/binutils/ld/ldlang.h,v
retrieving revision 1.1.1.2
diff -c -r1.1.1.2 ldlang.h
*** 1.1.1.2	1995/02/22 02:02:31
--- ldlang.h	1995/05/03 00:46:01
***************
*** 229,234 ****
--- 229,237 ----
    asection *common_section;
    asection *common_output_section;
    boolean complained;
+ 
+   /* This is used to overwrite the global one. */
+   boolean dynamic_link;
  } lang_input_statement_type;
  
  typedef struct
===================================================================
RCS file: /home/cvs/gnu/binutils/ld/lexsup.c,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 lexsup.c
*** 1.1.1.3	1995/03/24 02:20:43
--- lexsup.c	1995/05/03 03:43:14
***************
*** 53,58 ****
--- 53,60 ----
  {
    int ingroup = 0;
  
+   boolean last_is_dynamic_link = config.dynamic_link;
+ 
    /* Starting the short option string with '-' is for programs that
       expect options and other ARGV-elements in any order and that care about
       the ordering of the two.  We describe each non-option ARGV-element
***************
*** 193,201 ****
--- 195,205 ----
  	  break;
  	case OPTION_CALL_SHARED:
  	  config.dynamic_link = true;
+ 	  last_is_dynamic_link = true;
  	  break;
  	case OPTION_NON_SHARED:
  	  config.dynamic_link = false;
+ 	  last_is_dynamic_link = false;
  	  break;
  	case 'd':
  	  command_line.force_common_definition = true;
***************
*** 246,252 ****
  	  break;
  	case 'l':
  	  lang_add_input_file (optarg, lang_input_file_is_l_enum,
! 			       (char *) NULL);
  	  break;
  	case 'M':
  	  config.map_filename = "-";
--- 250,257 ----
  	  break;
  	case 'l':
  	  lang_add_input_file (optarg, lang_input_file_is_l_enum,
! 			       (char *) NULL)->dynamic_link
! 			       = last_is_dynamic_link;
  	  break;
  	case 'M':
  	  config.map_filename = "-";
===================================================================
RCS file: /home/cvs/gnu/binutils/ld/config/i386-linux.mt,v
retrieving revision 1.1.1.2
diff -c -r1.1.1.2 i386-linux.mt
*** 1.1.1.2	1995/04/01 00:53:35
--- i386-linux.mt	1995/05/03 02:50:16
***************
*** 1,2 ****
--- 1,3 ----
  EMUL=elf_i386
  EMUL_EXTRA1=i386linux
+ NO_DEFAULT_WRITABLE_TEXT_SEGMENT=y
===================================================================
RCS file: /home/cvs/gnu/binutils/ld/emultempl/elf32.em,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 elf32.em
*** 1.1.1.3	1995/03/04 19:23:54
--- elf32.em	1995/05/03 00:46:03
***************
*** 43,48 ****
--- 43,55 ----
  #include "ldlang.h"
  #include "ldgram.h"
  
+  
+ /* FIXME: On some hosts we will need to include a different file.
+    This is correct for ELF/SVR4, which is the only place this file will
+    typically be compiled.  However, if somebody configures the linker
+    for all targets, they will run into trouble here.  */
+ #include <dirent.h>
+ 
  static void gld${EMULATION_NAME}_before_parse PARAMS ((void));
  static boolean gld${EMULATION_NAME}_open_dynamic_archive
    PARAMS ((const char *, lang_input_statement_type *));
***************
*** 55,60 ****
--- 62,71 ----
  static void gld${EMULATION_NAME}_place_section
    PARAMS ((lang_statement_union_type *));
  static char *gld${EMULATION_NAME}_get_script PARAMS ((int *isfile));
+ static boolean gld${EMULATION_NAME}_find_so PARAMS ((lang_input_statement_type *entry));
+ 
+ extern boolean try_open_bfd PARAMS ((const char *attempt,
+ 		lang_input_statement_type *entry));
  
  static void
  gld${EMULATION_NAME}_before_parse()
***************
*** 63,68 ****
--- 74,200 ----
    config.dynamic_link = ${DYNAMIC_LINK-true};
  }
  
+ /* figure out which library is greater */
+ static int libcmp(p1, p2)
+   char *p1, *p2;
+ {
+     while (*p1)
+     {
+ 	if (isdigit(*p1) && isdigit(*p2))
+ 	{
+ 	    /* must compare this numerically */
+ 	    int v1, v2;
+ 	    v1 = strtoul(p1, &p1, 10);
+ 	    v2 = strtoul(p2, &p2, 10);
+ 	    if (v1 != v2)
+ 		return v1 - v2;
+ 	}
+ 	else if (*p1 != *p2)
+ 	    return *p1 - *p2;
+ 	else
+ 	    p1++, p2++;
+     }
+ 
+     return *p1 - *p2;
+ }
+ 
+ /* Search for and open the .so file specified by ENTRY until
+    a match .so or .a file is found. H.J. */
+ static boolean
+ gld${EMULATION_NAME}_find_so (entry)
+      lang_input_statement_type *entry;
+ {
+   search_dirs_type *search;
+   char *filename;
+   unsigned int len;
+   char *found;
+   boolean found_static;
+ 
+   found_static = false;
+   found = NULL;
+   filename = (char *) entry->filename;
+   len = strlen (filename);
+   for (search = search_head;
+        search != (search_dirs_type *)NULL;
+        search = search->next) 
+   {
+     DIR *dir;
+     struct dirent *ent;
+ 
+     /* We try this directory. */
+     dir = opendir (search->name);
+     if (dir == NULL)
+       continue;
+ 
+     while ((ent = readdir (dir)) != NULL)
+     {
+       /* We are looking for libxxxx.*. */
+       if (ent->d_name [len + 3] != '.'
+ 	  || strncmp (ent->d_name, "lib", 3) != 0
+ 	  || strncmp (ent->d_name + 3, filename, len) != 0)
+ 	continue;
+ 
+       if (strncmp (ent->d_name + 3 + len, ".a", 2) == 0)
+       {
+ 	found_static = true;
+ 	continue;
+       }
+ 
+       if (strncmp (ent->d_name + 3 + len, ".so", 3) != 0)
+ 	continue;
+ 
+       /* We've found a lib*.so.x.x.x file. We compare it with the
+ 	 one we have found if there is one. */
+       if (found == NULL)
+       {
+ 	found = (char *) xmalloc (strlen (ent->d_name) + 1);
+ 	strcpy (found, ent->d_name);
+       }
+       else
+       {
+ 	if (libcmp (&ent->d_name [len + 6], &found [len + 6]) > 0)
+ 	{
+ 	  free (found);
+ 	  found = (char *) xmalloc (strlen (ent->d_name) + 1);
+ 	  strcpy (found, ent->d_name);
+ 	}
+       }
+     }
+ 
+     closedir (dir);
+ 
+     /* We find a shared or static library. */
+     if (found != NULL || found_static == true)
+       break;
+   }
+ 
+   if (found == NULL)
+   {
+     /* We did not find a matching .so file.  This isn't an error,
+        since there might still be a matching .a file, which will be
+        found by the usual search.  */
+     return false;
+   }
+ 
+   filename = (char *) xmalloc (strlen (search->name)
+ 	+ strlen (found) + 2);
+   sprintf (filename, "%s/%s", search->name, found);
+ 
+   free (found);
+ 
+   /* Give it a try */
+   if (try_open_bfd (filename, entry)) 
+   {
+     entry->filename = filename;
+     return true;
+   }
+   else
+   {
+     free (filename);
+     return false;
+   }
+ }
+ 
  /* Try to open a dynamic archive.  This is where we know that ELF
     dynamic libraries have an extension of .so.  */
  
***************
*** 71,81 ****
       const char *arch;
       lang_input_statement_type *entry;
  {
!   const char *filename;
! 
!   filename = entry->filename;
! 
!   if (! ldfile_open_file_search (arch, entry, "lib", ".so"))
      return false;
  
    /* We have found a dynamic object to include in the link.  The ELF
--- 203,209 ----
       const char *arch;
       lang_input_statement_type *entry;
  {
!   if (gld${EMULATION_NAME}_find_so (entry) == false)
      return false;
  
    /* We have found a dynamic object to include in the link.  The ELF
***************
*** 95,106 ****
        && (entry->the_bfd->flags & DYNAMIC) != 0)
      {
        char *needed_name;
  
        ASSERT (entry->is_archive && entry->search_dirs_flag);
!       needed_name = (char *) xmalloc (strlen (filename)
! 				      + strlen (arch)
! 				      + sizeof "lib.so");
!       sprintf (needed_name, "lib%s%s.so", filename, arch);
        bfd_elf_set_dt_needed_name (entry->the_bfd, needed_name);
      }
  
--- 223,236 ----
        && (entry->the_bfd->flags & DYNAMIC) != 0)
      {
        char *needed_name;
+       char *shlib;
  
        ASSERT (entry->is_archive && entry->search_dirs_flag);
! 
!       /* We may have /xxxxx/libxxxx.so.x.x.x. We only want the
!        * libxxx.so.x.x.x part. */
!       shlib = strrchr (entry->filename, '/');
!       needed_name = strdup (shlib ? shlib + 1 : entry->filename);
        bfd_elf_set_dt_needed_name (entry->the_bfd, needed_name);
      }
  
===================================================================
RCS file: /home/cvs/gnu/binutils/ld/scripttempl/elf.sc,v
retrieving revision 1.1.1.3
diff -c -r1.1.1.3 elf.sc
*** 1.1.1.3	1995/03/04 19:23:56
--- elf.sc	1995/05/03 02:50:17
***************
*** 26,31 ****
--- 26,36 ----
  test "$LD_FLAG" = "N" && DATA_ADDR=.
  INTERP=".interp   ${RELOCATING-0} : { *(.interp) 	}"
  PLT=".plt    ${RELOCATING-0} : { *(.plt)	}"
+ if [ x"${NO_DEFAULT_WRITABLE_TEXT_SEGMENT}" = "xy" -o x"${NO_DEFAULT_WRITABLE_TEXT_SEGMENT}" = "xY" ]; then
+   DATA_ALIGN="${DATA_ADDR-ALIGN(${MAXPAGESIZE}) + ((ALIGN(8) + ${MAXPAGESIZE} - ALIGN(${MAXPAGESIZE})) & (${MAXPAGESIZE} - 1))}"
+ else
+   DATA_ALIGN="${DATA_ADDR- ALIGN(8) + ${MAXPAGESIZE}}"
+ fi
  cat <<EOF
  OUTPUT_FORMAT("${OUTPUT_FORMAT}", "${BIG_OUTPUT_FORMAT}",
  	      "${LITTLE_OUTPUT_FORMAT}")
***************
*** 101,107 ****
       important than losing a page of the virtual address space (note
       that no actual memory is lost; the page which is skipped can not
       be referenced).  */
!   ${RELOCATING+. = ${DATA_ADDR- ALIGN(8) + ${MAXPAGESIZE}};}
  
    .data  ${RELOCATING-0} :
    {
--- 106,112 ----
       important than losing a page of the virtual address space (note
       that no actual memory is lost; the page which is skipped can not
       be referenced).  */
!   ${RELOCATING+. = ${DATA_ALIGN};}
  
    .data  ${RELOCATING-0} :
    {



From hjl@nynexst.com  Sat May  6 09:23:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Sat, 06 May 1995 09:23:00 -0000
Subject: a strip bug fix
Message-ID: <9505061619.AA04935@titanic.nynexst.com>

Sat May  6 08:52:24 1995  H.J. Lu (hjl@nynexst.com)

	* objcopy.c (smart_rename): make it smarter, clean up
	  if rename () fails.

diff -c gnu/binutils/binutils/objcopy.c:1.1.1.5 gnu/binutils/binutils/objcopy.c:1.1.1.5.2.1
*** gnu/binutils/binutils/objcopy.c:1.1.1.5	Sat May  6 11:12:32 1995
--- gnu/binutils/binutils/objcopy.c	Sat May  6 11:12:32 1995
***************
*** 1326,1331 ****
--- 1326,1340 ----
  	  chmod (to, s.st_mode & 07777);
  	  chown (to, s.st_uid, s.st_gid);
  	}
+       else
+ 	{
+ 	  /* We have to clean up here. */
+ 	  int saved = errno;
+ 	  fprintf (stderr, "%s: `%s': ", program_name, to);
+ 	  errno = saved;
+ 	  perror ("rename");
+ 	  unlink (from);
+ 	}
      }
    else
      {



From raeburn@cygnus.com  Wed May 24 19:52:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Wed, 24 May 1995 19:52:00 -0000
Subject: gas for m68k elf
Message-ID: <9505250252.AA03541@cujo.cygnus.com>

Is anyone willing and able to do some testing (and maybe a little
debugging) for a 68k-elf configuration for gas?  I need someone with
access to a 68k-elf system that isn't using GNU tools as the native
tools, for comparison.

Ken



From rms@labri.u-bordeaux.fr  Thu May 25 11:54:00 1995
From: rms@labri.u-bordeaux.fr (Richard Stallman)
Date: Thu, 25 May 1995 11:54:00 -0000
Subject: gas for m68k elf
References: <9505250252.AA03541@cujo.cygnus.com>
Message-ID: <9505251853.AA01197@waves>

What is the progress on fixing the GAS bug that is blocking
the shared libraries for the Hurd?

I hope you are working on that, and not solely on the 68k-elf
configuration.  That is useful but not urgently necessary.






From raeburn@cygnus.com  Thu May 25 14:14:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Thu, 25 May 1995 14:14:00 -0000
Subject: gas for m68k elf
References: <9505251853.AA01197@waves>
Message-ID: <9505252114.AA05214@cujo.cygnus.com>

   From: Richard Stallman <rms@labri.u-bordeaux.fr>
   Date: Thu, 25 May 95 17:37:00 +0200

   What is the progress on fixing the GAS bug that is blocking
   the shared libraries for the Hurd?

I described the bug in Roland's assembly code, and how it could be
determined from the symptoms, in mail I sent yesterday afternoon.  I
checked in a change to detect that specific case and warn about it
last night, a couple of hours before I sent this mail.

   I hope you are working on that, and not solely on the 68k-elf
   configuration.  That is useful but not urgently necessary.

Perhaps not to the FSF, but it is to Cygnus.

In fact, the m68k-elf work has been done for a while, but I've had a
bug report on it from someone on the net, who looked over the code,
but doesn't have access to a machine to try it on either.  Instead,
I've been working on some MIPS code I was supposed to ship to a
customer some time ago.



From rms@labri.u-bordeaux.fr  Thu May 25 15:16:00 1995
From: rms@labri.u-bordeaux.fr (Richard Stallman)
Date: Thu, 25 May 1995 15:16:00 -0000
Subject: gas for m68k elf
References: <9505252114.AA05214@cujo.cygnus.com>
Message-ID: <9505252215.AA02174@waves>

    I described the bug in Roland's assembly code, and how it could be
    determined from the symptoms, in mail I sent yesterday afternoon.

Good.

I hadn't yet heard that this was solved.



From baford@fast.cs.utah.edu  Fri Jun  2 09:42:00 1995
From: baford@fast.cs.utah.edu (Bryan Ford)
Date: Fri, 02 Jun 1995 09:42:00 -0000
Subject: GAS patches for i386-msdos and i386-moss
Message-ID: <199506021642.KAA19668@fast.cs.utah.edu>

(As requested, I'm submitting separate patches for the different
parts of the gas/binutils collection.)

Here are some minor patches to GAS-950602;
they add a new target `i386-moss', which is a DOS extender
I'll be releasing shortly (I'd like to have support for it in
the main binutils distribution by the time I release it).
These patches also fib some minor problems in the MS-DOS target.

Note: the first patch is to the top-level config.sub file, not to a gas file.

Thanks!

				Bryan


diff -crN gas-950602-old/config.sub gas-950602/config.sub
*** gas-950602-old/config.sub	Fri Jun  2 02:31:00 1995
--- gas-950602/config.sub	Fri Jun  2 08:32:47 1995
***************
*** 801,807 ****
  	-gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \
  	      | -vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[345]* \
  	      | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \
! 	      | -amigados* | -msdos* | -newsos* | -unicos* | -aos* \
  	      | -nindy* | -vxworks* | -ebmon* | -hms* | -mvs* | -clix* \
  	      | -riscos* | -linux* | -uniplus* | -iris* | -rtu* | -xenix* \
  	      | -hiux* | -386bsd* | -netbsd* | -freebsd* | -riscix*  | -lites* \
--- 801,807 ----
  	-gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \
  	      | -vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[345]* \
  	      | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \
! 	      | -amigados* | -msdos* | -moss* | -newsos* | -unicos* | -aos* \
  	      | -nindy* | -vxworks* | -ebmon* | -hms* | -mvs* | -clix* \
  	      | -riscos* | -linux* | -uniplus* | -iris* | -rtu* | -xenix* \
  	      | -hiux* | -386bsd* | -netbsd* | -freebsd* | -riscix*  | -lites* \
diff -crN gas-950602-old/gas/ChangeLog gas-950602/gas/ChangeLog
*** gas-950602-old/gas/ChangeLog	Fri Jun  2 02:27:26 1995
--- gas-950602/gas/ChangeLog	Fri Jun  2 08:32:48 1995
***************
*** 528,533 ****
--- 528,537 ----
  	* config/obj-elf.h (OUTPUT_FLAVOR): Define.
  
  
+ Sun May  7 11:53:41 MDT 1995  Bryan Ford  <baford@cs.utah.edu>
+ 
+ 	* configure.in: Added i386-*-moss* target.
+ 
  Thu Apr 27 20:07:33 1995  Doug Evans  <dje@canuck.cygnus.com>
  
  	* Makefile.in (RUNTEST): Use one in srcdir if present.
diff -crN gas-950602-old/gas/configure gas-950602/gas/configure
*** gas-950602-old/gas/configure	Fri Jun  2 02:27:28 1995
--- gas-950602/gas/configure	Fri Jun  2 08:38:08 1995
***************
*** 702,707 ****
--- 702,708 ----
        i386-*-mach* | i386-*-gnu*)
  			    fmt=aout em=mach bfd_gas=yes ;;
        i386-*-msdos*)        fmt=aout ;;
+       i386-*-moss*)	    fmt=elf ;;
        i386-*-pe)            fmt=coff targ=i386coff em=pe ;;
        i386-*-*nt)           fmt=coff targ=i386coff em=pe ;;
        i960-*-bout)          fmt=bout ;;
diff -crN gas-950602-old/gas/configure.in gas-950602/gas/configure.in
*** gas-950602-old/gas/configure.in	Fri Jun  2 02:27:27 1995
--- gas-950602/gas/configure.in	Fri Jun  2 08:39:24 1995
***************
*** 175,180 ****
--- 175,181 ----
        i386-*-mach* | i386-*-gnu*)
  			    fmt=aout em=mach bfd_gas=yes ;;
        i386-*-msdos*)        fmt=aout ;;
+       i386-*-moss*)	    fmt=elf ;;
        i386-*-pe)            fmt=coff targ=i386coff em=pe ;;
        i386-*-*nt)           fmt=coff targ=i386coff em=pe ;;
        i960-*-bout)          fmt=bout ;;







From baford@schirf.cs.utah.edu  Fri Jun  2 10:14:00 1995
From: baford@schirf.cs.utah.edu (Bryan Ford)
Date: Fri, 02 Jun 1995 10:14:00 -0000
Subject: LD patches: i386-msdos and i386-moss targets
Message-ID: <199506021722.LAA10839@schirf.cs.utah.edu>

(As requested, I'm submitting separate patches for the different
parts of the gas/binutils collection.
What's the appropriat list for GNU ld patches?)

Here are some very simple patches to GNU ld-950602.
They add a new target `i386-msdos', to go along with the
corresponding target already in bfd and gas.
They also add a new target `i386-moss', which is a DOS extender
I'll be releasing shortly (I'd like to have support for it in
the main binutils distribution by the time I release it).

Thanks!

				Bryan


diff -crN gas-950602-old/ld/ChangeLog gas-950602/ld/ChangeLog
*** gas-950602-old/ld/ChangeLog	Fri Jun  2 02:29:57 1995
--- gas-950602/ld/ChangeLog	Fri Jun  2 08:32:49 1995
***************
*** 78,83 ****
--- 78,92 ----
  
  	* configure.in (hppa*-*-lites*): Handle like hppa*-*-*elf*.
  
+ Sun May  7 11:53:41 MDT 1995  Bryan Ford  <baford@cs.utah.edu>
+ 
+ 	* configure.in (i386-*-msdos*, i386-*-moss*): New targets.
+ 	* Makefile.in (ALL_EMULATIONS): Added i386msdos.o.
+ 	(i386msdos.o): New target.
+ 	* config/i386-msdos.mt: Created.
+ 	* emulparams/i386msdos.sh: Created.
+ 	* scripttempl/i386msdos.sc: Created.
+ 
  Mon Apr 24 19:21:02 1995  Michael Meissner  <meissner@cygnus.com>
  
  	* ldwrite.c (ldwrite): Before doing anything, reset the error
diff -crN gas-950602-old/ld/Makefile.in gas-950602/ld/Makefile.in
*** gas-950602-old/ld/Makefile.in	Fri Jun  2 02:29:59 1995
--- gas-950602/ld/Makefile.in	Fri Jun  2 08:32:49 1995
***************
*** 201,206 ****
--- 201,207 ----
  	eh8300h.o eh8500.o eh8500b.o eh8500c.o eh8500m.o eh8500s.o \
  	ehp300bsd.o ehp3hpux.o ehppaelf.o ei386aout.o ei386bsd.o \
  	ei386coff.o ei386go32.o ei386linux.o ei386lynx.o ei386mach.o \
+ 	ei386moss.o ei386msdos.o \
  	ei386nbsd.o ei386nw.o elnk960.o em68kaout.o em68kcoff.o em68kelf.o \
  	em68klynx.o em68knbsd.o em88kbcs.o emipsbig.o emipsbsd.o \
  	emipsidt.o emipsidtl.o emipslit.o enews.o ens32knbsd.o eppcnw.o \
***************
*** 319,324 ****
--- 320,331 ----
  ei386mach.c: $(srcdir)/emulparams/i386mach.sh \
    $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS}
  	${GENSCRIPTS} i386mach
+ ei386moss.c: $(srcdir)/emulparams/i386moss.sh \
+   $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/elf.sc ${GEN_DEPENDS}
+ 	${GENSCRIPTS} i386moss
+ ei386msdos.c: $(srcdir)/emulparams/i386msdos.sh \
+   $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/i386msdos.sc ${GEN_DEPENDS}
+ 	${GENSCRIPTS} i386msdos
  eebmon29k.c: $(srcdir)/emulparams/ebmon29k.sh \
    $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/ebmon29k.sc ${GEN_DEPENDS}
  	${GENSCRIPTS} ebmon29k
diff -crN gas-950602-old/ld/config/i386-moss.mt gas-950602/ld/config/i386-moss.mt
*** gas-950602-old/ld/config/i386-moss.mt	Wed Dec 31 17:00:00 1969
--- gas-950602/ld/config/i386-moss.mt	Fri Jun  2 08:32:49 1995
***************
*** 0 ****
--- 1,2 ----
+ EMUL=i386moss
+ EMUL_EXTRA1=i386msdos
diff -crN gas-950602-old/ld/config/i386-msdos.mt gas-950602/ld/config/i386-msdos.mt
*** gas-950602-old/ld/config/i386-msdos.mt	Wed Dec 31 17:00:00 1969
--- gas-950602/ld/config/i386-msdos.mt	Fri Jun  2 08:32:49 1995
***************
*** 0 ****
--- 1,2 ----
+ EMUL=i386msdos
+ EMUL_EXTRA1=i386aout
diff -crN gas-950602-old/ld/configure.in gas-950602/ld/configure.in
*** gas-950602-old/ld/configure.in	Fri Jun  2 02:29:58 1995
--- gas-950602/ld/configure.in	Fri Jun  2 08:42:57 1995
***************
*** 82,87 ****
--- 82,89 ----
    i[345]86-*-mach*)	ld_target=i386-mach ;;
    i[345]86-*-gnuelf*)	ld_target=i386-gelf ;;
    i[345]86-*-gnu*)	ld_target=i386-gnu ;;
+   i[345]86-*-msdos*)	ld_target=i386-msdos ;;
+   i[345]86-*-moss*)	ld_target=i386-moss ;;
    i[345]86-*-winnt)	ld_target=i386-pe ;;
    i[345]86-*-pe)	ld_target=i386-pe ;;
    m8*-*-*)		ld_target=m88k-bcs ;;
diff -crN gas-950602-old/ld/emulparams/i386moss.sh gas-950602/ld/emulparams/i386moss.sh
*** gas-950602-old/ld/emulparams/i386moss.sh	Wed Dec 31 17:00:00 1969
--- gas-950602/ld/emulparams/i386moss.sh	Fri Jun  2 08:32:49 1995
***************
*** 0 ****
--- 1,9 ----
+ SCRIPT_NAME=elf
+ OUTPUT_FORMAT="elf32-i386"
+ TEXT_START_ADDR=0x00002000
+ MAXPAGESIZE=0x1000
+ NONPAGED_TEXT_START_ADDR=0x00002000
+ ARCH=i386
+ NOP=0x9090
+ TEMPLATE_NAME=elf32
+ GENERATE_SHLIB_SCRIPT=yes
diff -crN gas-950602-old/ld/emulparams/i386msdos.sh gas-950602/ld/emulparams/i386msdos.sh
*** gas-950602-old/ld/emulparams/i386msdos.sh	Wed Dec 31 17:00:00 1969
--- gas-950602/ld/emulparams/i386msdos.sh	Fri Jun  2 08:32:49 1995
***************
*** 0 ****
--- 1,7 ----
+ SCRIPT_NAME=i386msdos
+ OUTPUT_FORMAT="msdos"
+ TEXT_START_ADDR=0x0
+ NONPAGED_TEXT_START_ADDR=0x0
+ SEGMENT_SIZE=0x10
+ PAD_TEXT=t
+ ARCH=i386
diff -crN gas-950602-old/ld/scripttempl/i386msdos.sc gas-950602/ld/scripttempl/i386msdos.sc
*** gas-950602-old/ld/scripttempl/i386msdos.sc	Wed Dec 31 17:00:00 1969
--- gas-950602/ld/scripttempl/i386msdos.sc	Fri Jun  2 08:32:49 1995
***************
*** 0 ****
--- 1,40 ----
+ cat <<EOF
+ OUTPUT_FORMAT("${OUTPUT_FORMAT}")
+ OUTPUT_ARCH(${ARCH})
+ 
+ ${RELOCATING+${LIB_SEARCH_DIRS}}
+ ${STACKZERO+${RELOCATING+${STACKZERO}}}
+ SECTIONS
+ {
+   ${RELOCATING+. = ${TEXT_START_ADDR};}
+   .text :
+   {
+     CREATE_OBJECT_SYMBOLS
+     *(.text)
+     ${RELOCATING+etext = .;}
+     ${RELOCATING+_etext = .;}
+     ${RELOCATING+__etext = .;}
+     ${PAD_TEXT+${RELOCATING+. = ${DATA_ALIGNMENT};}}
+   }
+   ${RELOCATING+. = ${DATA_ALIGNMENT};}
+   .rodata  ${RELOCATING-0} : { *(.rodata)  }
+   .data :
+   {
+     *(.data)
+     ${CONSTRUCTING+CONSTRUCTORS}
+     ${RELOCATING+edata  =  .;}
+     ${RELOCATING+_edata  =  .;}
+     ${RELOCATING+__edata  =  .;}
+   }
+   .bss :
+   {
+    ${RELOCATING+ _bss_start = .};
+    ${RELOCATING+ __bss_start = .};
+    *(.bss)
+    *(COMMON)
+    ${RELOCATING+end = ALIGN(4) };
+    ${RELOCATING+_end = ALIGN(4) };
+    ${RELOCATING+__end = ALIGN(4) };
+   }
+ }
+ EOF


				Bryan
---
Bryan Ford	baford@cs.utah.edu	University of Utah, CSS
`finger baford@schirf.cs.utah.edu' for PGP key and other info.





From dj@delorie.com  Fri Jun  2 16:49:00 1995
From: dj@delorie.com (DJ Delorie)
Date: Fri, 02 Jun 1995 16:49:00 -0000
Subject: LD patches: i386-msdos and i386-moss targets
References: <199506021722.LAA10839@schirf.cs.utah.edu>
Message-ID: <199506022347.TAA14959@delorie.com>

Please be careful not to confuse the i386-moss work with i386-go32 or
i386-djgpp work, which is also a dos extender that runs under ms-dos
and uses binutils, but uses the COFF support instead of ELF.  Anything
that says "msdos" should be appropriate for ALL ms-dos systems, not
just the moss system.  If it will only help moss, use the word "moss"
in the name.

DJ



From baford@schirf.cs.utah.edu  Sat Jun  3 07:36:00 1995
From: baford@schirf.cs.utah.edu (Bryan Ford)
Date: Sat, 03 Jun 1995 07:36:00 -0000
Subject: LD patches: i386-msdos and i386-moss targets 
References: <199506022347.TAA14959@delorie.com>
Message-ID: <199506031444.IAA21714@schirf.cs.utah.edu>

>Please be careful not to confuse the i386-moss work with i386-go32 or
>i386-djgpp work, which is also a dos extender that runs under ms-dos
>and uses binutils, but uses the COFF support instead of ELF.  Anything
>that says "msdos" should be appropriate for ALL ms-dos systems, not
>just the moss system.  If it will only help moss, use the word "moss"
>in the name.

The i386-msdos target is not for any DOS extender at all; it's for
creating plain 16-bit ("unextended") MS-DOS executables.

				Bryan



From hjl@nynexst.com  Wed Jun 14 07:05:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Wed, 14 Jun 1995 07:05:00 -0000
Subject: bfd assertion failed with gcc 950607
References: <18151.9506140906@afs.mcc.ac.uk>
Message-ID: <9506141358.AA09429@titanic.nynexst.com>

> 
> > Please apply this patch to binutils 2.5.2l.17 and let me know what you
> > get.
> 
> After applying your patch, I have some sensible error messages.
> This is the smallest case I have been able to produce.  I give
> you the two source files, Makefile, the .s files produced
> en route, and the log giving the assertion failures.  Note that
> this did not happen with the previous snapshots.  I am using
> the ldscripts from your binutils distribution, not those
> produced when recompiling binutils.
> 
>      -- Owen
>      LeBlanc@mcc.ac.uk
> 

How should we treat common and weak symbols? I don't know what I
am doing. But I think I am right. The ld on Solaris doesn't
complain. Could someone please take a look at this patch?

Thanks.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
-----
*** bfd.c.orig	Mon Jun 12 12:47:53 1995
--- ./bfd.c	Mon Jun 12 13:17:15 1995
***************
*** 638,643 ****
--- 638,657 ----
  }
  
  
+ void
+ bfd_assert_symbol(file, line, symbol)
+ char *file;
+ int line;
+ char *symbol;
+ {
+   if (symbol)
+     fprintf(stderr, "bfd assertion fail %s:%d due to symbol: `%s'. possible cause:\n\tmismatched types in library and program.\n",
+ 	file,line,symbol);
+   else
+     fprintf(stderr, "bfd assertion fail %s:%d\n",file,line);
+ }
+ 
+ 
  /*
  FUNCTION
  	bfd_set_start_address
*** elf32-i386.c.orig	Mon Jun 12 12:18:15 1995
--- ./elf32-i386.c	Wed Jun 14 09:46:07 1995
***************
*** 607,613 ****
    dynobj = elf_hash_table (info)->dynobj;
  
    /* Make sure we know what is going on here.  */
!   BFD_ASSERT (dynobj != NULL
  	      && ((h->elf_link_hash_flags & ELF_LINK_HASH_NEEDS_PLT)
  		  || ((h->elf_link_hash_flags
  		       & ELF_LINK_HASH_DEF_DYNAMIC) != 0
--- 607,613 ----
    dynobj = elf_hash_table (info)->dynobj;
  
    /* Make sure we know what is going on here.  */
!   BFD_ASSERT_SYMBOL (dynobj != NULL
  	      && ((h->elf_link_hash_flags & ELF_LINK_HASH_NEEDS_PLT)
  		  || ((h->elf_link_hash_flags
  		       & ELF_LINK_HASH_DEF_DYNAMIC) != 0
***************
*** 618,627 ****
  		      && (elf_elfheader (h->root.u.def.section->owner)->e_type
  			  == ET_DYN)
  		      && (h->root.type == bfd_link_hash_defined
  			  || h->root.type == bfd_link_hash_defweak)
  		      && (bfd_get_flavour (h->root.u.def.section->owner)
  			  == bfd_target_elf_flavour)
! 		      && h->root.u.def.section->output_section == NULL)));
  
    /* If this is a function, put it in the procedure linkage table.  We
       will fill in the contents of the procedure linkage table later,
--- 618,629 ----
  		      && (elf_elfheader (h->root.u.def.section->owner)->e_type
  			  == ET_DYN)
  		      && (h->root.type == bfd_link_hash_defined
+ 			  || h->root.type == bfd_link_hash_common
  			  || h->root.type == bfd_link_hash_defweak)
  		      && (bfd_get_flavour (h->root.u.def.section->owner)
  			  == bfd_target_elf_flavour)
! 		      && h->root.u.def.section->output_section == NULL)),
! 		      h->root.root.string);
  
    /* If this is a function, put it in the procedure linkage table.  We
       will fill in the contents of the procedure linkage table later,
*** elfcode.h.orig	Mon Jun 12 12:44:56 1995
--- ./elfcode.h	Wed Jun 14 09:45:25 1995
***************
*** 4712,4719 ****
        weaks = hlook->weakdef;
        hlook->weakdef = NULL;
  
!       BFD_ASSERT (hlook->root.type == bfd_link_hash_defined
! 		  || hlook->root.type == bfd_link_hash_defweak);
        slook = hlook->root.u.def.section;
        vlook = hlook->root.u.def.value;
  
--- 4712,4721 ----
        weaks = hlook->weakdef;
        hlook->weakdef = NULL;
  
!       BFD_ASSERT_SYMBOL (hlook->root.type == bfd_link_hash_defined
! 		  || hlook->root.type == bfd_link_hash_common
! 		  || hlook->root.type == bfd_link_hash_defweak,
! 		  hlook->root.root.string);
        slook = hlook->root.u.def.section;
        vlook = hlook->root.u.def.value;
  
*** libbfd-in.h.orig	Mon Jun 12 12:46:59 1995
--- ./libbfd-in.h	Mon Jun 12 12:53:18 1995
***************
*** 402,409 ****
--- 402,414 ----
  
  void	bfd_assert PARAMS ((char*,int));
  
+ void	bfd_assert_symbol PARAMS ((char*,int,char*));
+ 
  #define BFD_ASSERT(x) \
  { if (!(x)) bfd_assert(__FILE__,__LINE__); }
+ 
+ #define BFD_ASSERT_SYMBOL(x,s) \
+ { if (!(x)) bfd_assert_symbol(__FILE__,__LINE__,s); }
  
  #define BFD_FAIL() \
  { bfd_assert(__FILE__,__LINE__); }
*** libbfd.h.orig	Mon Apr 17 19:38:23 1995
--- ./libbfd.h	Mon Jun 12 13:02:56 1995
***************
*** 402,409 ****
--- 402,414 ----
  
  void	bfd_assert PARAMS ((char*,int));
  
+ void	bfd_assert_symbol PARAMS ((char*,int,char*));
+ 
  #define BFD_ASSERT(x) \
  { if (!(x)) bfd_assert(__FILE__,__LINE__); }
+ 
+ #define BFD_ASSERT_SYMBOL(x,s) \
+ { if (!(x)) bfd_assert_symbol(__FILE__,__LINE__,s); }
  
  #define BFD_FAIL() \
  { bfd_assert(__FILE__,__LINE__); }
------
#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#		"End of shell archive."
# Contents:  Makefile foo.c fred.c junk.c log
# Wrapped by hjl@jalod on Wed Jun 14 09:58:00 1995
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'Makefile' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'Makefile'\"
else
echo shar: Extracting \"'Makefile'\" \(188 characters\)
sed "s/^X//" >'Makefile' <<'END_OF_FILE'
XCC=gcc -v -b i486-linux
X
Xall:	junk
X
Xjunk:	junk.o fred.o libfoo.so
X	$(CC) -o $@ junk.o fred.o -lfoo -L.
X
Xlibfoo.so: foo.c
X	$(CC) -shared -o $@ -fPIC foo.c
X
Xclean:
X	rm -rf junk *.o *.s *.so
END_OF_FILE
if test 188 -ne `wc -c <'Makefile'`; then
    echo shar: \"'Makefile'\" unpacked with wrong size!
fi
# end of 'Makefile'
fi
if test -f 'foo.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'foo.c'\"
else
echo shar: Extracting \"'foo.c'\" \(52 characters\)
sed "s/^X//" >'foo.c' <<'END_OF_FILE'
X#pragma weak fooo=_fooo
X
Xint _fooo = 0;
X
Xfoo ()
X{
X}
END_OF_FILE
if test 52 -ne `wc -c <'foo.c'`; then
    echo shar: \"'foo.c'\" unpacked with wrong size!
fi
# end of 'foo.c'
fi
if test -f 'fred.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'fred.c'\"
else
echo shar: Extracting \"'fred.c'\" \(10 characters\)
sed "s/^X//" >'fred.c' <<'END_OF_FILE'
Xint fooo;
END_OF_FILE
if test 10 -ne `wc -c <'fred.c'`; then
    echo shar: \"'fred.c'\" unpacked with wrong size!
fi
# end of 'fred.c'
fi
if test -f 'junk.c' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'junk.c'\"
else
echo shar: Extracting \"'junk.c'\" \(57 characters\)
sed "s/^X//" >'junk.c' <<'END_OF_FILE'
Xextern int fooo;
Xvoid main(void)
X{
X  fooo=0;
X  foo ();
X}
END_OF_FILE
if test 57 -ne `wc -c <'junk.c'`; then
    echo shar: \"'junk.c'\" unpacked with wrong size!
fi
# end of 'junk.c'
fi
if test -f 'log' -a "${1}" != "-c" ; then 
  echo shar: Will not clobber existing file \"'log'\"
else
echo shar: Extracting \"'log'\" \(4649 characters\)
sed "s/^X//" >'log' <<'END_OF_FILE'
Xgcc -v -b i486-linux    -c junk.c -o junk.o
XReading specs from /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/specs
Xgcc driver version 2.6.4 snapshot 950305 executing gcc version 2.6.4
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) -D__i486__ junk.c /usr/tmp/cca02276.i
XGNU CPP version 2.6.4 snapshot 950305 (i386 Linux/ELF)
X#include "..." search starts here:
X#include <...> search starts here:
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/include
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/sys-include
X /usr/gnu/i486-linux/include
XEnd of search list.
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/cc1 /usr/tmp/cca02276.i -quiet -dumpbase junk.c -version -o /usr/tmp/cca02276.s
XGNU C version 2.6.4 snapshot 950305 (i386 Linux/ELF) compiled by GNU C version 2.6.4 snapshot 950305.
X /usr/gnu/i486-linux/bin/as -V -Qy -o junk.o /usr/tmp/cca02276.s
XGNU assembler version 950421 (i486-linuxelf), using BFD version cygnus-2.5
Xgcc -v -b i486-linux    -c fred.c -o fred.o
XReading specs from /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/specs
Xgcc driver version 2.6.4 snapshot 950305 executing gcc version 2.6.4
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) -D__i486__ fred.c /usr/tmp/cca02280.i
XGNU CPP version 2.6.4 snapshot 950305 (i386 Linux/ELF)
X#include "..." search starts here:
X#include <...> search starts here:
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/include
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/sys-include
X /usr/gnu/i486-linux/include
XEnd of search list.
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/cc1 /usr/tmp/cca02280.i -quiet -dumpbase fred.c -version -o /usr/tmp/cca02280.s
XGNU C version 2.6.4 snapshot 950305 (i386 Linux/ELF) compiled by GNU C version 2.6.4 snapshot 950305.
X /usr/gnu/i486-linux/bin/as -V -Qy -o fred.o /usr/tmp/cca02280.s
XGNU assembler version 950421 (i486-linuxelf), using BFD version cygnus-2.5
Xgcc -v -b i486-linux -shared -o libfoo.so -fPIC foo.c
XReading specs from /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/specs
Xgcc driver version 2.6.4 snapshot 950305 executing gcc version 2.6.4
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/cpp -lang-c -v -undef -D__GNUC__=2 -D__GNUC_MINOR__=6 -D__ELF__ -Dunix -Di386 -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__i386 -D__linux -Asystem(unix) -Asystem(posix) -Acpu(i386) -Amachine(i386) -D__PIC__ -D__pic__ -D__i486__ foo.c /usr/tmp/cca02284.i
XGNU CPP version 2.6.4 snapshot 950305 (i386 Linux/ELF)
X#include "..." search starts here:
X#include <...> search starts here:
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/include
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/sys-include
X /usr/gnu/i486-linux/include
XEnd of search list.
X /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/cc1 /usr/tmp/cca02284.i -quiet -dumpbase foo.c -version -fPIC -o /usr/tmp/cca02284.s
XGNU C version 2.6.4 snapshot 950305 (i386 Linux/ELF) compiled by GNU C version 2.6.4 snapshot 950305.
X /usr/gnu/i486-linux/bin/as -V -Qy -o /usr/tmp/cca022841.o /usr/tmp/cca02284.s
XGNU assembler version 950421 (i486-linuxelf), using BFD version cygnus-2.5
X /usr/gnu/i486-linux/bin/ld -m elf_i386 -shared -o libfoo.so /usr/gnu/i486-linux/lib/crti.o /usr/gnu/i486-linux/lib/crtbeginS.o -L/usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305 -L/usr/gnu/i486-linux/lib /usr/tmp/cca022841.o /usr/gnu/i486-linux/lib/crtendS.o /usr/gnu/i486-linux/lib/crtn.o
Xgcc -v -b i486-linux -o junk junk.o fred.o -lfoo -L.
XReading specs from /usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305/specs
Xgcc driver version 2.6.4 snapshot 950305 executing gcc version 2.6.4
X /usr/gnu/i486-linux/bin/ld -m elf_i386 -dynamic-linker /lib/elf/ld-linux.so.1 -rpath /lib/elf/ -o junk /usr/gnu/i486-linux/lib/crt1.o /usr/gnu/i486-linux/lib/crti.o /usr/gnu/i486-linux/lib/crtbegin.o -L. -L/usr/gnu/lib/gcc-lib/i486-linux/2.6.4-950305 -L/usr/gnu/i486-linux/lib junk.o fred.o -lfoo -lgcc -lc -lgcc /usr/gnu/i486-linux/lib/crtend.o /usr/gnu/i486-linux/lib/crtn.o
Xbfd assertion fail /home/titanic/hjl/gnu/gas/binutils-2.5.2l.17/bfd/elfcode.h:4717 due to symbol: `fooo'. possible cause:
X	mismatched types in library and program.
Xbfd assertion fail /home/titanic/hjl/gnu/gas/binutils-2.5.2l.17/bfd/elf32-i386.c:625 due to symbol: `fooo'. possible cause:
X	mismatched types in library and program.
END_OF_FILE
if test 4649 -ne `wc -c <'log'`; then
    echo shar: \"'log'\" unpacked with wrong size!
fi
# end of 'log'
fi
echo shar: End of shell archive.
exit 0



From roland@gnu.ai.mit.edu  Wed Jun 14 09:08:00 1995
From: roland@gnu.ai.mit.edu (Roland McGrath)
Date: Wed, 14 Jun 1995 09:08:00 -0000
Subject: bfd assertion failed with gcc 950607
References: <9506141358.AA09429@titanic.nynexst.com>
Message-ID: <199506141608.MAA09776@churchy.gnu.ai.mit.edu>

I am certain that your test case is a valid program and that the references
to `fooo' in junk.c should resolve to the common defn in fred.c rather than
to `_fooo' in foo.c.

So if that is what your patches accomplish, I would say they might be
right.  I don't think there is anyone available this month who really
understands ld well enough to be sure if that is the best way to fix it.



From hjl@nynexst.com  Wed Jun 14 09:43:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Wed, 14 Jun 1995 09:43:00 -0000
Subject: bfd assertion failed with gcc 950607
References: <199506141608.MAA09776@churchy.gnu.ai.mit.edu>
Message-ID: <9506141636.AA11264@titanic.nynexst.com>

> 
> I am certain that your test case is a valid program and that the references
> to `fooo' in junk.c should resolve to the common defn in fred.c rather than
> to `_fooo' in foo.c.

No. Solaris uses `_fooo' in foo.c. The GNU ld does the samething.
It just complains about it.

> 
> So if that is what your patches accomplish, I would say they might be

No, my patches only turn off the complaints.

> right.  I don't think there is anyone available this month who really
> understands ld well enough to be sure if that is the best way to fix it.
> 


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From roland@gnu.ai.mit.edu  Wed Jun 14 09:51:00 1995
From: roland@gnu.ai.mit.edu (Roland McGrath)
Date: Wed, 14 Jun 1995 09:51:00 -0000
Subject: bfd assertion failed with gcc 950607
References: <9506141636.AA11264@titanic.nynexst.com>
Message-ID: <199506141651.MAA09865@churchy.gnu.ai.mit.edu>

> > 
> > I am certain that your test case is a valid program and that the references
> > to `fooo' in junk.c should resolve to the common defn in fred.c rather than
> > to `_fooo' in foo.c.
> 
> No. Solaris uses `_fooo' in foo.c. The GNU ld does the samething.
> It just complains about it.

That is contrary to the specification of the SVR4 ABI, page 4-27:
"Similarly, if a common symbol exists (i.e., a symbol whose st_shndx field
holds SHN_COMMON), the appearance of a weak symbol with the same name will
not cause an error.  The link editor honors the common definition and
ignores the weak ones."



From hjl@nynexst.com  Wed Jun 14 14:26:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Wed, 14 Jun 1995 14:26:00 -0000
Subject: bfd assertion failed with gcc 950607
References: <199506141651.MAA09865@churchy.gnu.ai.mit.edu>
Message-ID: <9506142119.AA19611@titanic.nynexst.com>

> 
> > > 
> > > I am certain that your test case is a valid program and that the references
> > > to `fooo' in junk.c should resolve to the common defn in fred.c rather than
> > > to `_fooo' in foo.c.
> > 
> > No. Solaris uses `_fooo' in foo.c. The GNU ld does the samething.

I take it back. The GNU ld does right thing. But it just complains
about. I don't have a right fix it. I don't want to hack the code.
Basically a common symbol is very tricky. Although the GNU ELF
linker handles it right, BFD_ASSERT in elf32-i386.c around
625 doesn't take it into account.

> > It just complains about it.
> 
> That is contrary to the specification of the SVR4 ABI, page 4-27:
> "Similarly, if a common symbol exists (i.e., a symbol whose st_shndx field
> holds SHN_COMMON), the appearance of a weak symbol with the same name will
> not cause an error.  The link editor honors the common definition and
> ignores the weak ones."
> 


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From raeburn@cygnus.com  Wed Jun 14 14:37:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Wed, 14 Jun 1995 14:37:00 -0000
Subject: bfd assertion failed with gcc 950607
References: <199506141651.MAA09865@churchy.gnu.ai.mit.edu>
Message-ID: <9506142137.AA32237@cujo.cygnus.com>

   Date: Wed, 14 Jun 1995 12:51:39 -0400
   From: Roland McGrath <roland@gnu.ai.mit.edu>

   > No. Solaris uses `_fooo' in foo.c. The GNU ld does the samething.
   > It just complains about it.

   That is contrary to the specification of the SVR4 ABI, page 4-27:
   "Similarly, if a common symbol exists (i.e., a symbol whose st_shndx field
   holds SHN_COMMON), the appearance of a weak symbol with the same name will
   not cause an error.  The link editor honors the common definition and
   ignores the weak ones."

The paragraph you quote starts with "When the link editor combines
several relocatable object files...."  So a shared library should be
treated like a random .o file, instead of like an archive library?
That seems counterintuitive.  Is a shared library really considered a
"relocatable object file"?

The ABI description doesn't seem all that clear to me, actually.  At
the start of chapter 4, it's described as a third type of object file,
distinct from relocatable files and executable files.



From hjl@nynexst.com  Wed Jun 14 15:17:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Wed, 14 Jun 1995 15:17:00 -0000
Subject: bfd assertion failed with gcc 950607
References: <9506142137.AA32237@cujo.cygnus.com>
Message-ID: <9506142209.AA21867@titanic.nynexst.com>

> 
> 
>    Date: Wed, 14 Jun 1995 12:51:39 -0400
>    From: Roland McGrath <roland@gnu.ai.mit.edu>
> 
>    > No. Solaris uses `_fooo' in foo.c. The GNU ld does the samething.
>    > It just complains about it.
> 
>    That is contrary to the specification of the SVR4 ABI, page 4-27:
>    "Similarly, if a common symbol exists (i.e., a symbol whose st_shndx field
>    holds SHN_COMMON), the appearance of a weak symbol with the same name will
>    not cause an error.  The link editor honors the common definition and
>    ignores the weak ones."
> 
> The paragraph you quote starts with "When the link editor combines
> several relocatable object files...."  So a shared library should be
> treated like a random .o file, instead of like an archive library?
> That seems counterintuitive.  Is a shared library really considered a
> "relocatable object file"?
> 
> The ABI description doesn't seem all that clear to me, actually.  At
> the start of chapter 4, it's described as a third type of object file,
> distinct from relocatable files and executable files.
> 

The current GNU ELF ld does what was quoted by Roland from SVR4 ABI.
It honors the common symbol instead of the weak one in shared
libraries. BFD_ASSEET just complains something which ld can handle
but not expected by BFD_ASSEET.

-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From dj@delorie.com  Thu Jun 15 20:17:00 1995
From: dj@delorie.com (DJ Delorie)
Date: Thu, 15 Jun 1995 20:17:00 -0000
Subject: binutils minor bugs wrt posix
Message-ID: <199506160317.XAA10532@delorie.com>

In building binutils with DJGPP V2, which is much more posix-strict, I
encountered these problems:

gprof/gprof.c:342: Cast to u_char used, variable is declared as
"unsigned char" in header, u_char used nowhere else in sources.

gas/obj-format.c:2977: cast param of time() to (long *) and not
(time_t *).

DJ



From hjl@nynexst.com  Sat Jun 17 13:09:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Sat, 17 Jun 1995 13:09:00 -0000
Subject: ld, ld.so and -symbolic
References: <199506170044.RAA29582@www.willows.com>
Message-ID: <9506172001.AA19867@titanic.nynexst.com>

> 
> This may not be the right place to ask, but before I go off talking to the
> gnu people, I thought I'd start here specifically as this is an elf issue.  
> 
> The question has to do with the -symbolic option that gcc man pages say is
> a linker option, but ld does not seem to support.  My understanding on sun
> solaris is that the -Bsymbolic option  allows me to have two, or more, shared 
> objects that can have there own global variables, that won't conflict with 
> other variables of the same name.  The question I have is, is this supported,
> can it be supported, when, how, how much?
> 

I would like to see that is supported in ld. How hard
is it? I don't think that should be very hard. Am I
wrong?

-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From dj@delorie.com  Sat Jun 17 14:58:00 1995
From: dj@delorie.com (DJ Delorie)
Date: Sat, 17 Jun 1995 14:58:00 -0000
Subject: Lxx vs .Lxxx - gcc vs gas
Message-ID: <199506172158.RAA25682@delorie.com>

[Be careful when replying; this was sent to two mailing lists - DJ]

There are two types of "local" labels used by gcc and gas:

(1)	Lfoo:
(2)	.Lfoo:

gcc chooses which to use based on whether the target prepends an
underscore to external symbols or not.

gas chooses which to use based on whether the output object format is
COFF or not (for the i386, at least).

DJGPP is coff with underscores, and the two don't agree on which is
right, so I end up with all the local labels in the object's symbol
table.

Which should I fix?  Is there a global solution, or will I need a
special case for djgpp?

DJ
dj@delorie.com



From raeburn@cygnus.com  Sat Jun 17 16:33:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Sat, 17 Jun 1995 16:33:00 -0000
Subject: Lxx vs .Lxxx - gcc vs gas
References: <199506172158.RAA25682@delorie.com>
Message-ID: <9506172333.AA16800@cujo.cygnus.com>

It's a gas bug.  I'll fix it.



From rfg@segfault.us.com  Sat Jun 17 17:00:00 1995
From: rfg@segfault.us.com (Ronald F. Guilmette)
Date: Sat, 17 Jun 1995 17:00:00 -0000
Subject: Lxx vs .Lxxx - gcc vs gas 
References: <199506172158.RAA25682@delorie.com>
Message-ID: <26871.803433382@segfault>

In message < 199506172158.RAA25682@delorie.com >, you wrote:

>
>[Be careful when replying; this was sent to two mailing lists - DJ]
>
>There are two types of "local" labels used by gcc and gas:
>
>(1)	Lfoo:
>(2)	.Lfoo:
>
>gcc chooses which to use based on whether the target prepends an
>underscore to external symbols or not.

I'm not sure if that is a proper way to make the distinction, but it
might be.  Then again, it might not.

What I _can_ tell you is that the convention on ELF-based systems is
_not_ to put an underscore before a user-declared identifier (when
converting it from the C level to the assembly level).  This differs
from the older UNIX tradition of putting one underscore in front of
each user-declared name (at the assembly level).

I believe that for most COFF-based systems, the convention was to prepend
a leading underscore to the names of all entities which were declared by
the user at the C-language level.  (But I might be wrong about that.  It
has been a LONG time since I used COFF.)

Separately, there is the question of what prefix will force the assembler
NOT to write a given label into the symbol table of the object file.  In
the case of all ELF assemblers that I am familiar with, a leading period
will cause the relevant label NOT to appear in the symbol table of the
resulting object file... but these conventions are highly assembler-
dependent, and I don't knon that there is any hard-and-fast rule by
which you could predict (for any given assembler) what the ``hiding
prefix'' is.  You just have to try some experiments and see.

>gas chooses which to use based on whether the output object format is
>COFF or not (for the i386, at least).

I think that's probably wrong.  If you had said that GAS uses leading
periods as the ``hiding prefix'' for _both_ COFF and ELF, then I might
believe that gas was doing the Right Thing.  Even then however, I think
that the wisest thing to do (in _both_ gas and gcc) would be to establish
an entirely separate and independent target macro to control/determine
the ``hiding prefix''.

>DJGPP is coff with underscores, and the two don't agree on which is
>right, so I end up with all the local labels in the object's symbol
>table.
>
>Which should I fix?  Is there a global solution, or will I need a
>special case for djgpp?

See above.  I think that _somebody_ should fix both gas and gcc so that
the assembly-level ``hiding prefix'' can be specified independently from
everything else.  I really don't think that there is 100% correlation
between the object file format and the hiding prefix.  Any correlations
which seem to relate one to the other are, I believe, simply the product
of luck rather than the product of universal rules or universally obeyed
conventions.


-- Ron Guilmette, Sunnyvale, CA -------- RG Consulting ---------------------
---- E-mail: rfg@segfault.us.com --------Purveyors of Compiler Test Suites -
---- finger: rfg@rahul.net -------------------------------------------------



From pk@cs.few.eur.nl  Sun Jun 18 03:40:00 1995
From: pk@cs.few.eur.nl (Paul Kranenburg)
Date: Sun, 18 Jun 1995 03:40:00 -0000
Subject: ld, ld.so and -symbolic
References: <9506172001.AA19867@titanic.nynexst.com>
Message-ID: <9506181040.AA00218@cs.few.eur.nl>

> > The question has to do with the -symbolic option that gcc man pages say is
> > a linker option, but ld does not seem to support.  My understanding on sun
> > solaris is that the -Bsymbolic option  allows me to have two, or more, shared 
> > objects that can have there own global variables, that won't conflict with 
> > other variables of the same name.  The question I have is, is this supported,
> > can it be supported, when, how, how much?

You'd have to make sure that 1) all symbols get resolved, i.e. no
references to undefined remain in the shared object, and 2) all
remaining relocation records are of the type "relative to load address".
The latter is a hard requirement if you have to bootstrap a la "ld.so".

You'll need to have a library handy from which you can pull in all
required PIC modules, e.g. say "libc_pic.a" (in stead of "libc.so.x.y").

-pk

From hjl@nynexst.com  Sun Jun 18 08:14:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Sun, 18 Jun 1995 08:14:00 -0000
Subject: ld, ld.so and -symbolic
References: <9506181040.AA00218@cs.few.eur.nl>
Message-ID: <9506181506.AA25882@titanic.nynexst.com>

> 
> > > The question has to do with the -symbolic option that gcc man pages say is
> > > a linker option, but ld does not seem to support.  My understanding on sun
> > > solaris is that the -Bsymbolic option  allows me to have two, or more, shared 
> > > objects that can have there own global variables, that won't conflict with 
> > > other variables of the same name.  The question I have is, is this supported,
> > > can it be supported, when, how, how much?
> 
> You'd have to make sure that 1) all symbols get resolved, i.e. no
> references to undefined remain in the shared object, and 2) all
> remaining relocation records are of the type "relative to load address".
> The latter is a hard requirement if you have to bootstrap a la "ld.so".
> 
> You'll need to have a library handy from which you can pull in all
> required PIC modules, e.g. say "libc_pic.a" (in stead of "libc.so.x.y").
> 

Are we talking about the same thing? BTW, you don't have to use
-Bsymbolic when you build ld.so.

-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
-----
    -B symbolic  In dynamic mode only, when  building  a  shared
                 object,  bind  references  to  global symbols to
                 their definitions within the object, if  defini-
                 tions  are  available.   Normally, references to
                 global symbols within  shared  objects  are  not
                 bound  until  runtime,  even  if definitions are
                 available, so that definitions of the same  sym-
                 bol in an executable or other shared objects can
                 override the object's own definition.   ld  will
                 issue  warnings  for undefined symbols unless -z
                 defs overrides.




From roland@gnu.ai.mit.edu  Sun Jun 18 10:16:00 1995
From: roland@gnu.ai.mit.edu (Roland McGrath)
Date: Sun, 18 Jun 1995 10:16:00 -0000
Subject: ld, ld.so and -symbolic
References: <9506172001.AA19867@titanic.nynexst.com>
Message-ID: <199506181716.NAA13804@churchy.gnu.ai.mit.edu>

In ELF there is a simple feature that if a DT_SYMBOLIC element appears in a
shared object's dynamic section, then when resolving references within that
shared object, the dynamic linker will give that object's own definitions
first precedence, followed by the executable and other loaded shared
objects (the normal order being the executable followed by all loaded
shared objects).  I believe GNU ld already has a -symbolic switch that
creates the DT_SYMBOLIC element when building a shared object (though I
could be mistaken).



From hjl@nynexst.com  Mon Jun 19 07:01:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 19 Jun 1995 07:01:00 -0000
Subject: DT_SYMBOLIC and -Bsymbolic
Message-ID: <9506191353.AA03701@titanic.nynexst.com>

Hi,

Do the current binutils snapshots and the Linux ELF dynamic
linker support DT_SYMBOLIC? It should be easy to add -Bsymbolic
to ld. The Linux ELF dynamic linker just needs to check the
presence of DT_SYMBOLIC in the shared library to control the
symbol binding. It is specified in the ELF doc, ELF.doc.tar.gz,
on tsx-11 and sunsite in the linux gcc directory


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From eric@aib.com  Mon Jun 19 07:42:00 1995
From: eric@aib.com (Eric Youngdale)
Date: Mon, 19 Jun 1995 07:42:00 -0000
Subject: DT_SYMBOLIC and -Bsymbolic
References: <9506191353.AA03701@titanic.nynexst.com>
Message-ID: <9506191041.ZM12711@aib.com>

On Jun 19,  9:58am, H.J. Lu wrote:
> Subject: DT_SYMBOLIC and -Bsymbolic
> Hi,
>
> Do the current binutils snapshots and the Linux ELF dynamic
> linker support DT_SYMBOLIC? It should be easy to add -Bsymbolic
> to ld. The Linux ELF dynamic linker just needs to check the
> presence of DT_SYMBOLIC in the shared library to control the
> symbol binding. It is specified in the ELF doc, ELF.doc.tar.gz,
> on tsx-11 and sunsite in the linux gcc directory

	I doubt that this is handled at all - I never added support for it,
so unless Ian did it, there is probably nothing.  The good news is that it
would not be that hard to add.

-Eric


-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."



From hjl@nynexst.com  Mon Jun 19 08:01:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 19 Jun 1995 08:01:00 -0000
Subject: DT_SYMBOLIC and -Bsymbolic
References: <9506191041.ZM12711@aib.com>
Message-ID: <9506191453.AA04291@titanic.nynexst.com>

> 
> On Jun 19,  9:58am, H.J. Lu wrote:
> > Subject: DT_SYMBOLIC and -Bsymbolic
> > Hi,
> >
> > Do the current binutils snapshots and the Linux ELF dynamic
> > linker support DT_SYMBOLIC? It should be easy to add -Bsymbolic
> > to ld. The Linux ELF dynamic linker just needs to check the
> > presence of DT_SYMBOLIC in the shared library to control the
> > symbol binding. It is specified in the ELF doc, ELF.doc.tar.gz,
> > on tsx-11 and sunsite in the linux gcc directory
> 
> 	I doubt that this is handled at all - I never added support for it,
> so unless Ian did it, there is probably nothing.  The good news is that it
> would not be that hard to add.

That is what I thought. While I am on it, let me ask one more
question :-(. Is DT_TEXTREL supported? Or should it be?


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From eric@aib.com  Mon Jun 19 08:13:00 1995
From: eric@aib.com (Eric Youngdale)
Date: Mon, 19 Jun 1995 08:13:00 -0000
Subject: DT_SYMBOLIC and -Bsymbolic
References: <9506191453.AA04291@titanic.nynexst.com>
Message-ID: <9506191109.ZM13867@aib.com>

On Jun 19, 10:58am, H.J. Lu wrote:
> That is what I thought. While I am on it, let me ask one more
> question :-(. Is DT_TEXTREL supported? Or should it be?


	Yes.  This one should only occur if you attempt to create
a shared library from non-PIC code, as the .text section will then
need to have relocations applied.  The DT_TEXTREL tells the dynamic
loader that it needs to mprotect the .text section to make it writable
before applying relocations, and once we are through, we need to set
them back again.

	The dynamic loader should be doing this correctly -
someone did accidentally make a shared library from non-PIC code
as I recall.  They were complaining that dynamic linking was broken
(not surprising), but it worked otherwise, which would tend to suggest
that the linker is inserting DT_TEXTREL and the dynamic loader is
doing the right thing with it.

	I am trying to grab the latest binutils sources -  I will take
a look at DT_SYMBOLIC.

-Eric

-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."



From eric@aib.com  Mon Jun 19 14:54:00 1995
From: eric@aib.com (Eric Youngdale)
Date: Mon, 19 Jun 1995 14:54:00 -0000
Subject: DT_SYMBOLIC and -Bsymbolic
References: <9506191453.AA04291@titanic.nynexst.com>
Message-ID: <9506191708.ZM25348@aib.com>

On Jun 19, 10:58am, H.J. Lu wrote:
> Subject: Re: DT_SYMBOLIC and -Bsymbolic
> >
> > On Jun 19,  9:58am, H.J. Lu wrote:
> > > Subject: DT_SYMBOLIC and -Bsymbolic
> > > Hi,
> > >
> > > Do the current binutils snapshots and the Linux ELF dynamic
> > > linker support DT_SYMBOLIC? It should be easy to add -Bsymbolic
> > > to ld. The Linux ELF dynamic linker just needs to check the
> > > presence of DT_SYMBOLIC in the shared library to control the
> > > symbol binding. It is specified in the ELF doc, ELF.doc.tar.gz,
> > > on tsx-11 and sunsite in the linux gcc directory

	OK, I have patches to add this.  I basically assumed that all
that we needed to do was to translate -Bsymbolic on the link line into
DT_SYBMOLIC in the .dynamic section, and nothing more than that.  I tested
it with a small example, and it seemed to work.

-Eric




-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

From eric@aib.com  Mon Jun 19 15:21:00 1995
From: eric@aib.com (Eric Youngdale)
Date: Mon, 19 Jun 1995 15:21:00 -0000
Subject: DT_SYMBOLIC and -Bsymbolic
References: <9506191353.AA03701@titanic.nynexst.com>
Message-ID: <9506191820.ZM27067@aib.com>

	Hmm, I was looking at the man page for Solaris - my implementation
of
-Bsymbolic does not quite match what they suggest.  I was thinking that this
would be something that we could implement at runtime through patches to the
dynamic loader, but my guess is that we need to modify the real linker
behavior for this to work correctly.

-Eric


-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."



From hjl@nynexst.com  Mon Jun 19 17:55:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 19 Jun 1995 17:55:00 -0000
Subject: DT_SYMBOLIC and -Bsymbolic
References: <9506191820.ZM27067@aib.com>
Message-ID: <9506200047.AA09538@titanic.nynexst.com>

> 
> 
> 	Hmm, I was looking at the man page for Solaris - my implementation
> of
> -Bsymbolic does not quite match what they suggest.  I was thinking that this
> 

I think your change to ld is in the right directory. We just need
to make ld issue some warnings for unresolved references when
-Bsymbolic is used. Your change just works as under Solaris when
the messages are turned off.

> would be something that we could implement at runtime through patches to the
> dynamic loader, but my guess is that we need to modify the real linker
> behavior for this to work correctly.
> 

We do need to patch the dynamic linker to support DT_SYMBOLIC.


H.J.



From hjl@nynexst.com  Mon Jun 19 18:48:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 19 Jun 1995 18:48:00 -0000
Subject: A minor change
Message-ID: <9506200140.AA09821@titanic.nynexst.com>

This is for Eric's patch.

-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
----
*** bfd/elfcode.h.new	Mon Jun 19 21:27:50 1995
--- bfd/elfcode.h	Mon Jun 19 21:37:29 1995
***************
*** 5200,5206 ****
  	    return false;
  	}      
  
!       if (symbolic
  	  && ! elf_add_dynamic_entry (info, DT_SYMBOLIC, 0))
  	    return false;
  
--- 5200,5206 ----
  	    return false;
  	}      
  
!       if (info->shared && symbolic
  	  && ! elf_add_dynamic_entry (info, DT_SYMBOLIC, 0))
  	    return false;
  



From hjl@nynexst.com  Mon Jun 19 20:23:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 19 Jun 1995 20:23:00 -0000
Subject: A small patch for gas
Message-ID: <9506200315.AA10332@titanic.nynexst.com>

Hi,

I have to use this. Otherwise

# configure i486-linux --prefix=/usr --enable-targets=i386-elf,i386-linux,i386-coff

will fail.

H.J.
----
*** /users/import/gas-950618/gas/configure	Sun Jun 18 04:23:03 1995
--- gas/configure	Mon Jun 19 23:17:52 1995
***************
*** 557,563 ****
    armeb)	cpu_type=arm endian=big ;;
    arm*)		cpu_tpye=arm endian=little ;;
    hppa*)	cpu_type=hppa ;;
!   i[45]86)	cpu_type=i386 ;;
    m680[012346]0) cpu_type=m68k ;;
    m68008)	cpu_type=m68k ;;
    m683??)       cpu_type=m68k ;;
--- 557,563 ----
    armeb)	cpu_type=arm endian=big ;;
    arm*)		cpu_tpye=arm endian=little ;;
    hppa*)	cpu_type=hppa ;;
!   i[345]86)	cpu_type=i386 ;;
    m680[012346]0) cpu_type=m68k ;;
    m68008)	cpu_type=m68k ;;
    m683??)       cpu_type=m68k ;;
***************
*** 624,630 ****
      # check for architecture variants
      case ${cpu} in
        hppa*)		cpu_type=hppa ;;
!       i[45]86)		cpu_type=i386 ;;
        m680[012346]0)	cpu_type=m68k ;;
        m68008)		cpu_type=m68k ;;
        m683??)		cpu_type=m68k ;;
--- 624,630 ----
      # check for architecture variants
      case ${cpu} in
        hppa*)		cpu_type=hppa ;;
!       i[345]86)		cpu_type=i386 ;;
        m680[012346]0)	cpu_type=m68k ;;
        m68008)		cpu_type=m68k ;;
        m683??)		cpu_type=m68k ;;



From eric@aib.com  Tue Jun 20 11:55:00 1995
From: eric@aib.com (Eric Youngdale)
Date: Tue, 20 Jun 1995 11:55:00 -0000
Subject: DT_SYMBOLIC and -Bsymbolic
References: <9506200047.AA09538@titanic.nynexst.com>
Message-ID: <9506201454.ZM27215@aib.com>

	OK, I think the enclosed patch is more along the lines of what is
required.  The general idea is that we bypass the PLT when -Bsymbolic is
in effect, and in addition the GOT slots have a different type of relocation
(R_*_RELATIVE instead of R_*_GLOB_DAT).  I updated both the Sparc and i386
backends (others would be easy, if other backends supported shared libs).

	From what I can tell the advantages of using this are that you
get slightly better performance at runtime since you do not go through the
PLT for every function call.  In addition, there is less startup overhead
since there are no PLT slots to be initialized.  The GOT slots still exist,
but the R_*_RELOCATION relocations do not have a symbol, so you do not
have to search any of the symbol tables to perform these relocations, and
there would be yet another very slight performance increase.

	The Solaris linker does put a DT_SYMBOLIC entry in the .dynamic
section, but I am not sure what it is used for.  It is possible that it
would be used in cases where you attempt to link non-PIC code into a
shared library, since you would still be emitting relocations to the
output file in this case.  Thus patches to the dynamic loader should still
be required.

	The drawbacks to using this flag are that the library is less
sharable.  In other words, the user cannot redefine functions in the
library and expect that their redefinition will work for calls to the
function from within the library.

	I vaguely recall a few months ago seeing a discussion between some
of the members of the ABI+ committee (who are charged with updating the
SVr4 ABI, and merging differences between Solaris and Unixware).  Apparently
some (but not all) SVr4 vendors are using -Bsymbolic with libc - apparently
for performance reasons.

	FWIW, I would recommend against ever using this switch except in
certain specific cases - people need to know exactly what they are doing
when they turn this one on, and they need to know the ramifications.

-Eric

-- 
"The woods are lovely, dark and deep.  But I have promises to keep,
And lines to code before I sleep, And lines to code before I sleep."

From baford@schirf.cs.utah.edu  Wed Jun 21 15:30:00 1995
From: baford@schirf.cs.utah.edu (Bryan Ford)
Date: Wed, 21 Jun 1995 15:30:00 -0000
Subject: Patches to BFD, GAS, and LD
Message-ID: <199506212231.QAA14567@schirf.cs.utah.edu>

Since I didn't get any response to the patches I submitted a few
weeks ago (and they weren't incorporated), here they are again, 
updated to the latest gas snapshot (gas-950621).
Note that there are patches for BFD, GAS, and LD in this message,
as well as a patch to the top-level config.sub file.  They are all
extremely simple and should not cause any merging problems.

Please confirm when these are merged into the main tree.
Thanks!
                              Bryan

diff -crN gas-950621-old/bfd/ChangeLog gas-950621/bfd/ChangeLog
*** gas-950621-old/bfd/ChangeLog	Wed Jun 21 02:18:53 1995
--- gas-950621/bfd/ChangeLog	Wed Jun 21 16:15:39 1995
***************
*** 295,300 ****
--- 295,304 ----
  	(TARGET_LITTLE_SYM, TARGET_LITTLE_NAME): Define, to provide little
  	endian support.
  
+ Sun May  7 11:53:41 MDT 1995  Bryan Ford  <baford@cs.utah.edu>
+ 
+ 	* config/i386-moss.mt: created.
+ 
  Tue May  2 16:32:24 1995  Jeff Law  (law@snake.cs.utah.edu)
  
  	* config.bfd (hppa*-*-lites*): Treat just like hppa*-*-*elf*.
diff -crN gas-950621-old/bfd/bfd-in2.h gas-950621/bfd/bfd-in2.h
*** gas-950621-old/bfd/bfd-in2.h	Wed Jun 21 02:18:57 1995
--- gas-950621/bfd/bfd-in2.h	Wed Jun 21 15:23:50 1995
***************
*** 2094,2100 ****
    bfd_target_srec_flavour,
    bfd_target_som_flavour,
    bfd_target_os9k_flavour,
!   bfd_target_versados_flavour
  };
  
   /* Forward declaration.  */
--- 2094,2101 ----
    bfd_target_srec_flavour,
    bfd_target_som_flavour,
    bfd_target_os9k_flavour,
!   bfd_target_versados_flavour,
!   bfd_target_msdos_flavour
  };
  
   /* Forward declaration.  */
diff -crN gas-950621-old/bfd/config/i386-moss.mt gas-950621/bfd/config/i386-mos
s.mt
*** gas-950621-old/bfd/config/i386-moss.mt	Wed Dec 31 17:00:00 1969
--- gas-950621/bfd/config/i386-moss.mt	Wed Jun 21 15:17:37 1995
***************
*** 0 ****
--- 1,5 ----
+ # Target:  Intel 386 running MOSS (Mach-based DOS extender)
+ 
+ DEFAULT_VECTOR=bfd_elf32_i386_vec
+ SELECT_VECS=i386msdos_vec i386aout_vec
+ SELECT_ARCHITECTURES=bfd_i386_arch
diff -crN gas-950621-old/bfd/config/i386-msdos.mt gas-950621/bfd/config/i386-ms
dos.mt
*** gas-950621-old/bfd/config/i386-msdos.mt	Mon Feb  6 01:31:54 1995
--- gas-950621/bfd/config/i386-msdos.mt	Wed Jun 21 15:17:38 1995
***************
*** 1,5 ****
  # Target:  Intel 386 running DOS
! 
! DEFAULT_VECTOR=i386msdos_vec
! SELECT_VECS=i386aout_vec
  SELECT_ARCHITECTURES=bfd_i386_arch
--- 1,8 ----
  # Target:  Intel 386 running DOS
! # Use a.out as the default vector,
! # because that's what we want to use for everything but linking
! # (i.e. for object files and libraries and all that).
! # Producing the final executable in MS-DOS format is handled by the linker.
! DEFAULT_VECTOR=i386aout_vec
! SELECT_VECS=i386msdos_vec
  SELECT_ARCHITECTURES=bfd_i386_arch
diff -crN gas-950621-old/bfd/config.bfd gas-950621/bfd/config.bfd
*** gas-950621-old/bfd/config.bfd	Wed Jun 21 02:18:56 1995
--- gas-950621/bfd/config.bfd	Wed Jun 21 15:17:38 1995
***************
*** 66,72 ****
    i[345]86-*-mach*)	bfd_name=i386-mach3 strip_underscore=yes ;;
    i[345]86-*-osf1mk*)	bfd_name=i386-mach3 strip_underscore=yes ;;
    i[345]86-*-os9k)	bfd_name=i386-os9k ;;
!   i[345]86-*-msdos)	bfd_name=i386-msdos ;;
    i[345]86-*-winnt)	bfd_name=i386-pe ;;
    i[345]86-*-pe)	bfd_name=i386-pe ;;
    i[345]86-none-*)	bfd_name=i386-coff ;;
--- 66,73 ----
    i[345]86-*-mach*)	bfd_name=i386-mach3 strip_underscore=yes ;;
    i[345]86-*-osf1mk*)	bfd_name=i386-mach3 strip_underscore=yes ;;
    i[345]86-*-os9k)	bfd_name=i386-os9k ;;
!   i[345]86-*-msdos*)	bfd_name=i386-msdos ;;
!   i[345]86-*-moss*)	bfd_name=i386-moss ;;
    i[345]86-*-winnt)	bfd_name=i386-pe ;;
    i[345]86-*-pe)	bfd_name=i386-pe ;;
    i[345]86-none-*)	bfd_name=i386-coff ;;
diff -crN gas-950621-old/bfd/i386msdos.c gas-950621/bfd/i386msdos.c
*** gas-950621-old/bfd/i386msdos.c	Fri Jun  9 18:05:53 1995
--- gas-950621/bfd/i386msdos.c	Wed Jun 21 15:27:06 1995
***************
*** 95,101 ****
    /* Find the total size of the program on disk and in memory.  */
    for (sec = abfd->sections; sec != (asection *) NULL; sec = sec->next)
      {
- printf("section %s: vma 0x%x size 0x%x\n", sec->name, sec->vma, sec->
_raw_size);
        if (bfd_get_section_flags (abfd, sec) & SEC_ALLOC)
          {
  	  bfd_vma sec_vma = bfd_get_section_vma (abfd, sec)
--- 95,100 ----
***************
*** 161,169 ****
  
    section->filepos = EXE_PAGE_SIZE + bfd_get_section_vma (abfd, section);
  
!   if (bfd_seek (abfd, (file_ptr) (section->filepos + offset), SEEK_SET) != 0
!       || bfd_write (location, 1, count, abfd) != count)
!     return false;
  
    return true;
  }
--- 160,171 ----
  
    section->filepos = EXE_PAGE_SIZE + bfd_get_section_vma (abfd, section);
  
!   if (bfd_get_section_flags (abfd, section) & SEC_LOAD)
!     {
!       if (bfd_seek (abfd, (file_ptr) (section->filepos + offset), SEEK_SET) 
!= 0
!           || bfd_write (location, 1, count, abfd) != count)
!         return false;
!     }
  
    return true;
  }
***************
*** 184,189 ****
--- 186,192 ----
  #define msdos_bfd_link_hash_table_create _bfd_generic_link_hash_table_create
  #define msdos_bfd_link_add_symbols _bfd_generic_link_add_symbols
  #define msdos_bfd_final_link _bfd_generic_final_link
+ #define msdos_bfd_link_split_section _bfd_generic_link_split_section
  #define msdos_set_arch_mach _bfd_generic_set_arch_mach
  
  #define msdos_get_symtab_upper_bound _bfd_nosymbols_get_symtab_upper_bound
diff -crN gas-950621-old/config.sub gas-950621/config.sub
*** gas-950621-old/config.sub	Wed Jun 21 02:25:56 1995
--- gas-950621/config.sub	Wed Jun 21 15:17:38 1995
***************
*** 801,807 ****
  	-gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \
  	      | -vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[345]* \
  	      | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \
! 	      | -amigados* | -msdos* | -newsos* | -unicos* | -aos* \
  	      | -nindy* | -vxworks* | -ebmon* | -hms* | -mvs* | -clix* \
  	      | -riscos* | -linux* | -uniplus* | -iris* | -rtu* | -xenix* \
  	      | -hiux* | -386bsd* | -netbsd* | -freebsd* | -riscix*  | -lites* \
--- 801,807 ----
  	-gnu* | -bsd* | -mach* | -minix* | -genix* | -ultrix* | -irix* \
  	      | -vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[345]* \
  	      | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \
! 	      | -amigados* | -msdos* | -moss* | -newsos* | -unicos* | -aos* \
  	      | -nindy* | -vxworks* | -ebmon* | -hms* | -mvs* | -clix* \
  	      | -riscos* | -linux* | -uniplus* | -iris* | -rtu* | -xenix* \
  	      | -hiux* | -386bsd* | -netbsd* | -freebsd* | -riscix*  | -lites* \
diff -crN gas-950621-old/gas/ChangeLog gas-950621/gas/ChangeLog
*** gas-950621-old/gas/ChangeLog	Wed Jun 21 02:22:30 1995
--- gas-950621/gas/ChangeLog	Wed Jun 21 15:17:38 1995
***************
*** 610,615 ****
--- 610,619 ----
  	* config/obj-elf.h (OUTPUT_FLAVOR): Define.
  
  
+ Sun May  7 11:53:41 MDT 1995  Bryan Ford  <baford@cs.utah.edu>
+ 
+ 	* configure.in: Added i386-*-moss* target.
+ 
  Thu Apr 27 20:07:33 1995  Doug Evans  <dje@canuck.cygnus.com>
  
  	* Makefile.in (RUNTEST): Use one in srcdir if present.
diff -crN gas-950621-old/gas/configure gas-950621/gas/configure
*** gas-950621-old/gas/configure	Wed Jun 21 02:22:32 1995
--- gas-950621/gas/configure	Wed Jun 21 15:17:39 1995
***************
*** 702,707 ****
--- 702,708 ----
        i386-*-mach*)
  			    fmt=aout em=mach bfd_gas=yes ;;
        i386-*-msdos*)        fmt=aout ;;
+       i386-*-moss*)	    fmt=elf ;;
        i386-*-pe)            fmt=coff targ=i386coff em=pe ;;
        i386-*-*nt)           fmt=coff targ=i386coff em=pe ;;
        i960-*-bout)          fmt=bout ;;
diff -crN gas-950621-old/gas/configure.in gas-950621/gas/configure.in
*** gas-950621-old/gas/configure.in	Wed Jun 21 02:22:31 1995
--- gas-950621/gas/configure.in	Wed Jun 21 15:17:39 1995
***************
*** 175,180 ****
--- 175,181 ----
        i386-*-mach*)
  			    fmt=aout em=mach bfd_gas=yes ;;
        i386-*-msdos*)        fmt=aout ;;
+       i386-*-moss*)	    fmt=elf ;;
        i386-*-pe)            fmt=coff targ=i386coff em=pe ;;
        i386-*-*nt)           fmt=coff targ=i386coff em=pe ;;
        i960-*-bout)          fmt=bout ;;
diff -crN gas-950621-old/ld/ChangeLog gas-950621/ld/ChangeLog
*** gas-950621-old/ld/ChangeLog	Wed Jun 21 02:25:02 1995
--- gas-950621/ld/ChangeLog	Wed Jun 21 15:17:39 1995
***************
*** 108,113 ****
--- 108,122 ----
  
  	* configure.in (hppa*-*-lites*): Handle like hppa*-*-*elf*.
  
+ Sun May  7 11:53:41 MDT 1995  Bryan Ford  <baford@cs.utah.edu>
+ 
+ 	* configure.in (i386-*-msdos*, i386-*-moss*): New targets.
+ 	* Makefile.in (ALL_EMULATIONS): Added i386msdos.o.
+ 	(i386msdos.o): New target.
+ 	* config/i386-msdos.mt: Created.
+ 	* emulparams/i386msdos.sh: Created.
+ 	* scripttempl/i386msdos.sc: Created.
+ 
  Mon Apr 24 19:21:02 1995  Michael Meissner  <meissner@cygnus.com>
  
  	* ldwrite.c (ldwrite): Before doing anything, reset the error
diff -crN gas-950621-old/ld/Makefile.in gas-950621/ld/Makefile.in
*** gas-950621-old/ld/Makefile.in	Wed Jun 21 02:25:03 1995
--- gas-950621/ld/Makefile.in	Wed Jun 21 15:17:39 1995
***************
*** 201,206 ****
--- 201,207 ----
  	eh8300h.o eh8500.o eh8500b.o eh8500c.o eh8500m.o eh8500s.o \
  	ehp300bsd.o ehp3hpux.o ehppaelf.o ei386aout.o ei386bsd.o \
  	ei386coff.o ei386go32.o ei386linux.o ei386lynx.o ei386mach.o \
+ 	ei386moss.o ei386msdos.o \
  	ei386nbsd.o ei386nw.o elnk960.o em68kaout.o em68kcoff.o em68kelf.o \
  	em68klynx.o em68knbsd.o em88kbcs.o emipsbig.o emipsbsd.o \
  	emipsidt.o emipsidtl.o emipslit.o enews.o ens32knbsd.o eppcnw.o \
***************
*** 319,324 ****
--- 320,331 ----
  ei386mach.c: $(srcdir)/emulparams/i386mach.sh \
    $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS}
  	${GENSCRIPTS} i386mach
+ ei386moss.c: $(srcdir)/emulparams/i386moss.sh \
+   $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/elf.sc ${GEN_DEPENDS}
+ 	${GENSCRIPTS} i386moss
+ ei386msdos.c: $(srcdir)/emulparams/i386msdos.sh \
+   $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/i386msdos.sc 
${GEN_DEPENDS}
+ 	${GENSCRIPTS} i386msdos
  eebmon29k.c: $(srcdir)/emulparams/ebmon29k.sh \
    $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/ebmon29k.sc 
${GEN_DEPENDS}
  	${GENSCRIPTS} ebmon29k
diff -crN gas-950621-old/ld/config/i386-moss.mt gas-950621/ld/config/i386-moss.
mt
*** gas-950621-old/ld/config/i386-moss.mt	Wed Dec 31 17:00:00 1969
--- gas-950621/ld/config/i386-moss.mt	Wed Jun 21 15:17:39 1995
***************
*** 0 ****
--- 1,2 ----
+ EMUL=i386moss
+ EMUL_EXTRA1=i386msdos
diff -crN gas-950621-old/ld/config/i386-msdos.mt gas-950621/ld/config/i386-msdo
s.mt
*** gas-950621-old/ld/config/i386-msdos.mt	Wed Dec 31 17:00:00 1969
--- gas-950621/ld/config/i386-msdos.mt	Wed Jun 21 15:17:39 1995
***************
*** 0 ****
--- 1,2 ----
+ EMUL=i386msdos
+ EMUL_EXTRA1=i386aout
diff -crN gas-950621-old/ld/configure.in gas-950621/ld/configure.in
*** gas-950621-old/ld/configure.in	Wed Jun 21 02:25:02 1995
--- gas-950621/ld/configure.in	Wed Jun 21 15:18:22 1995
***************
*** 81,86 ****
--- 81,88 ----
    i[345]86-*-sysv*)	ld_target=i386-coff ;;
    i[345]86-*-mach*)	ld_target=i386-mach ;;
    i[345]86-*-gnu*)	ld_target=i386-gelf ;;
+   i[345]86-*-msdos*)	ld_target=i386-msdos ;;
+   i[345]86-*-moss*)	ld_target=i386-moss ;;
    i[345]86-*-winnt)	ld_target=i386-pe ;;
    i[345]86-*-pe)	ld_target=i386-pe ;;
    m8*-*-*)		ld_target=m88k-bcs ;;
diff -crN gas-950621-old/ld/configure.in.rej gas-950621/ld/configure.in.rej
*** gas-950621-old/ld/configure.in.rej	Wed Dec 31 17:00:00 1969
--- gas-950621/ld/configure.in.rej	Wed Jun 21 15:17:40 1995
***************
*** 0 ****
--- 1,17 ----
+ ***************
+ *** 82,87 ****
+     i[345]86-*-mach*)	ld_target=i386-mach ;;
+     i[345]86-*-gnuelf*)	ld_target=i386-gelf ;;
+     i[345]86-*-gnu*)	ld_target=i386-gnu ;;
+     i[345]86-*-winnt)	ld_target=i386-pe ;;
+     i[345]86-*-pe)	ld_target=i386-pe ;;
+     m8*-*-*)		ld_target=m88k-bcs ;;
+ --- 82,89 ----
+     i[345]86-*-mach*)	ld_target=i386-mach ;;
+     i[345]86-*-gnuelf*)	ld_target=i386-gelf ;;
+     i[345]86-*-gnu*)	ld_target=i386-gnu ;;
+ +   i[345]86-*-msdos*)	ld_target=i386-msdos ;;
+ +   i[345]86-*-moss*)	ld_target=i386-moss ;;
+     i[345]86-*-winnt)	ld_target=i386-pe ;;
+     i[345]86-*-pe)	ld_target=i386-pe ;;
+     m8*-*-*)		ld_target=m88k-bcs ;;
diff -crN gas-950621-old/ld/emulparams/i386moss.sh 
gas-950621/ld/emulparams/i386moss.sh
*** gas-950621-old/ld/emulparams/i386moss.sh	Wed Dec 31 17:00:00 1969
--- gas-950621/ld/emulparams/i386moss.sh	Wed Jun 21 15:17:40 1995
***************
*** 0 ****
--- 1,9 ----
+ SCRIPT_NAME=elf
+ OUTPUT_FORMAT="elf32-i386"
+ TEXT_START_ADDR=0x00002000
+ MAXPAGESIZE=0x1000
+ NONPAGED_TEXT_START_ADDR=0x00002000
+ ARCH=i386
+ NOP=0x9090
+ TEMPLATE_NAME=elf32
+ GENERATE_SHLIB_SCRIPT=yes
diff -crN gas-950621-old/ld/emulparams/i386msdos.sh 
gas-950621/ld/emulparams/i386msdos.sh
*** gas-950621-old/ld/emulparams/i386msdos.sh	Wed Dec 31 17:00:00 1969
--- gas-950621/ld/emulparams/i386msdos.sh	Wed Jun 21 15:17:40 1995
***************
*** 0 ****
--- 1,7 ----
+ SCRIPT_NAME=i386msdos
+ OUTPUT_FORMAT="msdos"
+ TEXT_START_ADDR=0x0
+ NONPAGED_TEXT_START_ADDR=0x0
+ SEGMENT_SIZE=0x10
+ PAD_TEXT=t
+ ARCH=i386
diff -crN gas-950621-old/ld/scripttempl/i386msdos.sc 
gas-950621/ld/scripttempl/i386msdos.sc
*** gas-950621-old/ld/scripttempl/i386msdos.sc	Wed Dec 31 17:00:00 1969
--- gas-950621/ld/scripttempl/i386msdos.sc	Wed Jun 21 15:17:40 1995
***************
*** 0 ****
--- 1,40 ----
+ cat <<EOF
+ OUTPUT_FORMAT("${OUTPUT_FORMAT}")
+ OUTPUT_ARCH(${ARCH})
+ 
+ ${RELOCATING+${LIB_SEARCH_DIRS}}
+ ${STACKZERO+${RELOCATING+${STACKZERO}}}
+ SECTIONS
+ {
+   ${RELOCATING+. = ${TEXT_START_ADDR};}
+   .text :
+   {
+     CREATE_OBJECT_SYMBOLS
+     *(.text)
+     ${RELOCATING+etext = .;}
+     ${RELOCATING+_etext = .;}
+     ${RELOCATING+__etext = .;}
+     ${PAD_TEXT+${RELOCATING+. = ${DATA_ALIGNMENT};}}
+   }
+   ${RELOCATING+. = ${DATA_ALIGNMENT};}
+   .rodata  ${RELOCATING-0} : { *(.rodata)  }
+   .data :
+   {
+     *(.data)
+     ${CONSTRUCTING+CONSTRUCTORS}
+     ${RELOCATING+edata  =  .;}
+     ${RELOCATING+_edata  =  .;}
+     ${RELOCATING+__edata  =  .;}
+   }
+   .bss :
+   {
+    ${RELOCATING+ _bss_start = .};
+    ${RELOCATING+ __bss_start = .};
+    *(.bss)
+    *(COMMON)
+    ${RELOCATING+end = ALIGN(4) };
+    ${RELOCATING+_end = ALIGN(4) };
+    ${RELOCATING+__end = ALIGN(4) };
+   }
+ }
+ EOF


				Bryan
---
Bryan Ford	baford@cs.utah.edu	University of Utah, CSS
`finger baford@schirf.cs.utah.edu' for PGP key and other info.





From alan@spri.levels.unisa.edu.au  Wed Jun 21 16:43:00 1995
From: alan@spri.levels.unisa.edu.au (Alan Modra)
Date: Wed, 21 Jun 1995 16:43:00 -0000
Subject: Patches to BFD, GAS, and LD
References: <199506212231.QAA14567@schirf.cs.utah.edu>
Message-ID: <m0sOZQq-0000y0C@mullet>

> Since I didn't get any response to the patches I submitted a few
> weeks ago (and they weren't incorporated), here they are again, 

Patience, patience! :-)

The following one of mine still hasn't made it, but since it's an
improvement rather than a bug fix, I'm not too worried.

+Sat Apr 22 20:53:05 1995  Alan Modra  <alan@spri.levels.unisa.edu.au>
+
+       * config/tc-i386.h (md_do_align, HANDLE_ALIGN):  Add macros to
+       generate optimal multi-byte nop instructions for ".align n"

From alan@spri.levels.unisa.edu.au  Wed Jun 21 16:57:00 1995
From: alan@spri.levels.unisa.edu.au (Alan Modra)
Date: Wed, 21 Jun 1995 16:57:00 -0000
Subject: gas fixup problem?
Message-ID: <m0sOZeD-0000y0C@mullet>

/usr/i486-linux/bin/as zzz.s; nm a.out
00000000 t L0
00000006 t L1
00000002 t L2		!!!!!!!!!
00000006 t L3
00000015 t L4
00000094 t L5

 --------------------zzz.s----------------
	.text
L0:
	jz L5
L1:
L2:
L3:
	.space -(L2 - L0 + 0x7f) & (16-1), 0x90

L4:
	.space 0x7f, 0x90
L5:
 -----------------------------------------

The idea of the .space here is to align L5, given we know how much
code is between the .space and L5.  Maybe this bug is just related to
.space, but if it's something to do with expression evaluation, then
it is a more serious one.  I'll see if I can fix it myself, but my
time is rather limited at the moment.  Maybe someone else will get
curious as to what is wrong here?



From alan@spri.levels.unisa.edu.au  Wed Jun 21 17:02:00 1995
From: alan@spri.levels.unisa.edu.au (Alan Modra)
Date: Wed, 21 Jun 1995 17:02:00 -0000
Subject: Another fixup bug
Message-ID: <m0sOZiY-0000y0C@mullet>

This one doesn't generate bad code, just not optimal.  The "jz L6"
gets assembled as a long branch, where a short one will reach the
distance.

 ----------------------------
	.text
L0:
	jz L5
L1:
	jz L6
L2:
	.align 16, 0x90

L4:
	.space 0x72, 0x90
L5:
	.space 2, 0x90
L6:
 ----------------------------

From jrs@world.std.com  Wed Jun 21 22:40:00 1995
From: jrs@world.std.com (Rick Sladkey)
Date: Wed, 21 Jun 1995 22:40:00 -0000
Subject: ELF line numbers
Message-ID: <951322.023610.jrs@world.std.com>

When I first tried GNU ld on SunOS 4.1.x, I liked the inclusion of
file, function and line number in undefined error messages.  I finally
got tired of seeing `.text+0xXXXX' messages and so I tried to add this
feature for ELF on Solaris 2.x and Linux.  I implemented a simple
version which will work even without debugging but omits the line
number (based on the one in aoutx.h).

Then as I was about to embark on the full debug version, I realized
that using the .stabs section will work for Solaris and Linux but not
DWARF.  In which file should one implement the stabs version?  It
seems that elfcode.h is too general and elf32-{i386,sparc}.c are too
specific.

bfd ChangeLog:

Thu Jun 22 02:21:39 1995  Rick Sladkey  <jrs@world.std.com>

	* elfcode.h (elf_find_nearest_line): Handle the simple
	case where there is no debugging information.

ld ChangeLog:

Thu Jun 22 02:21:39 1995  Rick Sladkey  <jrs@world.std.com>

	* ldmisc.c (undefined_symbol): Don't print the line number if
	it isn't meaningful.
	
*** gas-950619/bfd/elfcode.h-dist	Mon Jun 19 04:18:54 1995
--- gas-950619/bfd/elfcode.h	Wed Jun 21 15:24:09 1995
***************
*** 3397,3403 ****
       CONST char **functionname_ptr;
       unsigned int *line_ptr;
  {
!   return false;
  }
  
  int
--- 3397,3450 ----
       CONST char **functionname_ptr;
       unsigned int *line_ptr;
  {
!   /* Run down the file looking for the filename and function.  */
!   asymbol **p;
!   static  char buffer[100];
!   static  char filename_buffer[200];
!   CONST char *main_file_name = NULL;
! 
!   bfd_vma high_line_vma = ~0;
!   bfd_vma low_func_vma = 0;
!   asymbol *func = 0;
!   *filename_ptr = abfd->filename;
!   *functionname_ptr = 0;
!   *line_ptr = 0;
!   if (symbols != (asymbol **)NULL) {
!     for (p = symbols; *p; p++) {
!       elf_symbol_type  *q = (elf_symbol_type *)(*p);
!     next:
!       switch (ELF_ST_TYPE(q->internal_elf_sym.st_info)){
!       case STT_FILE:
! 	main_file_name = q->symbol.name;
! 	break;
! 
!       case STT_FUNC:
! 	{
! 	  /* We'll keep this if it is nearer than the one we have already */
! 	  if (q->symbol.value >= low_func_vma &&
! 	      q->symbol.value <= offset) {
! 	    low_func_vma = q->symbol.value;
! 	    func = (asymbol *)q;
! 	  }
! 	  if (func) {
! 	    CONST char *function = func->name;
! 	    char *p;
! 	    strncpy (buffer, function, sizeof (buffer) - 1);
! 	    buffer[sizeof(buffer)-1] = 0;
! 	    *functionname_ptr = buffer;
! 	    goto done;
! 
! 	  }
! 	}
! 	break;
!       }
!     }
!   }
! 
!  done:
!   if (main_file_name)
!     *filename_ptr = main_file_name;
!   return true;
  }
  
  int
*** gas-950619/ld/ldmisc.c-dist	Fri May 12 14:54:47 1995
--- gas-950619/ld/ldmisc.c	Wed Jun 21 15:13:48 1995
***************
*** 297,303 ****
  		      last_function = buystring (functionname);
  		    }
  		  discard_last = false;
! 		  fprintf (fp, "%s:%u", filename, linenumber);
  		}
  	      else if (linenumber != 0) 
  		finfo (fp, "%B:%s:%u", abfd, filename, linenumber);
--- 297,306 ----
  		      last_function = buystring (functionname);
  		    }
  		  discard_last = false;
! 		  if (linenumber != 0) 
! 		    finfo (fp, "%s:%u", filename, linenumber);
! 		  else
! 		    finfo (fp, "%s(%s+0x%v)", filename, section->name, offset);
  		}
  	      else if (linenumber != 0) 
  		finfo (fp, "%B:%s:%u", abfd, filename, linenumber);


From alan@spri.levels.unisa.edu.au  Sat Jun 24 03:51:00 1995
From: alan@spri.levels.unisa.edu.au (Alan Modra)
Date: Sat, 24 Jun 1995 03:51:00 -0000
Subject: gas fixup problem?
References: <no.id>
Message-ID: <m0sPSnu-0000y0C@mullet>

> 
> /usr/i486-linux/bin/as zzz.s; nm a.out
> 00000000 t L0
> 00000006 t L1
> 00000002 t L2		!!!!!!!!!
> 00000006 t L3
> 00000015 t L4
> 00000094 t L5
> 
>  --------------------zzz.s----------------
> 	.text
> L0:
> 	jz L5
> L1:
> L2:
> L3:
> 	.space -(L2 - L0 + 0x7f) & (16-1), 0x90
> 
> L4:
> 	.space 0x7f, 0x90
> L5:
>  -----------------------------------------
> 
> The idea of the .space here is to align L5, given we know how much
> code is between the .space and L5.  Maybe this bug is just related to
> .space, but if it's something to do with expression evaluation, then
> it is a more serious one.  I'll see if I can fix it myself, but my
> time is rather limited at the moment.  Maybe someone else will get
> curious as to what is wrong here?
> 
A bit more info.  The problem seems to be caused inside S_GET_VALUE()
in write.c around line 1937.  S_GET_VALUE tries to evaluate the
expression, and in so doing resolves L2 to be equal to 2, correct for
the first time round when the "jz" is assumed to be a short
instruction.  When gas decide that the "jz" needs to be a long branch
occupying 6 bytes, the value of L2 is marked as resolved so isn't
adjusted.
I'm not sure I have the time to figure out how all the gas internals
work, so a fix from me will take a while...

.org also exhibits the same sort of behaviour with
-------------------------------
        .text
Z0:
        jz Z9
Z1:
Z2:
        .org (15 & -(Z2 - Z0)) + .
Z5:
        .space 0x7f, 0x90
Z9:
-------------------------------
similarly giving wrong values for Z2

The slightly more contrived
-------------------------------
        .text
Z0:
        jz Z9
Z1:
Z2:
        .org (Z2 - Z0 + 1) + .
Z5:
        .space 0x7f, 0x90
Z9:
-------------------------------
bombs with
z1.s: Assembler messages:
z1.s:9: Error: attempt to .org/.space backwards? (-3)
z1.s:9: Internal error!
Assertion failure in write_contents at write.c line 924.
Please report this bug.

From gdt@mc.com  Tue Jun 27 06:39:00 1995
From: gdt@mc.com (Gary Thomas)
Date: Tue, 27 Jun 1995 06:39:00 -0000
Subject: Patches for PowerPC ELF support
Message-ID: <9506271336.AA11619@godzilla>

The attached patches (against the 950626 snapshot) fix some problems I
have with ELF support for the PowerPC.  Also I have added more complete
COFF support for the PowerPC [not a standard, but we need it for
continuity].  Also, these patches are basic to a *now working* port
of Linux for the PowerPC.

Details of the patches (I didn't change any "Change..." files - I'm
not familiar with the official procedures):.

	Add "powerpc-any-xcoff" as a target configuration.
	Create the files 'bfd/config/ppc-xcoff.mt' and
	   'bfd/ppc-xcoff.c'.
	Change 'bfd/elf32-ppc.c': This fixes a problem with incorrect
	   relocation of "partial" addressing modes (like XXX@ha).
	Changes to 'gas/config/tc-ppc.c': complete support for COFF
	   output (especially partial addressing modes).  Change the
	   check & reporting of overflow in partial fields which was
	   incorrect for absolute expressions using partial addressing modes.
	Changes to 'gas/write.c': Part of above fix.
	Changes to 'opcodes/ppc-opc.c': Add some 603 specific instructions.
	   TLB maintenance instructions "tlbld" and "tlbli".

	You may or may not want to incorporate 'ld/emulparams/elf32ppc.sh'.
	   These changes modify the defaults for "ld" for Linux on PowerPC.

Any questions or comments, don't hesitate to contact me.

Thanks,

--------------------------------------------------------------------------
Gary Thomas                              |
email: gdt@mc.com                        |
Mercury Computer Systems                 | "Fine wine is a necessity of
199 Riverneck Road                       |        life for me"
Chelmsford, MA 01824                     |
(508)256-0052 x278                       |      Thomas Jefferson
   ... opinions expressed here are mine  |
       and no one else would claim them! |
--------------------------------------------------------------------------

diff -r -c -P gas-950626/bfd/Makefile.in /usr/gary/gnu/gas-950626/bfd/Makefile.in
*** gas-950626/bfd/Makefile.in	Mon Jun 26 04:20:43 1995
--- /usr/gary/gnu/gas-950626/bfd/Makefile.in	Mon Jun 26 22:25:05 1995
***************
*** 143,148 ****
--- 143,149 ----
  	cofflink.o \
  	ecoff.o \
  	ecofflink.o \
+ 	ppc-xcoff.o \
  	elf32-gen.o \
  	elf32-hppa.o \
  	elf32-i386.o \
***************
*** 262,268 ****
  	 i386lynx.c cf-i386lynx.c m68klynx.c cf-m68klynx.c \
  	 sparclynx.c cf-sparclynx.c aix386-core.c hpux-core.c \
  	 irix-core.c lynx-core.c osf-core.c hash.c linker.c cofflink.c \
! 	 m68knetbsd.c ns32knetbsd.c sparcnetbsd.c
  
  HFILES = aout-target.h aoutf1.h aoutx.h coffcode.h \
  	 coffswap.h ecoffswap.h elf32-hppa.h elf32-target.h elf64-target.h \
--- 263,270 ----
  	 i386lynx.c cf-i386lynx.c m68klynx.c cf-m68klynx.c \
  	 sparclynx.c cf-sparclynx.c aix386-core.c hpux-core.c \
  	 irix-core.c lynx-core.c osf-core.c hash.c linker.c cofflink.c \
! 	 m68knetbsd.c ns32knetbsd.c sparcnetbsd.c \
! 	 ppc-xcoff.c
  
  HFILES = aout-target.h aoutf1.h aoutx.h coffcode.h \
  	 coffswap.h ecoffswap.h elf32-hppa.h elf32-target.h elf64-target.h \
***************
*** 789,793 ****
--- 791,798 ----
  sparcnetbsd.o: sparcnetbsd.c netbsd.h libaout.h $(INCDIR)/bfdlink.h \
    aout-target.h $(INCDIR)/aout/aout64.h $(INCDIR)/aout/stab_gnu.h \
    $(INCDIR)/aout/stab.def $(INCDIR)/aout/ar.h
+ ppc-xcoff.o: ppc-xcoff.c $(INCDIR)/coff/internal.h \
+   $(INCDIR)/coff/rs6000.h libcoff.h $(INCDIR)/bfdlink.h \
+   coffcode.h coffswap.h
  
  # IF YOU PUT ANYTHING HERE IT WILL GO AWAY
diff -r -c -P gas-950626/bfd/config/ppc-xcoff.mt /usr/gary/gnu/gas-950626/bfd/config/ppc-xcoff.mt
*** gas-950626/bfd/config/ppc-xcoff.mt	Wed Dec 31 19:00:00 1969
--- /usr/gary/gnu/gas-950626/bfd/config/ppc-xcoff.mt	Mon Jun 26 22:25:05 1995
***************
*** 0 ****
--- 1,6 ----
+ # Target:  PowerPC using XCOFF
+ 
+ DEFAULT_VECTOR=bfd_xcoff_powerpc_vec
+ 
+ SELECT_VECS=bfd_elf32_powerpc_vec rs6000coff_vec
+ SELECT_ARCHITECTURES=bfd_powerpc_arch bfd_rs6000_arch
diff -r -c -P gas-950626/bfd/config.bfd /usr/gary/gnu/gas-950626/bfd/config.bfd
*** gas-950626/bfd/config.bfd	Mon Jun 26 04:20:45 1995
--- /usr/gary/gnu/gas-950626/bfd/config.bfd	Mon Jun 26 22:38:14 1995
***************
*** 128,133 ****
--- 128,134 ----
    powerpcle-*-elf*)	bfd_name=ppcle-elf ;;
    powerpcle-*-sysv4*)	bfd_name=ppcle-elf ;;
    powerpcle-*-eabi*)	bfd_name=ppcle-elf ;;
+   powerpc-*-xcoff*)	bfd_name=ppc-xcoff ;;
    rs6000-*-*)		bfd_name=rs6000 ;;
    sparc-*-lynxos*)	bfd_name=sparc-lynx ;;
    sparc-*-netbsd*)	bfd_name=sparc-nbsd strip_underscore=yes;;
diff -r -c -P gas-950626/bfd/configure.in /usr/gary/gnu/gas-950626/bfd/configure.in
*** gas-950626/bfd/configure.in	Mon Jun 26 04:20:46 1995
--- /usr/gary/gnu/gas-950626/bfd/configure.in	Mon Jun 26 22:25:05 1995
***************
*** 165,170 ****
--- 165,171 ----
  				target64=true ;;
      bfd_elf64_sparc_vec)	tb="$tb elf64-sparc.o elf64.o elf.o"
  				target64=true ;;
+     bfd_xcoff_powerpc_vec)	tb="$tb ppc-xcoff.o" ;;
      cisco_core_vec)		tb="$tb cisco-core.o" ;;
      demo_64_vec)		tb="$tb demo64.o aout64.o stab-syms.o"
  				target64=true ;;
diff -r -c -P gas-950626/bfd/elf32-ppc.c /usr/gary/gnu/gas-950626/bfd/elf32-ppc.c
*** gas-950626/bfd/elf32-ppc.c	Tue May  9 17:07:01 1995
--- /usr/gary/gnu/gas-950626/bfd/elf32-ppc.c	Mon Jun 26 22:25:05 1995
***************
*** 1055,1061 ****
  			+ sec->output_section->vma
  			+ sec->output_offset
  			+ addend);
- 
    return (relocation & 0x8000) << 1;
  }
  
--- 1055,1060 ----
***************
*** 1076,1082 ****
    if (output_bfd != (bfd *) NULL)
      return ppc_elf_std_reloc (abfd, reloc_entry, symbol, data,
  			      input_section, output_bfd, error_message);
- 
    reloc_entry->addend += ppc_elf_addr16_ha_inner (symbol->section,
  						  (bfd_is_com_section (symbol->section)) ? 0 : symbol->value,
  						  reloc_entry->addend);
--- 1075,1080 ----
***************
*** 1171,1176 ****
--- 1169,1175 ----
    Elf_Internal_Rela *rel = relocs;
    Elf_Internal_Rela *relend = relocs + input_section->reloc_count;
    boolean ret = true;
+   long sym_value;
  
  #ifdef DEBUG
    fprintf (stderr, "ppc_elf_relocate_section called for %s section %s, %ld relocations%s\n",
***************
*** 1257,1266 ****
--- 1256,1268 ----
  	  continue;
  	}
  
+       sym_value = 0;
+ 
        if (r_symndx < symtab_hdr->sh_info)
  	{
  	  sym = local_syms + r_symndx;
  	  sec = local_sections[r_symndx];
+ 	  sym_value = sym->st_value;
  	  relocation = (sec->output_section->vma
  			+ sec->output_offset
  			+ sym->st_value);
***************
*** 1272,1277 ****
--- 1274,1280 ----
  	      || h->root.type == bfd_link_hash_defweak)
  	    {
  	      sec = h->root.u.def.section;
+ 	      sym_value = h->root.u.def.value;
  	      relocation = (h->root.u.def.value
  			    + sec->output_section->vma
  			    + sec->output_offset);
***************
*** 1306,1312 ****
--- 1309,1321 ----
  
  	case (int)R_PPC_ADDR16_HA:	/* arithmetic adjust relocations */
  	  BFD_ASSERT (sec != (asection *)0);
+ #if 0	  
+ /* Note: This caused double-value to be added because of how "ha_inner" works */	  
  	  addend += ppc_elf_addr16_ha_inner (sec, relocation, addend);
+ #else
+ 	  addend += ppc_elf_addr16_ha_inner (sec, sym_value, addend);
+ 						  
+ #endif	  
  	  break;
  	}
  
diff -r -c -P gas-950626/bfd/ppc-xcoff.c /usr/gary/gnu/gas-950626/bfd/ppc-xcoff.c
*** gas-950626/bfd/ppc-xcoff.c	Wed Dec 31 19:00:00 1969
--- /usr/gary/gnu/gas-950626/bfd/ppc-xcoff.c	Mon Jun 26 22:25:06 1995
***************
*** 0 ****
--- 1,684 ----
+ /* BFD back-end for IBM RS/6000 "XCOFF" files.
+    Copyright 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc.
+    FIXME: Can someone provide a transliteration of this name into ASCII?
+    Using the following chars caused a compiler warning on HIUX (so I replaced
+    them with octal escapes), and isn't useful without an understanding of what
+    character set it is.
+    Written by Metin G. Ozisik, Mimi Ph\373\364ng-Th\345o V\365, 
+      and John Gilmore.
+    Archive support from Damon A. Permezel.
+    Contributed by IBM Corporation and Cygnus Support.
+ 
+ This file is part of BFD, the Binary File Descriptor library.
+ 
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+ 
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ GNU General Public License for more details.
+ 
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.  */
+ 
+ /* This port currently only handles reading object files, except when
+    compiled on an RS/6000 host.  -- no archive support, no core files.
+    In all cases, it does not support writing.
+ 
+    FIXMEmgo comments are left from Metin Ozisik's original port.  */
+ 
+ /* Internalcoff.h and coffcode.h modify themselves based on this flag.  */
+ #define RS6000COFF_C 1
+ 
+ #include "bfd.h"
+ #include "sysdep.h"
+ #include "libbfd.h"
+ #include "obstack.h"
+ #include "coff/internal.h"
+ #include "coff/rs6000.h"
+ #include "libcoff.h"
+ 
+ static bfd_reloc_status_type ppc_xcoff_std_reloc
+   PARAMS ((bfd *, arelent *, asymbol *, PTR, asection *, bfd *, char **));
+ 
+ static bfd_vma ppc_xcoff_addr16_ha_inner PARAMS ((asection *, bfd_vma, bfd_vma));
+ static bfd_reloc_status_type ppc_xcoff_addr16_ha_reloc
+   PARAMS ((bfd *, arelent *, asymbol *, PTR, asection *, bfd *, char **));
+ 
+ /* The main body of code is in coffcode.h.  */
+ 
+ #define COFF_DEFAULT_SECTION_ALIGNMENT_POWER (3)
+ 
+ /* The XCOFF reloc table.  Actually, XCOFF relocations specify the
+    bitsize and whether they are signed or not, along with a
+    conventional type.  This table is for the types, which are used for
+    different algorithms for putting in the reloc.  Many of these
+    relocs need special_function entries, which I have not written.  */
+ 
+ static reloc_howto_type ppc_xcoff_howto_table[] =
+ {
+   /* Standard 32 bit relocation.  */
+   HOWTO (0,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 32,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_POS",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffffffff,            /* src_mask */                             
+ 	 0xffffffff,            /* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+ 
+   /* 32 bit relocation, but store negative value.  */
+   HOWTO (1,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 -2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 32,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_NEG",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffffffff,            /* src_mask */                             
+ 	 0xffffffff,            /* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+ 
+   /* 32 bit PC relative relocation.  */
+   HOWTO (2,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 32,	                /* bitsize */                   
+ 	 true,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_signed, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_REL",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffffffff,            /* src_mask */                             
+ 	 0xffffffff,            /* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* 16 bit TOC relative relocation.  */
+   HOWTO (3,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 1,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 16,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_signed, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_TOC",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* I don't really know what this is.  */
+   HOWTO (4,	                /* type */                                 
+ 	 1,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 32,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_RTB",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffffffff,	        /* src_mask */                             
+ 	 0xffffffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* External TOC relative symbol.  */
+   HOWTO (5,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 16,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_GL",                /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* Local TOC relative symbol.  */
+   HOWTO (6,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 16,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_TCL",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   { 7 },
+   
+   /* Non modifiable absolute branch.  */
+   HOWTO (8,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 26,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_BA",                /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0x3fffffc,	        /* src_mask */                             
+ 	 0x3fffffc,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   { 9 },
+ 
+   /* Non modifiable relative branch.  */
+   HOWTO (0xa,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 26,	                /* bitsize */                   
+ 	 true,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_signed, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_BR",                /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0x3fffffc,	        /* src_mask */                             
+ 	 0x3fffffc,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   { 0xb },
+ 
+   /* Indirect load.  */
+   HOWTO (0xc,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 16,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_RL",                /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* Load address.  */
+   HOWTO (0xd,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 16,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_RLA",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   { 0xe },
+   
+   /* Non-relocating reference.  */
+   HOWTO (0xf,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 32,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_REF",               /* name */                                 
+ 	 false,	                /* partial_inplace */                      
+ 	 0,		        /* src_mask */                             
+ 	 0,     	   	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   { 0x10 },
+   { 0x11 },
+   
+   /* TOC relative indirect load.  */
+   HOWTO (0x12,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 16,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_TRL",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* TOC relative load address.  */
+   HOWTO (0x13,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 16,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_TRLA",              /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* Modifiable relative branch.  */
+   HOWTO (0x14,	                /* type */                                 
+ 	 1,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 32,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_RRTBI",             /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffffffff,	        /* src_mask */                             
+ 	 0xffffffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* Modifiable absolute branch.  */
+   HOWTO (0x15,	                /* type */                                 
+ 	 1,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 32,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_RRTBA",             /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffffffff,	        /* src_mask */                             
+ 	 0xffffffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* Modifiable call absolute indirect.  */
+   HOWTO (0x16,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 16,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_CAI",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* Modifiable call relative.  */
+   HOWTO (0x17,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 16,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_REL",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* Modifiable branch absolute.  */
+   HOWTO (0x18,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 16,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_RBA",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* Modifiable branch absolute.  */
+   HOWTO (0x19,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 16,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_RBAC",              /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* Modifiable branch relative.  */
+   HOWTO (0x1a,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 26,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_signed, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_REL",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+   
+   /* Modifiable branch absolute.  */
+   HOWTO (0x1b,	                /* type */                                 
+ 	 0,	                /* rightshift */                           
+ 	 2,	                /* size (0 = byte, 1 = short, 2 = long) */ 
+ 	 16,	                /* bitsize */                   
+ 	 false,	                /* pc_relative */                          
+ 	 0,	                /* bitpos */                               
+ 	 complain_overflow_bitfield, /* complain_on_overflow */
+ 	 0,		        /* special_function */                     
+ 	 "R_REL",               /* name */                                 
+ 	 true,	                /* partial_inplace */                      
+ 	 0xffff,	        /* src_mask */                             
+ 	 0xffff,        	/* dst_mask */                             
+ 	 false),                /* pcrel_offset */
+ 
+   /* A 16 bit relocation without overflow.  */
+   HOWTO (0x1C,		       /* type */
+ 	 0,	                /* rightshift */
+ 	 1,	                /* size (0 = byte, 1 = short, 2 = long) */
+ 	 16,	                /* bitsize */
+ 	 false,	                /* pc_relative */
+ 	 0,	                /* bitpos */
+ 	 complain_overflow_dont,/* complain_on_overflow */
+ 	 ppc_xcoff_std_reloc,	/* special_function */
+ 	 "R_PPC_ADDR16_LO",	/* name */
+ 	 false,	                /* partial_inplace */
+ 	 0,		        /* src_mask */
+ 	 0xffff,       		/* dst_mask */
+ 	 false),                /* pcrel_offset */
+ 
+   /* The high order 16 bits of an address.  */
+   HOWTO (0x1D,			/* type */
+ 	 16,	                /* rightshift */
+ 	 1,	                /* size (0 = byte, 1 = short, 2 = long) */
+ 	 16,	                /* bitsize */
+ 	 false,	                /* pc_relative */
+ 	 0,	                /* bitpos */
+ 	 complain_overflow_dont, /* complain_on_overflow */
+ 	 ppc_xcoff_std_reloc,	/* special_function */
+ 	 "R_PPC_ADDR16_HI",	/* name */
+ 	 false,	                /* partial_inplace */
+ 	 0,		        /* src_mask */
+ 	 0xffff,       		/* dst_mask */
+ 	 false),                /* pcrel_offset */
+ 
+   /* The high order 16 bits of an address, plus 1 if the contents of
+      the low 16 bits, treated as a signed number, is negative.  */
+   HOWTO (0x1E,			/* type */
+ 	 16,	                /* rightshift */
+ 	 1,	                /* size (0 = byte, 1 = short, 2 = long) */
+ 	 16,	                /* bitsize */
+ 	 false,	                /* pc_relative */
+ 	 0,	                /* bitpos */
+ 	 complain_overflow_dont, /* complain_on_overflow */
+ 	 ppc_xcoff_addr16_ha_reloc, /* special_function */
+ 	 "R_PPC_ADDR16_HA",	/* name */
+ 	 false,	                /* partial_inplace */
+ 	 0,		        /* src_mask */
+ 	 0xffff,    		/* dst_mask */
+ 	 false),                /* pcrel_offset */
+ 	 
+ };
+ 
+ #define RTYPE2HOWTO(cache_ptr, dst) ppc_xcoff_rtype2howto (cache_ptr, dst)
+ 
+ static void ppc_xcoff_rtype2howto PARAMS ((arelent *,
+ 					    struct internal_reloc *));
+ 
+ static void
+ ppc_xcoff_rtype2howto (relent, internal)
+      arelent *relent;
+      struct internal_reloc *internal;
+ {
+   relent->howto = ppc_xcoff_howto_table + internal->r_type;
+ 
+   /* The r_size field of an XCOFF reloc encodes the bitsize of the
+      relocation, as well as indicating whether it is signed or not.
+      Doublecheck that the relocation information gathered from the
+      type matches this information.  */
+   if (relent->howto->bitsize != (internal->r_size & 0x1f) + 1)
+     abort ();
+ #if 0
+   if ((internal->r_size & 0x80) != 0
+       ? (relent->howto->complain_on_overflow != complain_overflow_signed)
+       : (relent->howto->complain_on_overflow != complain_overflow_bitfield))
+     abort ();
+ #endif
+ }
+ 
+ #define coff_bfd_reloc_type_lookup ppc_xcoff_reloc_type_lookup
+ 
+ static reloc_howto_type *ppc_xcoff_reloc_type_lookup
+   PARAMS ((bfd *, bfd_reloc_code_real_type));
+ 
+ static reloc_howto_type *
+ ppc_xcoff_reloc_type_lookup (abfd, code)
+      bfd *abfd;
+      bfd_reloc_code_real_type code;
+ {
+   switch (code)
+     {
+     case BFD_RELOC_PPC_B26:
+       return &ppc_xcoff_howto_table[0xa];
+     case BFD_RELOC_PPC_BA26:
+       return &ppc_xcoff_howto_table[8];
+     case BFD_RELOC_PPC_TOC16:
+       return &ppc_xcoff_howto_table[3];
+     case BFD_RELOC_32:
+       return &ppc_xcoff_howto_table[0];
+     case BFD_RELOC_HI16:
+       return &ppc_xcoff_howto_table[0x1D];
+     case BFD_RELOC_HI16_S:
+       return &ppc_xcoff_howto_table[0x1E];
+     case BFD_RELOC_LO16:
+       return &ppc_xcoff_howto_table[0x1C];
+     default:
+       return NULL;
+     }
+ }
+ 
+ #define SELECT_RELOC(internal, howto)					\
+   {									\
+     internal.r_type = howto->type;					\
+     internal.r_size =							\
+       ((howto->complain_on_overflow == complain_overflow_signed		\
+ 	? 0x80								\
+ 	: 0)								\
+        | (howto->bitsize - 1));						\
+   }
+   
+ /* XCOFF relocs are against symbols.  If we are producing relocateable
+    output, and the reloc is against an external symbol, and nothing
+    has given us any additional addend, the resulting reloc will also
+    be against the same symbol.  In such a case, we don't want to
+    change anything about the way the reloc is handled, since it will
+    all be done at final link time.  Rather than put special case code
+    into bfd_perform_relocation, all the reloc types use this howto
+    function.  It just short circuits the reloc if producing
+    relocateable output against an external symbol.  */
+ 
+ /*ARGSUSED*/
+ static bfd_reloc_status_type
+ ppc_xcoff_std_reloc (abfd,
+ 		   reloc_entry,
+ 		   symbol,
+ 		   data,
+ 		   input_section,
+ 		   output_bfd,
+ 		   error_message)
+      bfd *abfd;
+      arelent *reloc_entry;
+      asymbol *symbol;
+      PTR data;
+      asection *input_section;
+      bfd *output_bfd;
+      char **error_message;
+ {
+   if (output_bfd != (bfd *) NULL
+       && (symbol->flags & BSF_SECTION_SYM) == 0
+       && (! reloc_entry->howto->partial_inplace || reloc_entry->addend == 0))
+     {
+       reloc_entry->address += input_section->output_offset;
+       return bfd_reloc_ok;
+     }
+ 
+   return bfd_reloc_continue;
+ }
+ 
+ /* Don't pretend we can deal with unsupported relocs.  */
+ 
+ /*ARGSUSED*/
+ static bfd_reloc_status_type
+ ppc_xcoff_unsupported_reloc (abfd, reloc_entry, symbol, data, input_section,
+ 			   output_bfd, error_message)
+      bfd *abfd;
+      arelent *reloc_entry;
+      asymbol *symbol;
+      PTR data;
+      asection *input_section;
+      bfd *output_bfd;
+      char **error_message;
+ {
+   BFD_ASSERT (reloc_entry->howto != (reloc_howto_type *)0);
+   fprintf (stderr,
+ 	   "%s: Relocation %s (%d) is not currently supported.\n",
+ 	   bfd_get_filename (abfd),
+ 	   reloc_entry->howto->name,
+ 	   reloc_entry->howto->type);
+ 
+   return bfd_reloc_notsupported;
+ }
+ 
+ /* Internal function to return the adjustment to the addend for relocations
+    that return the upper 16 bits after sign extending the lower 16 bits, ie
+    for use with a ORIS instruction followed by a memory reference using the
+    bottom 16 bits.  */
+ 
+ INLINE
+ static bfd_vma
+ ppc_xcoff_addr16_ha_inner (sec, value, addend)
+      asection *sec;
+      bfd_vma value;
+      bfd_vma addend;
+ {
+   bfd_vma relocation = (value
+ 			+ sec->output_section->vma
+ 			+ sec->output_offset
+ 			+ addend);
+   return (relocation & 0x8000) << 1;
+ }
+ 
+ /* Handle the ADDR16_HA reloc by adjusting the reloc addend.  */
+ 
+ /*ARGSUSED*/
+ static bfd_reloc_status_type
+ ppc_xcoff_addr16_ha_reloc (abfd, reloc_entry, symbol, data, input_section,
+ 		         output_bfd, error_message)
+      bfd *abfd;
+      arelent *reloc_entry;
+      asymbol *symbol;
+      PTR data;
+      asection *input_section;
+      bfd *output_bfd;
+      char **error_message;
+ {
+   if (output_bfd != (bfd *) NULL)
+     return ppc_xcoff_std_reloc (abfd, reloc_entry, symbol, data,
+ 			      input_section, output_bfd, error_message);
+   reloc_entry->addend += ppc_xcoff_addr16_ha_inner (symbol->section,
+ 						  (bfd_is_com_section (symbol->section)) ? 0 : symbol->value,
+ 						  reloc_entry->addend);
+   return bfd_reloc_continue;
+ }
+ 
+ #define COFF_LONG_FILENAMES
+ 
+ #include "coffcode.h"
+ 
+ #define	coff_archive_p		bfd_generic_archive_p
+ #define	coff_mkarchive		_bfd_generic_mkarchive
+ 
+ 
+ 
+ #define CORE_FILE_P _bfd_dummy_target
+ 
+ #define coff_core_file_failing_command _bfd_nocore_core_file_failing_command
+ #define coff_core_file_failing_signal _bfd_nocore_core_file_failing_signal
+ #define coff_core_file_matches_executable_p \
+   _bfd_nocore_core_file_matches_executable_p
+ 
+ /* The transfer vector that leads the outside world to all of the above. */
+ 
+ const bfd_target bfd_xcoff_powerpc_vec =
+ {
+   "powerpc-xcoff",		/* name */
+   bfd_target_coff_flavour,	
+   true,				/* data byte order is big */
+   true,				/* header byte order is big */
+ 
+   (HAS_RELOC | EXEC_P |		/* object flags */
+    HAS_LINENO | HAS_DEBUG |
+    HAS_SYMS | HAS_LOCALS | WP_TEXT),
+ 
+   (SEC_HAS_CONTENTS | SEC_ALLOC | SEC_LOAD | SEC_RELOC), /* section flags */
+   0,				/* leading char */
+   '/',				/* ar_pad_char */
+   15,				/* ar_max_namelen??? FIXMEmgo */
+   3,				/* default alignment power */
+ 
+   bfd_getb64, bfd_getb_signed_64, bfd_putb64,
+      bfd_getb32, bfd_getb_signed_32, bfd_putb32,
+      bfd_getb16, bfd_getb_signed_16, bfd_putb16, /* data */
+   bfd_getb64, bfd_getb_signed_64, bfd_putb64,
+      bfd_getb32, bfd_getb_signed_32, bfd_putb32,
+      bfd_getb16, bfd_getb_signed_16, bfd_putb16, /* hdrs */
+ 
+   {_bfd_dummy_target, coff_object_p, 	/* bfd_check_format */
+      coff_archive_p, CORE_FILE_P},
+   {bfd_false, coff_mkobject, coff_mkarchive, /* bfd_set_format */
+      bfd_false},
+   {bfd_false, coff_write_object_contents,	/* bfd_write_contents */
+      _bfd_write_archive_contents, bfd_false},
+ 
+      BFD_JUMP_TABLE_GENERIC (coff),
+      BFD_JUMP_TABLE_COPY (coff),
+      BFD_JUMP_TABLE_CORE (coff),
+      BFD_JUMP_TABLE_ARCHIVE (_bfd_archive_coff),
+      BFD_JUMP_TABLE_SYMBOLS (coff),
+      BFD_JUMP_TABLE_RELOCS (coff),
+      BFD_JUMP_TABLE_WRITE (coff),
+      BFD_JUMP_TABLE_LINK (coff),
+      BFD_JUMP_TABLE_DYNAMIC (_bfd_nodynamic),
+ 
+   COFF_SWAP_TABLE,
+ };
diff -r -c -P gas-950626/bfd/targets.c /usr/gary/gnu/gas-950626/bfd/targets.c
*** gas-950626/bfd/targets.c	Mon Jun 26 04:20:45 1995
--- /usr/gary/gnu/gas-950626/bfd/targets.c	Mon Jun 26 22:25:06 1995
***************
*** 467,472 ****
--- 467,473 ----
  extern const bfd_target bfd_elf64_big_generic_vec;
  extern const bfd_target bfd_elf64_little_generic_vec;
  extern const bfd_target bfd_elf64_sparc_vec;
+ extern const bfd_target bfd_xcoff_powerpc_vec;
  extern const bfd_target demo_64_vec;
  extern const bfd_target ecoff_big_vec;
  extern const bfd_target ecoff_little_vec;
***************
*** 590,595 ****
--- 591,597 ----
  #if 0
  	&bfd_elf64_sparc_vec,
  #endif
+ 	&bfd_xcoff_powerpc_vec,
  	/* We don't include cisco_core_vec.  Although it has a magic number,
  	   the magic number isn't at the beginning of the file, and thus
  	   might spuriously match other kinds of files.  */
***************
*** 779,784 ****
--- 781,787 ----
    }
  
    bfd_set_error (bfd_error_invalid_target);
+ fprintf(stderr, "Target = %s\n", target_name);
    return NULL;
  }
  
diff -r -c -P gas-950626/config.sub /usr/gary/gnu/gas-950626/config.sub
*** gas-950626/config.sub	Mon Jun 26 04:28:39 1995
--- /usr/gary/gnu/gas-950626/config.sub	Mon Jun 26 22:25:06 1995
***************
*** 806,812 ****
  	      | -riscos* | -linux* | -uniplus* | -iris* | -rtu* | -xenix* \
  	      | -hiux* | -386bsd* | -netbsd* | -freebsd* | -riscix*  | -lites* \
  	      | -lynxos* | -bosx* | -nextstep* | -cxux* | -aout* | -elf* \
! 	      | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta | -udi | -eabi)
  		;;
  	# CYGNUS LOCAL
  	-go32 | -sim | -es1800* | -hms* | -xray | -os68k* | -none* | -v88r* \
--- 806,812 ----
  	      | -riscos* | -linux* | -uniplus* | -iris* | -rtu* | -xenix* \
  	      | -hiux* | -386bsd* | -netbsd* | -freebsd* | -riscix*  | -lites* \
  	      | -lynxos* | -bosx* | -nextstep* | -cxux* | -aout* | -elf* \
! 	      | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta | -udi | -eabi | -xcoff)
  		;;
  	# CYGNUS LOCAL
  	-go32 | -sim | -es1800* | -hms* | -xray | -os68k* | -none* | -v88r* \
diff -r -c -P gas-950626/gas/config/tc-ppc.c /usr/gary/gnu/gas-950626/gas/config/tc-ppc.c
*** gas-950626/gas/config/tc-ppc.c	Wed May 17 05:26:51 1995
--- /usr/gary/gnu/gas-950626/gas/config/tc-ppc.c	Mon Jun 26 22:25:11 1995
***************
*** 616,621 ****
--- 616,652 ----
  
  #endif /* OBJ_ELF */
  
+ #ifdef OBJ_COFF
+ /* Parse @h, etc. and return the desired relocation.  */
+ static bfd_reloc_code_real_type
+ ppc_coff_suffix (str_p)
+      char **str_p;
+ {
+   char *str = *str_p;
+ 
+   if (*str != '@')
+     return BFD_RELOC_UNUSED;
+ 
+   if (strncmp (str, "@L", 2) == 0 || strncmp (str, "@l", 2) == 0)
+     {
+       *str_p += 2;
+       return BFD_RELOC_LO16;
+     }
+   else if (strncmp (str, "@HA", 3) == 0 || strncmp (str, "@ha", 3) == 0)
+     {
+       *str_p += 3;
+       return BFD_RELOC_HI16_S;
+     }
+   else if (strncmp (str, "@H", 2) == 0 || strncmp (str, "@h", 2) == 0)
+     {
+       *str_p += 2;
+       return BFD_RELOC_HI16;
+     }
+ 
+   return BFD_RELOC_UNUSED;
+ }
+ #endif
+ 
  /* We need to keep a list of fixups.  We can't simply generate them as
     we go, because that would require us to first create the frag, and
     that would screw up references to ``.''.  */
***************
*** 793,798 ****
--- 824,840 ----
  	  fixups[fc].reloc = reloc;
  	  ++fc;
  	}
+ #else
+       else if ((reloc = ppc_coff_suffix (&str)) != BFD_RELOC_UNUSED)
+ 	{
+ 	  /* We need to generate a fixup for this expression.  */
+ 	  if (fc >= MAX_INSN_FIXUPS)
+ 	    as_fatal ("too many fixups");
+ 	  fixups[fc].exp = ex;
+ 	  fixups[fc].opindex = 0;
+ 	  fixups[fc].reloc = reloc;
+ 	  ++fc;
+ 	}
  #endif /* OBJ_ELF */
  
        else
***************
*** 2700,2705 ****
--- 2742,2748 ----
  	case BFD_RELOC_16:
  	  if (fixp->fx_pcrel)
  	    abort ();
+ 	  fixp->fx_bit_fixP = 1;  /* Turn off error check code in 'write.c' */
  
  	  md_number_to_chars (fixp->fx_frag->fr_literal + fixp->fx_where,
  			      value, 2);
diff -r -c -P gas-950626/gas/config/tc-ppc.h /usr/gary/gnu/gas-950626/gas/config/tc-ppc.h
*** gas-950626/gas/config/tc-ppc.h	Tue May  9 17:17:24 1995
--- /usr/gary/gnu/gas-950626/gas/config/tc-ppc.h	Mon Jun 26 22:25:11 1995
***************
*** 33,39 ****
  
  /* The target BFD format.  */
  #ifdef OBJ_COFF
! #define TARGET_FORMAT "aixcoff-rs6000"
  #endif
  #ifdef OBJ_ELF
  #define TARGET_FORMAT (target_big_endian) ? "elf32-powerpc" : "elf32-powerpcle"
--- 33,40 ----
  
  /* The target BFD format.  */
  #ifdef OBJ_COFF
! /* #define TARGET_FORMAT "aixcoff-rs6000" */
! #define TARGET_FORMAT "powerpc-xcoff"
  #endif
  #ifdef OBJ_ELF
  #define TARGET_FORMAT (target_big_endian) ? "elf32-powerpc" : "elf32-powerpcle"
diff -r -c -P gas-950626/gas/config/te-ppcxcoff.h /usr/gary/gnu/gas-950626/gas/config/te-ppcxcoff.h
*** gas-950626/gas/config/te-ppcxcoff.h	Wed Dec 31 19:00:00 1969
--- /usr/gary/gnu/gas-950626/gas/config/te-ppcxcoff.h	Mon Jun 26 22:25:11 1995
***************
*** 0 ****
--- 1,3 ----
+ #undef TARGET_FORMAT
+ #define TARGET_FORMAT "powerpc-xcoff"
+ 
diff -r -c -P gas-950626/gas/configure.in /usr/gary/gnu/gas-950626/gas/configure.in
*** gas-950626/gas/configure.in	Mon Jun 26 04:24:54 1995
--- /usr/gary/gnu/gas-950626/gas/configure.in	Mon Jun 26 22:32:38 1995
***************
*** 238,243 ****
--- 238,245 ----
  			    esac
  			    ;;
        ppc-*-netware*)       fmt=elf em=ppcnw ;;
+       
+       ppc-*-xcoff*)         fmt=coff em=ppcxcoff ;;
  
        sh-*-coff)            fmt=coff ;;
  
Only in gas-950626/gas/doc: as.info
Only in gas-950626/gas/doc: as.info-1
Only in gas-950626/gas/doc: as.info-2
Only in gas-950626/gas/doc: as.info-3
Only in gas-950626/gas/doc: as.info-4
Only in gas-950626/gas/doc: as.info-5
Only in gas-950626/gas/doc: as.info-6
Only in gas-950626/gas/doc: gasp.info
diff -r -c -P gas-950626/gas/write.c /usr/gary/gnu/gas-950626/gas/write.c
*** gas-950626/gas/write.c	Thu Jun 22 14:44:47 1995
--- /usr/gary/gnu/gas-950626/gas/write.c	Mon Jun 26 22:25:12 1995
***************
*** 2346,2351 ****
--- 2346,2352 ----
  	    }
  	}
  
+ #if 0 /*** If this check is enabled here, some errors are bogus **/	
        if (!fixP->fx_bit_fixP && size > 0)
  	{
  	  valueT mask = 0;
***************
*** 2387,2392 ****
--- 2388,2394 ----
  			  (unsigned long) (fragP->fr_address + where));
  #endif
  	}			/* not a bit fix */
+ #endif
  
        if (!fixP->fx_done)
  	{
***************
*** 2408,2413 ****
--- 2410,2467 ----
  	    fixP->fx_done = 1;
  #endif
  	}
+ 
+ #if 1 /*** This error check can now be performed safely **/
+ /* Note: there is probably a better way to handle this.  For the PowerPC */
+ /* (at least) there are some 16-bit relocations which may involve values */
+ /* whose result is known at assembly time to be larger than 16 bits.     */
+ /* These are OK though, since the result only uses one 16-bit half       */
+ /* (upper or lower), decided upon at link-time.  I have had the "fix3"   */
+ /* routine set the "fixP" flag to avoid this check since it is incorrect */
+ /* for these relocation types.                                           */	
+       if (!fixP->fx_bit_fixP && size > 0)
+ 	{
+ 	  valueT mask = 0;
+ 	  if (size < sizeof (mask))
+ 	    {
+ 	      /* set all bits to one */
+ 	      mask--;
+ 	      /* Technically, combining these produces an undefined result
+ 		 if size is sizeof (valueT), though I think these two
+ 		 half-way operations should both be defined.  And the
+ 		 compiler should be able to combine them if it's valid on
+ 		 the host architecture.  */
+ 	      mask <<= size * 4;
+ 	      mask <<= size * 4;
+ 	      if ((add_number & mask) != 0
+ 		  && (add_number & mask) != mask)
+ 		{
+ 		  char buf[50], buf2[50];
+ 		  sprint_value (buf, fragP->fr_address + where);
+ 		  if (add_number > 1000)
+ 		    sprint_value (buf2, add_number);
+ 		  else
+ 		    sprintf (buf2, "%ld", (long) add_number);
+ 		  as_bad_where (fixP->fx_file, fixP->fx_line,
+ 				"Value of %s too large for field of %d bytes at %s",
+ 				buf2, size, buf);
+ 		} /* generic error checking */
+ 	    }
+ #ifdef WARN_SIGNED_OVERFLOW_WORD
+ 	  /* Warn if a .word value is too large when treated as a signed
+ 	     number.  We already know it is not too negative.  This is to
+ 	     catch over-large switches generated by gcc on the 68k.  */
+ 	  if (!flag_signed_overflow_ok
+ 	      && size == 2
+ 	      && add_number > 0x7fff)
+ 	    as_bad_where (fixP->fx_file, fixP->fx_line,
+ 			  "Signed .word overflow; switch may be too large; %ld at 0x%lx",
+ 			  (long) add_number,
+ 			  (unsigned long) (fragP->fr_address + where));
+ #endif
+ 	}			/* not a bit fix */
+ #endif
+ 	
  #ifdef TC_VALIDATE_FIX
      skip: ;
  #endif
Only in gas-950626/gprof: conftest.c
diff -r -c -P gas-950626/include/opcode/ppc.h /usr/gary/gnu/gas-950626/include/opcode/ppc.h
*** gas-950626/include/opcode/ppc.h	Mon Apr  4 13:16:52 1994
--- /usr/gary/gnu/gas-950626/include/opcode/ppc.h	Mon Jun 26 22:25:12 1995
***************
*** 77,82 ****
--- 77,85 ----
     but it also supports many additional POWER instructions.  */
  #define PPC_OPCODE_601 (040)
  
+ /* Opcodes specific to PowerPC 603 */
+ #define PPC_OPCODE_603 (0100)
+ 
  /* A macro to extract the major opcode from an instruction.  */
  #define PPC_OP(i) (((i) >> 26) & 0x3f)
  
diff -r -c -P gas-950626/ld/Makefile.in /usr/gary/gnu/gas-950626/ld/Makefile.in
*** gas-950626/ld/Makefile.in	Mon Jun 26 04:27:42 1995
--- /usr/gary/gnu/gas-950626/ld/Makefile.in	Mon Jun 26 22:27:18 1995
***************
*** 206,212 ****
  	emipsidt.o emipsidtl.o emipslit.o enews.o ens32knbsd.o eppcnw.o \
  	eriscix.o esa29200.o eshl.o esh.o esparclynx.o esparcnbsd.o \
  	est2000.o esun3.o esun4.o evanilla.o evax.o evsta.o \
! 	ez8ksim.o ei386pe.o earmpe.o
  
  CFILES = ldctor.c ldemul.c ldexp.c ldfile.c ldlang.c \
  	ldmain.c ldmisc.c ldver.c ldwrite.c lexsup.c \
--- 206,212 ----
  	emipsidt.o emipsidtl.o emipslit.o enews.o ens32knbsd.o eppcnw.o \
  	eriscix.o esa29200.o eshl.o esh.o esparclynx.o esparcnbsd.o \
  	est2000.o esun3.o esun4.o evanilla.o evax.o evsta.o \
! 	ez8ksim.o ei386pe.o earmpe.o excoffppc.o
  
  CFILES = ldctor.c ldemul.c ldexp.c ldfile.c ldlang.c \
  	ldmain.c ldmisc.c ldver.c ldwrite.c lexsup.c \
***************
*** 466,471 ****
--- 466,474 ----
  eppcnw.c:	$(srcdir)/emulparams/ppcnw.sh \
    $(srcdir)/emultempl/elf32.em $(srcdir)/scripttempl/nw.sc ${GEN_DEPENDS}
  	${GENSCRIPTS} ppcnw
+ excoffppc.c:	$(srcdir)/emulparams/xcoffppc.sh \
+   $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/xcoffppc.sc ${GEN_DEPENDS}
+ 	${GENSCRIPTS} xcoffppc
  
  ei386nbsd.c:	$(srcdir)/emulparams/i386nbsd.sh \
    $(srcdir)/emultempl/generic.em $(srcdir)/scripttempl/aout.sc ${GEN_DEPENDS}
diff -r -c -P gas-950626/ld/config/ppc-xcoff.mt /usr/gary/gnu/gas-950626/ld/config/ppc-xcoff.mt
*** gas-950626/ld/config/ppc-xcoff.mt	Wed Dec 31 19:00:00 1969
--- /usr/gary/gnu/gas-950626/ld/config/ppc-xcoff.mt	Mon Jun 26 22:25:13 1995
***************
*** 0 ****
--- 1 ----
+ EMUL=xcoffppc
diff -r -c -P gas-950626/ld/configure.in /usr/gary/gnu/gas-950626/ld/configure.in
*** gas-950626/ld/configure.in	Mon Jun 26 04:27:41 1995
--- /usr/gary/gnu/gas-950626/ld/configure.in	Mon Jun 26 22:25:13 1995
***************
*** 126,131 ****
--- 126,132 ----
    powerpc-*-elf* | powerpc-*-eabi*)	ld_target=ppc-elf32 ;;
    powerpcle-*-elf* | powerpcle-*-eabi*)	ld_target=ppcle-elf32 ;;
    powerpc-*-netware*)	ld_target=ppc-nw ;;
+   powerpc-*-xcoff*)	ld_target=ppc-xcoff ;;
    w65-*-*)              ld_target=coff-w65 ;;
    *-*-aout)		ld_target=${target_cpu}-${target_vendor} ;;
    *-*-coff)		ld_target=${target_cpu}-${target_vendor} ;;
diff -r -c -P gas-950626/ld/emulparams/elf32ppc.sh /usr/gary/gnu/gas-950626/ld/emulparams/elf32ppc.sh
*** gas-950626/ld/emulparams/elf32ppc.sh	Thu Jan 26 12:59:02 1995
--- /usr/gary/gnu/gas-950626/ld/emulparams/elf32ppc.sh	Mon Jun 26 22:25:13 1995
***************
*** 1,7 ****
  SCRIPT_NAME=elfppc
  OUTPUT_FORMAT="elf32-powerpc"
! TEXT_START_ADDR=0x0400000
! DATA_ADDR=0x10000000
! MAXPAGESIZE=0x40000
  NONPAGED_TEXT_START_ADDR=0x0400000
  ARCH=powerpc
--- 1,6 ----
  SCRIPT_NAME=elfppc
  OUTPUT_FORMAT="elf32-powerpc"
! TEXT_START_ADDR=0x01000
! MAXPAGESIZE=0x10000
  NONPAGED_TEXT_START_ADDR=0x0400000
  ARCH=powerpc
diff -r -c -P gas-950626/ld/emulparams/xcoffppc.sh /usr/gary/gnu/gas-950626/ld/emulparams/xcoffppc.sh
*** gas-950626/ld/emulparams/xcoffppc.sh	Wed Dec 31 19:00:00 1969
--- /usr/gary/gnu/gas-950626/ld/emulparams/xcoffppc.sh	Mon Jun 26 22:25:13 1995
***************
*** 0 ****
--- 1,7 ----
+ # XCOFF for PowerPC
+ SCRIPT_NAME=xcoffppc
+ OUTPUT_FORMAT="powerpc-xcoff"
+ TEXT_START_ADDR=0x1000
+ PAGE_SIZE=0x1000
+ ARCH=powerpc
+ 
diff -r -c -P gas-950626/ld/scripttempl/xcoffppc.sc /usr/gary/gnu/gas-950626/ld/scripttempl/xcoffppc.sc
*** gas-950626/ld/scripttempl/xcoffppc.sc	Wed Dec 31 19:00:00 1969
--- /usr/gary/gnu/gas-950626/ld/scripttempl/xcoffppc.sc	Mon Jun 26 22:25:13 1995
***************
*** 0 ****
--- 1,37 ----
+ # Linker script for PowerPC COFF.
+ # Based on sparccoff.sc by Gary Thomas
+ test -z "$ENTRY" && ENTRY=_start
+ cat <<EOF
+ OUTPUT_FORMAT("${OUTPUT_FORMAT}")
+ ${LIB_SEARCH_DIRS}
+ 
+ ENTRY(${ENTRY})
+ 
+ SECTIONS
+ {
+   .text ${RELOCATING+ SIZEOF_HEADERS} : {
+     *(.init)
+     *(.text)
+     *(.fini)
+     ${RELOCATING+ etext  =  .};
+   }
+   .data ${RELOCATING+ 0x400000 + (. & 0xffc00fff)} : {
+     *(.data)
+     ${RELOCATING+ edata  =  .};
+   }
+   .bss ${RELOCATING+ SIZEOF(.data) + ADDR(.data)} :
+   { 					
+     *(.bss)
+     *(COMMON)
+     ${RELOCATING+ end = .};
+   }
+   .stab  0 ${RELOCATING+(NOLOAD)} : 
+   {
+     [ .stab ]
+   }
+   .stabstr  0 ${RELOCATING+(NOLOAD)} :
+   {
+     [ .stabstr ]
+   }
+ }
+ EOF
diff -r -c -P gas-950626/opcodes/ppc-opc.c /usr/gary/gnu/gas-950626/opcodes/ppc-opc.c
*** gas-950626/opcodes/ppc-opc.c	Tue Mar  7 16:48:29 1995
--- /usr/gary/gnu/gas-950626/opcodes/ppc-opc.c	Mon Jun 26 22:25:13 1995
***************
*** 1250,1255 ****
--- 1250,1256 ----
  #define B32 PPC_OPCODE_32
  #define B64 PPC_OPCODE_64
  #define M601 PPC_OPCODE_601
+ #define M603 PPC_OPCODE_603
  
  /* The opcode table.
  
***************
*** 2295,2300 ****
--- 2296,2304 ----
  
  { "tlbie",   X(31,306),	XRTRA_MASK,	PPC,		{ RB } },
  { "tlbi",    X(31,306),	XRTRA_MASK,	POWER,		{ RB } },
+ 
+ { "tlbld",   X(31,978),	XRTRA_MASK,	PPC|M603,	{ RB } },
+ { "tlbli",   X(31,1010),XRTRA_MASK,	PPC|M603,	{ RB } },
  
  { "eciwx",   X(31,310), X_MASK,		PPC,		{ RT, RA, RB } },
  

From stephen@gr.osf.org  Thu Jun 29 04:53:00 1995
From: stephen@gr.osf.org (Nick Stephen)
Date: Thu, 29 Jun 1995 04:53:00 -0000
Subject: strange PowerPc assembler syntax used by gas?
Message-ID: <199506291153.HAA03920@postman.osf.org>

The Motorola PowerPC Programming Environments book at
Appendix F-9 defines a simplified branch mnemonic of the
form :

  bne	cr3,	target

where `cr3' is defined at F-1 as `symbol cr3' value `3', these
symbols also being used by the cmp mnemonics etc - I have the
cr symbols #defined to be the appropriate values.


When I assemble or disassemble powerpc code using gas,
I see that the assembler expects

  bne	4*cr3,	target

... this caused me a headache when writing some assembler,
since the former expression (which I had used) assembled
without warning generating erroneous code which disassembles
as

  bne	4*cr0, target

This erroneous code is generated because the least significant
bits of the first argument are masked off and ignored (it is
expecting the value 12, not the value 3), and there is
zero in the most significant bits.

I am not putting forward a patch since I'm not sure of the
correct solution (apart from me rewriting my code which I've
already done!).

I suggest one of the following:

  1) Change the assembler syntax to follow that of Motorola.
     This may involve gcc changes?

  2) Test the bottom bits of the first argument for such
     branches, and report a warning/error if they are set.
     This would give a warning for any assembler code of
     the form defined in the Motorola specification.
     - I believe that this should be done in the `insert_cr'
     function in opcodes/ppc-opc.c

I am working using the 26/05/95 snapshot, I got directory
checksum errors on the 07/06/95 snapshot I downloaded so
was unable to check to see if this problem is still present,
but I believe that it is.

Nick
--
Nick Stephen                    Email: stephen@gr.osf.org
OSF Research Institute          Phone: +33 76 63 48 72
2, Avenue de Vignate            Fax:   +33 76 51 05 32
38610 Gieres - France




From erich@uruk.org  Sat Jul  1 17:53:00 1995
From: erich@uruk.org (erich@uruk.org)
Date: Sat, 01 Jul 1995 17:53:00 -0000
Subject: Possible bugs in GAS/LD...
Message-ID: <199507020055.RAA29094@uruk.org>

I upgraded my snapshot of the GAS assembler from "950426" to "950627",
and for C source code, it apparently is working fine (no careful testing
of this, however).

For assembly source code, of which I have 2 files, one builds OK and
when linked gives a somewhat different executable format, and the other
one (part of a bigger program) won't even build.

My configuration is "--target=i386-gnu", using the GCC 2.6.3 compiler
as a front end (i.e. run with files ending in ".S" instead of ".s" so
I can use the C pre-processor).

Problem #1 (LD output format somewhat different):

I'm using the "-N" option to force a predictable 32-byte a.out header
with no other page alignment, which has worked fine until recently.  it
is now producing a much larger header, and aligns the output to a page-
boundary, so my forced text start address of hex 7c00 produces an output
file where the text starts at location hex c00 in the file (aligned for
demand paging, obviously).

I can work around this easily enough...  it is just somewhat disturbing
to have it change, especially since I thought the 'OMAGIC' format was
supposed to only use a 32-byte header with no other padding.

Problem #2 (GAS aborts build):

On the "950426" version, everything compiles/assembles/links/runs just
fine.  The "950627" version (along with a few earlier versions I tried),
produces this result for my assembly source file in my bigger program:

---------(start error)---------
/var/tmp/cc028269.s: Assembler messages:
/var/tmp/cc028269.s:911: Error: Can not do 2 byte relocation
/var/tmp/cc028269.s:911: Fatal error: Cannot generate relocation type for symbol .text, code (null)
----------(end error)----------

Line number 911 is the end of the file, which leaves me confused.

--
Erich Stefan Boleyn                   \_ E-mail (preferred):  <erich@uruk.org>
Mad Genius wanna-be, CyberMuffin        \__     home #:  +1 (503) 226-0741
<A HREF= http://www.uruk.org/ >WWW Site</A>  \_  USnail: 924 S.W. 16th Ave, #202
Motto: "I'll live forever or die trying"     \        Portland, OR, USA  97205



From ian@cygnus.com  Sun Jul  2 09:55:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Sun, 02 Jul 1995 09:55:00 -0000
Subject: Possible bugs in GAS/LD...
References: <199507020055.RAA29094@uruk.org>
Message-ID: <199507021654.MAA23931@sanguine.cygnus.com>

   From: erich@uruk.org
   Date: Sat, 01 Jul 1995 17:55:34 -0700

   My configuration is "--target=i386-gnu", 

The i386-gnu target now generates ELF object files, not a.out object
files.  I believe this was done at the request of Roland McGrath.

You should be able to use i386-aout to get a.out object files.

Ian



From hjl@nynexst.com  Sun Jul  2 10:01:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Sun, 02 Jul 1995 10:01:00 -0000
Subject: Where is bfd/elfxx-target.h?
Message-ID: <m0sSSO6-00011EC@didi.nynexst.com>

I was wondering where I could get bfd/elfxx-target.h? It is not
in diffs-950701.gz.

Thannks.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

From raeburn@cygnus.com  Sun Jul  2 13:28:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Sun, 02 Jul 1995 13:28:00 -0000
Subject: Where is bfd/elfxx-target.h?
References: <m0sSSO6-00011EC@didi.nynexst.com> <m0sSSO6-00011EC@didi.nynexst.com>
Message-ID: <9507022028.AA14945@cujo.cygnus.com>

I goofed handling some of our source code configuration, so it got
omitted from the snapshots.  Ian has already fixed it, so it'll be in
tomorrow's snapshot.  Sorry 'bout that.



From alan@spri.levels.unisa.edu.au  Tue Jul  4 18:23:00 1995
From: alan@spri.levels.unisa.edu.au (Alan Modra)
Date: Tue, 04 Jul 1995 18:23:00 -0000
Subject: newlib-1.6.1 shows bug in m68k-coff-as
Message-ID: <m0sTJB1-0000y0C@mullet>

This one came up when I decided to try out the latest assembler on
newlib-1.6.1.  gas was configured with
./configure --prefix=/usr --target=m68k-coff --host=i486-linux

$ cd /usr/tmp/newlib-1.6.1/newlib/libm/math

$ m68k-coff-gcc -g -pipe -O2 -DMISSING_SYSCALL_NAMES -fno-builtin
-I/usr/tmp/newlib-1.6.1/newlib/./targ-include
-I/usr/tmp/newlib-1.6.1/newlib/./libc/include -S k_standard.c

$ /usr/tmp/gas-950704/gas/as.new -o /dev/null k_standard.s
k_standard.s: Assembler messages:
k_standard.s:297: Error: Value of -784 too large for field of 1 bytes at 0x317
k_standard.s:297: Error: value out of range

An older gas works ok

$ m68k-coff-as --version
GNU assembler version 950530 (m68k-coff)

$ m68k-coff-as -o /dev/null k_standard.s


The relevant lines from k_standard.s
	.set .LI381,.+2
	move.w .L381-.LI381.b(%pc,%a1.l*2),%d0
	jmp %pc@(2,%d0:w)
.L381:

If anyone wants all of k_standard.s, just ask.

From raeburn@cygnus.com  Fri Jul  7 14:57:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Fri, 07 Jul 1995 14:57:00 -0000
Subject: changes to elf, bfd, m68k, sparc-solaris
Message-ID: <9507072156.AA12339@cujo.cygnus.com>

If you haven't picked up a snapshot lately, please try the one from
this morning or tomorrow morning.

The BFD directory now uses autoconf for some things; some of the data
in hosts/*.h and config/*.mh still needs to move into autoconf.  (In
today's snapshot you'll want to remove bfd/config.cache; that'll be
fixed in the next snapshot.)  The ELF code in BFD has been rearranged
significantly.

A couple weeks or so ago, I incorporated a bunch of m68k fixes from
Andreas Schwab.  And in the next snapshot will be some code Ian has
written for PIC support in the sparc-solaris2 configuration.  (No PIC
support for sunos4 yet, sorry.)

So especially if you're using an elf or m68k configuration, please let
me know if any new problems come up.

The diffs are going to be rather large; I'm in the process of updating
the FSF address in the headers too.  (Some done yesterday, the rest
should be done today.)  Also, Steve has recently added some binary
files, and we've fixed some files without trailing newlines; diff and
patch don't deal with these well, so you may just want to grab a new
snapshot.

Ken



From ian@cygnus.com  Tue Jul 11 08:49:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 11 Jul 1995 08:49:00 -0000
Subject: strange PowerPc assembler syntax used by gas?
References: <199506291153.HAA03920@postman.osf.org>
Message-ID: <199507111549.LAA21317@sanguine.cygnus.com>

   Date: Thu, 29 Jun 95 13:53:16 +0200
   From: Nick Stephen <stephen@gr.osf.org>

   The Motorola PowerPC Programming Environments book at
   Appendix F-9 defines a simplified branch mnemonic of the
   form :

     bne	cr3,	target

   where `cr3' is defined at F-1 as `symbol cr3' value `3', these
   symbols also being used by the cmp mnemonics etc - I have the
   cr symbols #defined to be the appropriate values.

Thanks.  I agree that gas appears to be handling this type of
instruction incorrectly.  I have checked in this patch to ppc-opc.c to
fix it.  As I understand it, it should not require any gcc changes,
because gcc does not rely on the extended branch mnemonics.  Mike,
please correct me if I am wrong (if I'm wrong, we might not want this
patch after all).

Ian

Index: ppc-opc.c
===================================================================
RCS file: /rel/cvsfiles/devo/opcodes/ppc-opc.c,v
retrieving revision 1.15
diff -p -r1.15 ppc-opc.c
*** ppc-opc.c	1995/07/07 22:49:39	1.15
--- ppc-opc.c	1995/07/11 15:47:39
*************** static unsigned long insert_bo PARAMS ((
*** 49,56 ****
  static long extract_bo PARAMS ((unsigned long, int *));
  static unsigned long insert_boe PARAMS ((unsigned long, long, const char **));
  static long extract_boe PARAMS ((unsigned long, int *));
- static unsigned long insert_cr PARAMS ((unsigned long, long, const char **));
- static long extract_cr PARAMS ((unsigned long, int *));
  static unsigned long insert_ds PARAMS ((unsigned long, long, const char **));
  static long extract_ds PARAMS ((unsigned long, int *));
  static unsigned long insert_li PARAMS ((unsigned long, long, const char **));
--- 49,54 ----
*************** const struct powerpc_operand powerpc_ope
*** 178,184 ****
       conditional branch mnemonics, which set the lower two bits of the
       BI field.  This field is optional.  */
  #define CR (BT + 1)
!   { 5, 16, insert_cr, extract_cr, PPC_OPERAND_CR | PPC_OPERAND_OPTIONAL },
  
    /* The D field in a D form instruction.  This is a displacement off
       a register, and implies that the next operand is a register in
--- 176,182 ----
       conditional branch mnemonics, which set the lower two bits of the
       BI field.  This field is optional.  */
  #define CR (BT + 1)
!   { 3, 18, 0, 0, PPC_OPERAND_CR | PPC_OPERAND_OPTIONAL },
  
    /* The D field in a D form instruction.  This is a displacement off
       a register, and implies that the next operand is a register in
*************** extract_boe (insn, invalid)
*** 621,650 ****
        && ! valid_bo (value))
      *invalid = 1;
    return value & 0x1e;
- }
- 
- /* The condition register number portion of the BI field in a B form
-    or XL form instruction.  This is used for the extended conditional
-    branch mnemonics, which set the lower two bits of the BI field.  It
-    is the BI field with the lower two bits ignored.  */
- 
- /*ARGSUSED*/
- static unsigned long
- insert_cr (insn, value, errmsg)
-      unsigned long insn;
-      long value;
-      const char **errmsg;
- {
-   return insn | ((value & 0x1c) << 16);
- }
- 
- /*ARGSUSED*/
- static long
- extract_cr (insn, invalid)
-      unsigned long insn;
-      int *invalid;
- {
-   return (insn >> 16) & 0x1c;
  }
  
  /* The DS field in a DS form instruction.  This is like D, but the
--- 619,624 ----



From ian@cygnus.com  Tue Jul 11 09:33:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 11 Jul 1995 09:33:00 -0000
Subject: ELF line numbers
References: <951322.023610.jrs@world.std.com>
Message-ID: <199507111633.MAA21372@sanguine.cygnus.com>

   From: jrs@world.std.com (Rick Sladkey)
   Date: Thu, 22 Jun 1995 02:36:10 EDT

   When I first tried GNU ld on SunOS 4.1.x, I liked the inclusion of
   file, function and line number in undefined error messages.  I finally
   got tired of seeing `.text+0xXXXX' messages and so I tried to add this
   feature for ELF on Solaris 2.x and Linux.  I implemented a simple
   version which will work even without debugging but omits the line
   number (based on the one in aoutx.h).

Thanks.  I checked this in.

   Then as I was about to embark on the full debug version, I realized
   that using the .stabs section will work for Solaris and Linux but not
   DWARF.  In which file should one implement the stabs version?  It
   seems that elfcode.h is too general and elf32-{i386,sparc}.c are too
   specific.

Actually, the GNU tools support .stabs debugging for any ELF target.
That is actually the only to implement C++ debugging in ELF right now,
because g++ does not support DWARF.  So, elfcode.h (actually, the
function is now in elf.c) is the right place to handle both stabs and
DWARF debugging information.

Ian



From meissner@cygnus.com  Tue Jul 11 14:23:00 1995
From: meissner@cygnus.com (Michael Meissner)
Date: Tue, 11 Jul 1995 14:23:00 -0000
Subject: strange PowerPc assembler syntax used by gas?
References: <199506291153.HAA03920@postman.osf.org> <199507111549.LAA21317@sanguine.cygnus.com> <199507111549.LAA21317@sanguine.cygnus.com>
Message-ID: <199507112123.RAA00457@tiktok.cygnus.com>

|    Date: Thu, 29 Jun 95 13:53:16 +0200
|    From: Nick Stephen <stephen@gr.osf.org>
| 
|    The Motorola PowerPC Programming Environments book at
|    Appendix F-9 defines a simplified branch mnemonic of the
|    form :
| 
|      bne	cr3,	target
| 
|    where `cr3' is defined at F-1 as `symbol cr3' value `3', these
|    symbols also being used by the cmp mnemonics etc - I have the
|    cr symbols #defined to be the appropriate values.
| 
| Thanks.  I agree that gas appears to be handling this type of
| instruction incorrectly.  I have checked in this patch to ppc-opc.c to
| fix it.  As I understand it, it should not require any gcc changes,
| because gcc does not rely on the extended branch mnemonics.  Mike,
| please correct me if I am wrong (if I'm wrong, we might not want this
| patch after all).

Thanks.  No, gcc uses simple numbers for the branch instructions.

| Ian
| 
| Index: ppc-opc.c
| ===================================================================
| RCS file: /rel/cvsfiles/devo/opcodes/ppc-opc.c,v
| retrieving revision 1.15
| diff -p -r1.15 ppc-opc.c
| *** ppc-opc.c	1995/07/07 22:49:39	1.15
| --- ppc-opc.c	1995/07/11 15:47:39
| *************** static unsigned long insert_bo PARAMS ((
| *** 49,56 ****
|   static long extract_bo PARAMS ((unsigned long, int *));
|   static unsigned long insert_boe PARAMS ((unsigned long, long, const char **));
|   static long extract_boe PARAMS ((unsigned long, int *));
| - static unsigned long insert_cr PARAMS ((unsigned long, long, const char **));
| - static long extract_cr PARAMS ((unsigned long, int *));
|   static unsigned long insert_ds PARAMS ((unsigned long, long, const char **));
|   static long extract_ds PARAMS ((unsigned long, int *));
|   static unsigned long insert_li PARAMS ((unsigned long, long, const char **));
| --- 49,54 ----
| *************** const struct powerpc_operand powerpc_ope
| *** 178,184 ****
|        conditional branch mnemonics, which set the lower two bits of the
|        BI field.  This field is optional.  */
|   #define CR (BT + 1)
| !   { 5, 16, insert_cr, extract_cr, PPC_OPERAND_CR | PPC_OPERAND_OPTIONAL },
|   
|     /* The D field in a D form instruction.  This is a displacement off
|        a register, and implies that the next operand is a register in
| --- 176,182 ----
|        conditional branch mnemonics, which set the lower two bits of the
|        BI field.  This field is optional.  */
|   #define CR (BT + 1)
| !   { 3, 18, 0, 0, PPC_OPERAND_CR | PPC_OPERAND_OPTIONAL },
|   
|     /* The D field in a D form instruction.  This is a displacement off
|        a register, and implies that the next operand is a register in
| *************** extract_boe (insn, invalid)
| *** 621,650 ****
|         && ! valid_bo (value))
|       *invalid = 1;
|     return value & 0x1e;
| - }
| - 
| - /* The condition register number portion of the BI field in a B form
| -    or XL form instruction.  This is used for the extended conditional
| -    branch mnemonics, which set the lower two bits of the BI field.  It
| -    is the BI field with the lower two bits ignored.  */
| - 
| - /*ARGSUSED*/
| - static unsigned long
| - insert_cr (insn, value, errmsg)
| -      unsigned long insn;
| -      long value;
| -      const char **errmsg;
| - {
| -   return insn | ((value & 0x1c) << 16);
| - }
| - 
| - /*ARGSUSED*/
| - static long
| - extract_cr (insn, invalid)
| -      unsigned long insn;
| -      int *invalid;
| - {
| -   return (insn >> 16) & 0x1c;
|   }
|   
|   /* The DS field in a DS form instruction.  This is like D, but the
| --- 619,624 ----
| 



From raeburn@cygnus.com  Tue Jul 11 22:46:00 1995
From: raeburn@cygnus.com (raeburn@cygnus.com)
Date: Tue, 11 Jul 1995 22:46:00 -0000
Subject: more autoconfiscation
Message-ID: <199507120545.BAA29470@kr-pc.cygnus.com>

I've converted the opcodes directory to use autoconf.  It also no
longer gets its sysdep.h file from the bfd directory.  I added a
small sysdep.h that uses a configure-generated config.h; if more
stuff needs to be added into this for your system, or more tests
need to be run, let me know.

DJ, I took a shot at fixing up the opcodes/configure.bat script,
but you should probably check it over and let me know if I missed
anything.

I believe the bfd directory is now the only directory using the
bfd/hosts/*.h files.  If that's the case, the autoconf conversion
of the bfd directory can be pushed a bit further, and many of those
files can be removed in favor of a common, conditionalized header
file and additional autoconf tests.

Ken



From cagney@highland.com.au  Tue Jul 11 23:43:00 1995
From: cagney@highland.com.au (Andrew Cagney)
Date: Tue, 11 Jul 1995 23:43:00 -0000
Subject: whih patch should I run?
Message-ID: <Uk0q4Qz02QU69_H2Fl@highland.com.au>

Hello,

To ask a silly question.  Which version of patch should I be using?  The
diffs for going between gas 950620 and 950704 contained entries of the
form:

---
diff -u -r --new-file --show-function-line=^[A-Za-z_]
/cygint/s1/users/raeburn/offsite/snap/new/../old/gas-950627/ld/testsuite/
ld-versados/t1.ld ./ld/testsuite/ld-versados/t1.ld
---
/cygint/s1/users/raeburn/offsite/snap/new/../old/gas-950627/ld/testsuite/ld-
versados/t1.ld   Wed Jun 21 10:15:05 1995
+++ ./ld/testsuite/ld-versados/t1.ld    Mon Jul  3 14:35:18 1995
@@ -278,4 +278,4 @@ SECTIONS
 .PWRV      = 0xfeedface;
 */
 
-}
\ No newline at end of file
+}
---

and and I've found that the versions of patch that I've tried (2.0 and
2.1 on SunOS and NetBSD) and 2.1 barf because of a `malformed patch'. 
Is there a newer version of patch that I should be using that saves this
need to handle diffs like the above by hand?

Any help appreciated on this tickler ...

			regards, Andrew



From raeburn@cygnus.com  Wed Jul 12 00:45:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Wed, 12 Jul 1995 00:45:00 -0000
Subject: whih patch should I run?
References: <Uk0q4Qz02QU69_H2Fl@highland.com.au> <Uk0q4Qz02QU69_H2Fl@highland.com.au>
Message-ID: <9507120745.AA21416@cujo.cygnus.com>

   From: Andrew Cagney <cagney@highland.com.au>
   Date: Wed, 12 Jul 1995 15:43:56 +1000 (EST)


   Is there a newer version of patch that I should be using that saves this
   need to handle diffs like the above by hand?

If you find one, I'd like to hear about it.

The version on my system doesn't deal too well with file names that
are found in multiple directories (e.g., ChangeLog) either.



From raeburn@cygnus.com  Wed Jul 12 11:30:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Wed, 12 Jul 1995 11:30:00 -0000
Subject: more autoconfiscation
References: <199507120545.BAA29470@kr-pc.cygnus.com> <199507120545.BAA29470@kr-pc.cygnus.com>
Message-ID: <9507121830.AA21609@cujo.cygnus.com>

Okay, I was wrong.  Other directories are still using sysdep.h, even
though they aren't setting up symlinks like the opcodes directory was.
Sigh...



From alan@spri.levels.unisa.edu.au  Thu Jul 27 21:57:00 1995
From: alan@spri.levels.unisa.edu.au (Alan Modra)
Date: Thu, 27 Jul 1995 21:57:00 -0000
Subject: m68k-coff-as bug
Message-ID: <m0sbhUN-0000ySC@mullet>

Here is an updated version of the patch Andreas Schwab sent to fix the
m68k-coff problem introduced in gas-950622.


--- gas-950726/gas/config/obj-coff.c	Fri Jul 28 08:41:30 1995
+++ ./gas/config/obj-coff.c	Fri Jul 28 08:46:07 1995
@@ -3677,6 +3677,7 @@
 
 	      if (!TC_FORCE_RELOCATION (fixP))
 		{
+		  pcrel = 0;	/* No further pcrel processing. */
 		  fixP->fx_addsy = NULL;
 		  fixP->fx_subsy = NULL;
 		  fixP->fx_done = 1;



Some test code, similar to that emitted by gcc for switch statements:

mullet:/tmp$ cat >zzz.s
.text
.org 512
        .set .LI1,.+2
        move.w .L1-.LI1.b(%pc,%a0.l),%d0
        jmp %pc@(2,%d0:w)
.L1:

mullet:/tmp$ /usr/tmp/gas-950726/gas/as.new -m68000 -o /dev/null zzz.s
zzz.s: Assembler messages:
zzz.s:4: Error: Value of -508 too large for field of 1 bytes at 0x203
zzz.s:4: Error: value out of range

From cagney@highland.com.au  Tue Aug  1 00:41:00 1995
From: cagney@highland.com.au (Andrew Cagney)
Date: Tue, 01 Aug 1995 00:41:00 -0000
Subject: gas-950726/ss-950728/powerpc*-*-eabi: addis 9,0,a-400000@ha ???
Message-ID: <kk7R4ob02QU6ReMY4t@highland.com.au>

Hello,

	c-torture-1.34/execute/index-1.c

from the lines:

	int
	f (int n)
	{
	  return a[n - 100000];
	}

outputs the assembler:

	addis 9,0,a-400000@ha
	addi 11,9,a-400000@l

quite simply, is this valid PowerPC assembler?  Gas doesn't think so:

cagney@puddin$ powerpc-unknown-eabi-gcc -v index-1.c
...
GNU assembler version 950726 (powerpc-unknown-eabi), using BFD version
cygnus-2.5
/usr/tmp/cca29430.s: Assembler messages:
/usr/tmp/cca29430.s:62: Error: Value of -400000 too large for field of 2
bytes at 34
/usr/tmp/cca29430.s:63: Error: Value of -400000 too large for field of 2
bytes at 38

			Andrew



From hjl@nynexst.com  Thu Aug  3 06:53:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Thu, 03 Aug 1995 06:53:00 -0000
Subject: problems with ld from binutils 2.5.2l.20
References: <9508021833.AA27238@husc7.harvard.edu>
Message-ID: <9508031349.AA10077@nynexst.com>

> 
>  > For the GNU linker, -L applies to all -l's.
> 
> This behavior is wrong. First, it makes no sense, since the order of
> -l's is significant, and second, it makes it impossible to control
> which copies of which libraries are linked with, which could be
> significant. 
> 

The problem is twofold:

1. gcc will re-arrange the order of -L's and -l's. It puts -L's ahead of
   -l's.
2. One -L list is used fo all libraries in the linker.

We have to change both gcc and ld to do the "right" thing.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From ian@cygnus.com  Thu Aug  3 08:29:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Thu, 03 Aug 1995 08:29:00 -0000
Subject: problems with ld from binutils 2.5.2l.20
References: <9508031349.AA10077@nynexst.com>
Message-ID: <199508031528.LAA03205@sanguine.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Thu, 3 Aug 95 9:49:19 EDT

   >  > For the GNU linker, -L applies to all -l's.
   > 
   > This behavior is wrong. First, it makes no sense, since the order of
   > -l's is significant, and second, it makes it impossible to control
   > which copies of which libraries are linked with, which could be
   > significant. 

   The problem is twofold:

   1. gcc will re-arrange the order of -L's and -l's. It puts -L's ahead of
      -l's.
   2. One -L list is used fo all libraries in the linker.

   We have to change both gcc and ld to do the "right" thing.

Just as a side note, the GNU linker behaviour is consistent with the
SunOS linker behaviour.  However, I agree that this should probably be
changed.

Ian



From ian@cygnus.com  Tue Aug  8 09:52:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 08 Aug 1995 09:52:00 -0000
Subject: m68k operand syntax
Message-ID: <199508081652.MAA10450@sanguine.cygnus.com>

I've changed the m68k assembler to use a bison grammar to parse
operands.  The point of this change was to add full support for the
Motorola syntax, instead of the somewhat half-baked and hard-to-
maintain support that was in the older code.  I've tried to test
pretty carefully to make sure that I didn't break anything, but I
would appreciate it if people using the m68k could take a look, when
the find the time, to make sure that there haven't been any
regressions.  Thanks.

Ian



From meissner@cygnus.com  Wed Aug  9 12:38:00 1995
From: meissner@cygnus.com (Michael Meissner)
Date: Wed, 09 Aug 1995 12:38:00 -0000
Subject: gas-950726/ss-950728/powerpc*-*-eabi: addis 9,0,a-400000@ha ???
References: <kk7R4ob02QU6ReMY4t@highland.com.au> <kk7R4ob02QU6ReMY4t@highland.com.au>
Message-ID: <199508091939.PAA01047@wogglebug.tiac.net>

| Hello,
| 
| 	c-torture-1.34/execute/index-1.c
| 
| from the lines:
| 
| 	int
| 	f (int n)
| 	{
| 	  return a[n - 100000];
| 	}
| 
| outputs the assembler:
| 
| 	addis 9,0,a-400000@ha
| 	addi 11,9,a-400000@l
| 
| quite simply, is this valid PowerPC assembler?  Gas doesn't think so:

It probably should be valid PowerPC assembler (given the semantics of
@ha and @l and the fact that the PowerPC elf uses RELA relocations
instead of the stupid REL relocations like the x86 does).  I'll look
into it.

-- 
Michael Meissner, Cygnus Support (East Coast)
Suite 105, 48 Grove Street, Somerville, MA 02144, USA
meissner@cygnus.com,	617-629-3016 (office),	617-629-3010 (fax)



From meissner@cygnus.com  Fri Aug 11 10:31:00 1995
From: meissner@cygnus.com (Michael Meissner)
Date: Fri, 11 Aug 1995 10:31:00 -0000
Subject: gas-950726/ss-950728/powerpc*-*-eabi: addis 9,0,a-400000@ha ???
References: <kk7R4ob02QU6ReMY4t@highland.com.au> <kk7R4ob02QU6ReMY4t@highland.com.au>
Message-ID: <199508111731.NAA01820@tiktok.cygnus.com>

| Hello,
| 
| 	c-torture-1.34/execute/index-1.c
| 
| from the lines:
| 
| 	int
| 	f (int n)
| 	{
| 	  return a[n - 100000];
| 	}
| 
| outputs the assembler:
| 
| 	addis 9,0,a-400000@ha
| 	addi 11,9,a-400000@l
| 
| quite simply, is this valid PowerPC assembler?  Gas doesn't think so:

This will be fixed in tonights fixes.  Here are the patches:

Fri Aug 11 13:23:56 1995  Michael Meissner  <meissner@cygnus.com>

	* write.h (struct fix): Add new field fx_no_overflow.

	* write.c (fixup_segment): If fx_no_overflow is non-zero, don't
	complain if the addend is too large.

	* config/tc-ppc.c (md_assemble): Set fx_no_overflow if the half
	word relocations BFD_RELOC_{LO16,HI16,HI16_S}.

*** write.h.~1~	Wed Jul 12 10:17:43 1995
--- write.h	Fri Aug 11 13:16:44 1995
*************** struct fix
*** 78,83 ****
--- 78,88 ----
    /* Has this relocation already been applied?  */
    unsigned fx_done : 1;
  
+   /* Suppress overflow complaints on large addends.  This is used
+      in the PowerPC ELF config to allow large addends on the
+      BFD_RELOC_{LO16,HI16,HI16_S} relocations.  */
+   unsigned fx_no_overflow : 1;
+ 
    /* How many bytes are involved? */
    short int fx_size;
  
*** write.c.~1~	Thu Aug 10 09:13:24 1995
--- write.c	Fri Aug 11 13:17:16 1995
*************** fixup_segment (fixP, this_segment_type)
*** 2391,2397 ****
  	    }
  	}
  
!       if (!fixP->fx_bit_fixP && size > 0)
  	{
  	  valueT mask = 0;
  	  if (size < sizeof (mask))
--- 2391,2397 ----
  	    }
  	}
  
!       if (!fixP->fx_bit_fixP && !fixP->fx_no_overflow && size > 0)
  	{
  	  valueT mask = 0;
  	  if (size < sizeof (mask))
*** config/tc-ppc.c.~1~	Fri Jul 21 23:10:32 1995
--- config/tc-ppc.c	Fri Aug 11 13:16:54 1995
*************** md_assemble (str)
*** 875,887 ****
  	  reloc_howto_type *reloc_howto = bfd_reloc_type_lookup (stdoutput, fixups[i].reloc);
  	  int size = (!reloc_howto) ? 0 : bfd_get_reloc_size (reloc_howto);
  	  int offset = target_big_endian ? (4 - size) : 0;
  
  	  if (size > 4)
  	    abort();
  
! 	  fix_new_exp (frag_now, f - frag_now->fr_literal + offset, size,
! 		       &fixups[i].exp, (reloc_howto && reloc_howto->pc_relative),
! 		       fixups[i].reloc);
  	}
        else
  	fix_new_exp (frag_now, f - frag_now->fr_literal, 4,
--- 875,899 ----
  	  reloc_howto_type *reloc_howto = bfd_reloc_type_lookup (stdoutput, fixups[i].reloc);
  	  int size = (!reloc_howto) ? 0 : bfd_get_reloc_size (reloc_howto);
  	  int offset = target_big_endian ? (4 - size) : 0;
+ 	  fixS *fixP;
  
  	  if (size > 4)
  	    abort();
  
! 	  fixP = fix_new_exp (frag_now, f - frag_now->fr_literal + offset, size,
! 			      &fixups[i].exp, (reloc_howto && reloc_howto->pc_relative),
! 			      fixups[i].reloc);
! 
! 	  /* Turn off complaints that the addend is too large for things like
! 	     foo+100000@ha.  */
! 	  switch (fixups[i].reloc)
! 	    {
! 	    case BFD_RELOC_LO16:
! 	    case BFD_RELOC_HI16:
! 	    case BFD_RELOC_HI16_S:
! 	      fixP->fx_no_overflow = 1;
! 	      break;
! 	    }
  	}
        else
  	fix_new_exp (frag_now, f - frag_now->fr_literal, 4,

-- 
Michael Meissner, Cygnus Support (East Coast)
Suite 105, 48 Grove Street, Somerville, MA 02144, USA
meissner@cygnus.com,	617-629-3016 (office),	617-629-3010 (fax)



From hjl@nynexst.com  Tue Aug 15 13:34:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Tue, 15 Aug 1995 13:34:00 -0000
Subject: Ooops... typo (fwd)
Message-ID: <9508152031.AA08645@nynexst.com>

Forwarded message:
>From owner-gcc@vger.rutgers.edu Fri Aug  4 04:04:03 1995
From: Jim Paradis <paradis@amt.tay1.dec.com>
Message-Id: <9508040424.AA07496@ives.amt.tay1.dec.com>
Subject: Ooops... typo
To: linux-alpha@vger.rutgers.edu, linux-gcc@vger.rutgers.edu
Date: Fri, 4 Aug 1995 00:24:50 -0500 (EDT)
In-Reply-To: <9508040120.AA07184@ives.amt.tay1.dec.com> from "Jim Paradis" at Aug 3, 95 09:20:07 pm
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 552       
Sender: owner-gcc@vger.rutgers.edu
Precedence: bulk

In my previous message regarding gcc bugs, there was a little typo:

> 	fragp->fr_offset += newsize - size;
> 
> All of the variables above are 64-bit "long long"'s.  newsize=16, size=12;
> therefore fragp->fr_offset should have been incremented by 12.  Instead it
> was incremented by 24.

size=4, not 12.  Otherwise, it *really* doesn't come out right!


-- 
Jim Paradis (paradis@amt.tay1.dec.com)        "It's not procrastination, 
Digital Equipment Corporation		       it's my new Just-In-Time 
(508)952-4047				       Workload Management System!"


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From hjl@nynexst.com  Tue Aug 15 13:34:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Tue, 15 Aug 1995 13:34:00 -0000
Subject: My registers spilleth over... (fwd)
Message-ID: <9508152031.AA08641@nynexst.com>

Forwarded message:
>From owner-gcc@vger.rutgers.edu Fri Aug  4 02:50:53 1995
From: Jim Paradis <paradis@amt.tay1.dec.com>
Message-Id: <9508040120.AA07184@ives.amt.tay1.dec.com>
Subject: My registers spilleth over...
To: linux-gcc@vger.rutgers.edu, linux-alpha@vger.rutgers.edu
Date: Thu, 3 Aug 1995 21:20:07 -0500 (EDT)
X-Mailer: ELM [version 2.4 PL13]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3854      
Sender: owner-gcc@vger.rutgers.edu
Precedence: bulk

This message is of greater interest to the linux-gcc list, but it's also
of interest to the linux-alpha list as well...

For the linux-alpha folks: Someone, some weeks back, tried and failed to
cross-compile Linux/Alpha 1.2 on a Linux/i486 box.  I told him at the
time that that was because he was using the 32-bit cross-development
tools, and that I could build him a set of 64-bit cross-tools that would 
do the job.

I then went and tried to build a set of cross tools on my Linux/i486 box,
only to have the build fall over dead.  To make a VERY long story short,
I'd stumbled over not one but TWO bugs in both gcc2.6.3 and gcc2.7.0 for
i486.  I've since made workarounds that should allow me to build a working
64-bit cross-tool set.  It's building even as we speak, and I'll put it
up on gatekeeper once I've verified it.

(linux-gcc people can tune in now):  The first bug I found was when my
freshly-built gas tried to build a "dummy" Alpha object file (basically, a
six-line bit of assembly code that's nothing more than a single routine
consiisting of a single "ret" instruction).  gas fell over dead when it
tried to build it: got "Assertion failed in write.c".  Much tracking down
finally got me to the following line of code:

	fragp->fr_offset += newsize - size;

All of the variables above are 64-bit "long long"'s.  newsize=16, size=12;
therefore fragp->fr_offset should have been incremented by 12.  Instead it
was incremented by 24.  I figure this is a bug in the handling of
"long long"s by the i486 code generator; if I break the above apart into
two statements:

	fragp->fr_offset = fragp->fr_offset + newsize;
	fragp->fr_offset = fragp->fr_offset - size;

then everything works fine.

The second problem was when I was compiling gdb; at one point, I got
the following:

	fixed or forbidden register was spilled.
	This may be due to a compiler bug or to impossible asm
	statements or clauses.

Turns out it was a compiler bug, though I don't know enough to be able to
fix it.  Basically, the register-spilling algorithm breaks down terribly
when you run out of spillable registers.  The above message occurred
because the compiler ran out of otherwise spillable registers and tried
to spill SP (not a good thing to do if you want to find where you *put*
the spilled data!).  When I fixed it so as not to do this, it then 
tried to spill a previously-spilled-now-live register, and again gave
the above message.  When I fixed *THAT*, it just threw up its hands and
panic'ed with "can't find any more registers to spill".

Basically, I think this is a design deficiency in the register-allocation
algorithm.  Every other architecture that gcc runs on has a large enough
register set so that you'll never hit this case.  Intel, with its
braindead register architecture left over from the 8088 days, is more
likely to run out of places to put the data first....

There are several ways to address this problem... one might abort and re-run 
the register allocation on the routine, hauling fewer and fewer in-memory
variables into registers until one is able to obtain a successful allocation.
Or, one might implement multiple-spillage, using register coloring to
determine just *how* live a register is (i.e. if it's not used in an
inner scope but it is used in an outer scope, you can consider it "not
dead but resting" and spill it temporarily).  Those who do compilers for
a living no doubt could think up more.

Anyhow: my workaround was to recompile the offending file with the 
-fvolatile flag.  It slows the code down, but it gets you there!

Anyhow: anyone with *real* fixes to these problems is more than welcome
to come forward 8-)

-- 
Jim Paradis (paradis@amt.tay1.dec.com)        "It's not procrastination, 
Digital Equipment Corporation		       it's my new Just-In-Time 
(508)952-4047				       Workload Management System!"


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From ian@cygnus.com  Tue Aug 15 14:30:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 15 Aug 1995 14:30:00 -0000
Subject: My registers spilleth over... (fwd)
References: <9508152031.AA08641@nynexst.com>
Message-ID: <199508152130.RAA09556@sanguine.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Tue, 15 Aug 95 16:30:38 EDT

   Forwarded message:
   From: Jim Paradis <paradis@amt.tay1.dec.com>
   Date: Thu, 3 Aug 1995 21:20:07 -0500 (EDT)

   (linux-gcc people can tune in now):  The first bug I found was when my
   freshly-built gas tried to build a "dummy" Alpha object file (basically, a
   six-line bit of assembly code that's nothing more than a single routine
   consiisting of a single "ret" instruction).  gas fell over dead when it
   tried to build it: got "Assertion failed in write.c".  Much tracking down
   finally got me to the following line of code:

	   fragp->fr_offset += newsize - size;

   All of the variables above are 64-bit "long long"'s.  newsize=16, size=12;
   therefore fragp->fr_offset should have been incremented by 12.  Instead it
   was incremented by 24.  I figure this is a bug in the handling of
   "long long"s by the i486 code generator; if I break the above apart into
   two statements:

	   fragp->fr_offset = fragp->fr_offset + newsize;
	   fragp->fr_offset = fragp->fr_offset - size;

   then everything works fine.

Note that this is a compiler bug.  Nothing needs to be changed in gas.

Ian



From meissner@cygnus.com  Wed Aug 16 06:10:00 1995
From: meissner@cygnus.com (Michael Meissner)
Date: Wed, 16 Aug 1995 06:10:00 -0000
Subject: My registers spilleth over... (fwd)
References: <9508152031.AA08641@nynexst.com> <9508152031.AA08641@nynexst.com>
Message-ID: <199508161310.JAA01232@tiktok.cygnus.com>

(Gcc2 folks, the complaint is yet another register spill case
involving long longs, in this case building a cross debugger from x86
to alpha).

| The second problem was when I was compiling gdb; at one point, I got
| the following:
| 
| 	fixed or forbidden register was spilled.
| 	This may be due to a compiler bug or to impossible asm
| 	statements or clauses.
| 
| Turns out it was a compiler bug, though I don't know enough to be able to
| fix it.  Basically, the register-spilling algorithm breaks down terribly
| when you run out of spillable registers.

This has been a neverending struggle on the x86 and long longs.  With
some programs, changing the allocation order helps with -mreg-alloc=.
When I was actively working on the x86 port, I had programs that would
work with one order or another.  

IMHO, the real problem is the register allocator, and the reload phase
in particular.  However, rewriting it would take a while (and even
longer to shake out the bugs).  At one point, I had management at OSF
signed up to give me the time to do this, and then priorities (and the
layoff) occurred.

| because the compiler ran out of otherwise spillable registers and tried
| to spill SP (not a good thing to do if you want to find where you *put*
| the spilled data!).  When I fixed it so as not to do this, it then 
| tried to spill a previously-spilled-now-live register, and again gave
| the above message.  When I fixed *THAT*, it just threw up its hands and
| panic'ed with "can't find any more registers to spill".
| 
| Basically, I think this is a design deficiency in the register-allocation
| algorithm.  Every other architecture that gcc runs on has a large enough
| register set so that you'll never hit this case.  Intel, with its
| braindead register architecture left over from the 8088 days, is more
| likely to run out of places to put the data first....

| There are several ways to address this problem... one might abort and re-run 
| the register allocation on the routine, hauling fewer and fewer in-memory
| variables into registers until one is able to obtain a successful allocation.
| Or, one might implement multiple-spillage, using register coloring to
| determine just *how* live a register is (i.e. if it's not used in an
| inner scope but it is used in an outer scope, you can consider it "not
| dead but resting" and spill it temporarily).  Those who do compilers for
| a living no doubt could think up more.

Actually GCC does all that now (maybe not to the extent it could), and
it doesn't help sometimes.  But the more fundamendal problem is that
this takes a lot of work, and the GCC teams already has lots of
desirable work that also needs time and (smart) bodies.

-- 
Michael Meissner, Cygnus Support (East Coast)
Suite 105, 48 Grove Street, Somerville, MA 02144, USA
meissner@cygnus.com,	617-629-3016 (office),	617-629-3010 (fax)



From cagney@highland.com.au  Wed Aug 16 20:41:00 1995
From: cagney@highland.com.au (Andrew Cagney)
Date: Wed, 16 Aug 1995 20:41:00 -0000
Subject: ppc - srwi 11, 10, 0 gives warning 
Message-ID: <okAenhn02QU6MSELA3@highland.com.au>

Hello,

Given the PowerPC assembler:

	cagney@puddin$ cat bug.s
	        srwi 11,10,0
	        rlwinm 11, 10, 32, 0, 31

where the second instruction is what `srwi' is expanded into, gas-950726
gives the warning:

	cagney@puddin$ powerpc-unknown-eabi-as -v bug.s -o bug.o
	GNU assembler version 950726 (powerpc-unknown-eabi), using BFD version
cygnus-2.5
	bug.s: Assembler messages:
	bug.s:1: Warning: operand out of range (32 not between 0 and 31)
	bug.s:2: Warning: operand out of range (32 not between 0 and 31)

While the warning is valid (32 is indeed > 31) and gas is still
generating correct code (mapping it to zero),   I think that for this
case the warning may possibly need to be suppressed.

The assembler was output by ss-950805 from the C file
c-torture/execute/930921-1.c:

	bash$ powerpcle-unknown-eabi-gcc 930921-1.c -msoft-float
/applications/clayton/root/usr/lib/crt0.o
-L/applications/clayton/root/usr/lib -lc -mstrict-align
	/var/tmp/cc026999.s: Assembler messages:
	/var/tmp/cc026999.s:34: Warning: operand out of range (32 not between 0
and 31)

Any thoughts?

			Andrew.



From hjl@nynexst.com  Sun Aug 20 18:51:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Sun, 20 Aug 1995 18:51:00 -0000
Subject: A weak symbol bug in gas-950819
Message-ID: <m0skM0o-00011FC@didi.nynexst.com>

Hi,

There is a weak symbol bug in gas-950819. The old snapshots failed to
pick up the real definition under certain circumstances. gas-950819
failed to set the weak symbol to zero.

BTW, what an ELF linker should do with the symbol "xxx" in

ld .... -lfoo -lbar

where a real "xxx" is defined in libfoo.a, a weak one is defined in
libbar.a and "xxx" is referenced in libbar.a only?


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
----
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1995-08-20 21:43 EDT by <hjl@didi>.
# Source directory was `/home/hjl/bugs/ld/weak'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode       name
# ------ ---------- ------------------------------------------
#    353 -rw-r--r-- Makefile
#     78 -rw-r--r-- bar.c
#    100 -rw-r--r-- foo.c
#     32 -rw-r--r-- main.c
#     45 -rw-r--r-- main1.c
#     17 -rw-r--r-- x.c
#
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
  shar_touch=touch
else
  shar_touch=:
  echo
  echo 'WARNING: not restoring timestamps.  Consider getting and'
  echo "installing GNU \`touch', distributed in GNU File Utilities..."
  echo
fi
rm -f 1231235999 $$.touch
#
# ============= Makefile ==============
if test -f 'Makefile' && test X"$1" != X"-c"; then
  echo 'x - skipping Makefile (file already exists)'
else
  echo 'x - extracting Makefile (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'Makefile' &&
SRCS= foo.c x.c bar.c
OBJS=$(SRCS:.c=.o)
AR=ar
CFLAGS=
CC=gcc -ggdb
RANLIB =ranlib
X
X.c.o:
X	$(CC) $(CFLAGS) -c $<
X
all: f1 f2 f3
X
f1: libfoo.a
X	$(CC) -o $@ main.c -L. -lfoo
X
f2: libfoo.a
X	$(CC) -o $@ main.c x.o -L. -lfoo
X
f3: libfoo.a
X	$(CC) -o $@ main1.c -L. -lfoo
X
libfoo.a:$(OBJS)
X	$(AR) ucvr $@ $(OBJS)
X	$(RANLIB) $@
X
clean:
X	-rm -f *.o *.a f1 f2 f3
SHAR_EOF
  $shar_touch -am 0820213995 'Makefile' &&
  chmod 0644 'Makefile' ||
  echo 'restore of Makefile failed'
  shar_count="`wc -c < 'Makefile'`"
  test 353 -eq "$shar_count" ||
    echo "Makefile: original size 353, current size $shar_count"
fi
# ============= bar.c ==============
if test -f 'bar.c' && test X"$1" != X"-c"; then
  echo 'x - skipping bar.c (file already exists)'
else
  echo 'x - extracting bar.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'bar.c' &&
#include <stdio.h>
X
extern int weak_x;
X
bar ()
{
X  printf ("%d\n", weak_x);
}
SHAR_EOF
  $shar_touch -am 0421213795 'bar.c' &&
  chmod 0644 'bar.c' ||
  echo 'restore of bar.c failed'
  shar_count="`wc -c < 'bar.c'`"
  test 78 -eq "$shar_count" ||
    echo "bar.c: original size 78, current size $shar_count"
fi
# ============= foo.c ==============
if test -f 'foo.c' && test X"$1" != X"-c"; then
  echo 'x - skipping foo.c (file already exists)'
else
  echo 'x - extracting foo.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'foo.c' &&
#include <stdio.h>
X
#pragma weak weak_x
X
extern int  weak_x;
X
foo ()
{
X  printf ("%d\n", weak_x);
}
SHAR_EOF
  $shar_touch -am 0421213795 'foo.c' &&
  chmod 0644 'foo.c' ||
  echo 'restore of foo.c failed'
  shar_count="`wc -c < 'foo.c'`"
  test 100 -eq "$shar_count" ||
    echo "foo.c: original size 100, current size $shar_count"
fi
# ============= main.c ==============
if test -f 'main.c' && test X"$1" != X"-c"; then
  echo 'x - skipping main.c (file already exists)'
else
  echo 'x - extracting main.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'main.c' &&
main ()
{
X  foo ();
X  bar ();
}
SHAR_EOF
  $shar_touch -am 0420012595 'main.c' &&
  chmod 0644 'main.c' ||
  echo 'restore of main.c failed'
  shar_count="`wc -c < 'main.c'`"
  test 32 -eq "$shar_count" ||
    echo "main.c: original size 32, current size $shar_count"
fi
# ============= main1.c ==============
if test -f 'main1.c' && test X"$1" != X"-c"; then
  echo 'x - skipping main1.c (file already exists)'
else
  echo 'x - extracting main1.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'main1.c' &&
main ()
{
X  foo ();
#if 0
X  bar ();
#endif
}
SHAR_EOF
  $shar_touch -am 0421222395 'main1.c' &&
  chmod 0644 'main1.c' ||
  echo 'restore of main1.c failed'
  shar_count="`wc -c < 'main1.c'`"
  test 45 -eq "$shar_count" ||
    echo "main1.c: original size 45, current size $shar_count"
fi
# ============= x.c ==============
if test -f 'x.c' && test X"$1" != X"-c"; then
  echo 'x - skipping x.c (file already exists)'
else
  echo 'x - extracting x.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'x.c' &&
int weak_x = 20;
SHAR_EOF
  $shar_touch -am 0421213795 'x.c' &&
  chmod 0644 'x.c' ||
  echo 'restore of x.c failed'
  shar_count="`wc -c < 'x.c'`"
  test 17 -eq "$shar_count" ||
    echo "x.c: original size 17, current size $shar_count"
fi
exit 0

From ian@cygnus.com  Mon Aug 21 08:14:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 21 Aug 1995 08:14:00 -0000
Subject: A weak symbol bug in gas-950819
References: <m0skM0o-00011FC@didi.nynexst.com>
Message-ID: <199508211514.LAA17943@sanguine.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Sun, 20 Aug 1995 21:50:49 -0400 (EDT)

   There is a weak symbol bug in gas-950819. The old snapshots failed to
   pick up the real definition under certain circumstances. gas-950819
   failed to set the weak symbol to zero.

I'm not sure what you mean when you say that it failed to set the weak
symbol to zero.

I do see from your test case that the linker has a bug in the way it
handles an undefined weak reference followed by a weak reference.
I've checked in the appended patch, which should fix the problem.

   BTW, what an ELF linker should do with the symbol "xxx" in

   ld .... -lfoo -lbar

   where a real "xxx" is defined in libfoo.a, a weak one is defined in
   libbar.a and "xxx" is referenced in libbar.a only?

The linker processes libraries sequentially.  Assuming that there is
no mention of "xxx" before libfoo.a, and assuming that the definition
of "xxx" is not brought in from libfoo.a for some other reason,
libfoo.a is irrelevant to this case.

Ian

Index: linker.c
===================================================================
RCS file: /rel/cvsfiles/devo/bfd/linker.c,v
retrieving revision 1.58
diff -p -r1.58 linker.c
*** linker.c	1995/07/13 18:14:17	1.58
--- linker.c	1995/08/21 15:09:20
*************** enum link_action
*** 1321,1327 ****
  static const enum link_action link_action[8][8] =
  {
    /* current\prev    new    undef  undefw def    defw   com    indr   warn  */
!   /* UNDEF_ROW 	*/  {UND,   NOACT, NOACT, REF,   REF,   NOACT, REFC,  WARNC },
    /* UNDEFW_ROW	*/  {WEAK,  NOACT, NOACT, REF,   REF,   NOACT, REFC,  WARNC },
    /* DEF_ROW 	*/  {DEF,   DEF,   DEF,   MDEF,  DEF,   CDEF,  MDEF,  CYCLE },
    /* DEFW_ROW 	*/  {DEFW,  DEFW,  DEFW,  NOACT, NOACT, NOACT, NOACT, CYCLE },
--- 1321,1327 ----
  static const enum link_action link_action[8][8] =
  {
    /* current\prev    new    undef  undefw def    defw   com    indr   warn  */
!   /* UNDEF_ROW 	*/  {UND,   NOACT, UND,   REF,   REF,   NOACT, REFC,  WARNC },
    /* UNDEFW_ROW	*/  {WEAK,  NOACT, NOACT, REF,   REF,   NOACT, REFC,  WARNC },
    /* DEF_ROW 	*/  {DEF,   DEF,   DEF,   MDEF,  DEF,   CDEF,  MDEF,  CYCLE },
    /* DEFW_ROW 	*/  {DEFW,  DEFW,  DEFW,  NOACT, NOACT, NOACT, NOACT, CYCLE },
Index: elflink.h
===================================================================
RCS file: /rel/cvsfiles/devo/bfd/elflink.h,v
retrieving revision 1.9
diff -p -r1.9 elflink.h
*** elflink.h	1995/08/14 15:57:17	1.9
--- elflink.h	1995/08/21 15:09:22
*************** elf_link_add_archive_symbols (abfd, info
*** 155,161 ****
  	    continue;
  	  if (h->root.type != bfd_link_hash_undefined)
  	    {
! 	      defined[i] = true;
  	      continue;
  	    }
  
--- 155,162 ----
  	    continue;
  	  if (h->root.type != bfd_link_hash_undefined)
  	    {
! 	      if (h->root.type != bfd_link_hash_undefweak)
! 		defined[i] = true;
  	      continue;
  	    }
  



From ian@cygnus.com  Mon Aug 21 11:53:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 21 Aug 1995 11:53:00 -0000
Subject: gas now supports macros
Message-ID: <199508211852.OAA18256@sanguine.cygnus.com>

I have added support for macros to gas.  I did it by integrating some
of the code from gasp.

I wouldn't describe this as particularly complete, but it does seem to
work.  I would be interested in getting reactions, patches, and
suggestions for improvement.  It would be particularly nice if
somebody figured out a good way to put macro expansions into a
assembler listing.

Ian

Sample usage:

        .macro  sum from=0, to=5
        .long   \from
        .if     \to-\from
        sum     "(\from+1)",\to
        .endif
        .endm



From ian@cygnus.com  Mon Aug 21 11:53:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 21 Aug 1995 11:53:00 -0000
Subject: macros available tomorrow
Message-ID: <199508211853.OAA18259@sanguine.cygnus.com>

I forgot to mention that the macro code will be in tomorrow's
snapshot.

Ian



From dall@hfrd.dsto.gov.au  Sun Aug 27 20:48:00 1995
From: dall@hfrd.dsto.gov.au (Ian Dall)
Date: Sun, 27 Aug 1995 20:48:00 -0000
Subject: How best to put machine dependant bits in frags and fixes?
References: <199508162020.QAA13437@kr-laptop.cygnus.com> <199508180053.KAA01743@hfrd015.dsto.gov.au> <199508180147.VAA00583@kr-laptop.cygnus.com> <199508212328.IAA04600@hfrd015.dsto.gov.au> <199508220148.VAA28233@kr-laptop.cygnus.com> <199508220148.VAA28233@kr-laptop.cygnus.com>
Message-ID: <199508280347.NAA00388@hfrd015.dsto.gov.au>

I have working a new scheme where the ns32k backend uses fr_machdep to
attach a note, instead of having multiple machine dependant fields in
the frag structure. I removed the fr_pcrel_adjust and fr_bsr fields
which are only used by the ns32k port. The new ns32k scheme keeps a
pointer to the frag containing the relavant opcode and an offset in
that frag. From this, it is possible to calculate the address of the
opcode and hence the difference between the address of the opcode and
the address of the displacement field (which is the correct amount to
adjust the pcrel amount by). This works even though frags may grow or
shrink or change fr_address during the relax phase.

A similar thing needs to be done for fixes. I attached a note to the
tc_fix_data field in the fix structure which contains a pointer to the
opcode frag and the offset in that frag. I also have tried folding
various machine dependent fields in the fix structure into the
tc_fix_data. I grepped around to find out where these fields are used
and note that the comments against these fields weren't always correct.

Anyway, one certainly can do the folding, but it isn't a clear win.

The relevant fields seems to be:

fx_pcrel_adjust is used by i860, i960, m68k. (No longer used by the
ns32k).

fx_im_disp is used by i860, i960 and ns32k. i860 asserts it is always
zero, i960 and ns32k sometimes put 2 in here which wont fit in 1
bit. This was one bit unless building for TC_NS32K in which case it
was 2 bits.  However, it should be two bits or else not needed at
all.

fx_bsr  used by i960, ns32k (sequent only).

fx_tcbit ?

fx_bit_fixP i860, i960-coff and ns32k use this. i960-coff stores an
integer.  This could be folded into tc_fix_data, except there is
machine independent code in write.c which refers to it.

It is a pity the fx_bit_fixP is referenced in write.c. I guess one
could use some new TC_... macro to do return the required info, but if
it is just TC_BITFIXP, then this doesn't seem like a win in terms of
decluttering the machine independent code.

Folding the small fields into tc_fix_data doesn't save any space on
most machines because of the alignment restrictions. Also there is
some penalty in accessing them (an extra dereference plus typically
code to test for the case of tc_fix_data == 0.

One goal is to not waste space for fields a particular machine does not
need. Another goal would be to eliminate machine dependent code
in the machine independant parts. Finally, one could want to select
the target machine at run time. I don't see the last goal as being very
relevant (multiple simultaneous target support is a long way off if
ever).

The first two goals could be supported by having (optional) target
dependent macros to do the *declaration* and initialization of the
target dependent fix fields. The macros might be called
TC_FIX_DECL_SMALL (for target dependent bitfields), TC_FIX_DECL (for
other fields), and TC_FIX_INIT which would be called whenever a new
fix is created, just after the machine independant initialization. The
only bad thing about this is that having a macro containing just
declarations of fields within a structure is a bit unusual and might
trip up programmers.

For example, the fix struct would become:

    struct fix
    {
      unsigned fx_pcrel : 1;
      unsigned fx_plt : 1;

      unsigned fx_done : 1;

    #ifdef TC_FIX_DECL_SMALL
      TC_FIX_DECL_SMALL;
    #else
    #ifdef TC_NS32K
      unsigned fx_im_disp : 2;
    #else
      unsigned fx_im_disp : 1;
    #endif
      unsigned fx_bsr : 1;

      unsigned fx_tcbit : 1;

      char fx_pcrel_adjust;
    #endif /* TC_FIX_DECL_SMALL */

      unsigned fx_no_overflow : 1;

      short int fx_size;

      fragS *fx_frag;

      long fx_where;

      symbolS *fx_addsy;

      symbolS *fx_subsy;

      valueT fx_offset;

      struct fix *fx_next;

      bit_fixS *fx_bit_fixP;

    #ifdef BFD_ASSEMBLER
      bfd_reloc_code_real_type fx_r_type;
    #else
    #ifdef NEED_FX_R_TYPE
      int fx_r_type;
    #endif
    #endif

      valueT fx_addnumber;

      char *fx_file;
      unsigned fx_line;

    #ifdef TC_FIX_DECL
      TC_FIX_DECL;
    #else
      PTR tc_fix_data;
    #endif /* TC_FIX_DECL */
    };



I'd be happy to make the changes to write.h, write.c and the ns32k backend
if you think it is on the right track.

Ian












From cagney@highland.com.au  Wed Aug 30 13:36:00 1995
From: cagney@highland.com.au (Andrew Cagney)
Date: Wed, 30 Aug 1995 13:36:00 -0000
Subject: gas-950822/powerpcle-unknown-eabisim - `gas -mbig' still little ...
Message-ID: <199508301450.AAA08567@puddin.highland.com.au>

Hello,

This one has puzzled me for a while.  Gas, when configured for LE
PowerPC, should still be able to generate BE object files.
Mysteriously it doesn't.  (ditto for BE configured gas generating LE
object files). For instance, the assembler:

	bash$ cat t.s
	.text
	.long 0x12345678
	bash$ ./as.new -o t.o -mbig -v t.s
	GNU assembler version 950822 (powerpcle-unknown-eabisim), using BFD version cygnus-2.5

would give:

	bash$ powerpcle-unknown-eabisim-objdump -d t.o  
	t.o:     file format elf32-powerpc
	No symbols in "t.o".
	Disassembly of section .text:
	00000000 rldcr  r22,r2,r6,16

instead of:

	bash$ powerpcle-unknown-eabisim-objdump -d t.o  
	t.o:     file format elf32-powerpc
	No symbols in "t.o".
	Disassembly of section .text:
	00000000 .long 0x12345678

Seems that md_begin() was clobering md_parse_arg()'s setting of
target_big_endian.

The patch below hopefully fixes this and also elimates what I think
are now redundant header definitions.

			Andrew

*** gas-950822/gas/SRC/ChangeLog	Mon Aug 28 19:47:32 1995
--- gas-950822/gas/ChangeLog	Thu Aug 31 00:10:56 1995
***************
*** 1,3 ****
--- 1,17 ----
+ Thu Aug 31 00:00:38 1995  Andrew Cagney - aka Noid  <cagney@kremvax>
+ 
+ 	* config/tc-ppc.h: Eliminate redundant definitions of
+         TARGET_BYTES_BIG_ENDIAN, TARGET_BYTES_LITTLE_ENDIAN and
+         PPC_BIG_ENDIAN.  The variable target_big_endian now contains this
+         information and is set in read.c/tc-ppc.c.
+ 
+ 	Perhaphs even `target_big_endian' should be initialised from
+ 	stdoutput->xvec->byteorder_big_p.
+ 
+ 	* config/tc-ppc.c (md_begin): Delete code incorrectly setting the
+         variable `target_big_endian' to PPC_BIG_ENDIAN.  This is now done
+         by read.c/tc-ppc.c.
+ 
  Tue Aug 22 03:00:33 1995  Ken Raeburn  <raeburn@kr-laptop.cygnus.com>
  
  	Sat Aug 19 18:08:16 1995  Pat Rankin  <rankin@eql.caltech.edu>
*** gas-950822/gas/config/SRC/tc-ppc.h	Fri Aug 18 19:23:22 1995
--- gas-950822/gas/config/tc-ppc.h	Wed Aug 30 23:51:49 1995
***************
*** 63,81 ****
  #define DIFF_EXPR_OK		/* .-foo gets turned into PC relative relocs */
  #endif
  
- /* Set the endianness we are using.  Default to big endian.  */
- #ifndef TARGET_BYTES_BIG_ENDIAN
- #ifndef TARGET_BYTES_LITTLE_ENDIAN
- #define TARGET_BYTES_BIG_ENDIAN 1
- #endif
- #endif
- 
- #ifdef TARGET_BYTES_BIG_ENDIAN
- #define PPC_BIG_ENDIAN 1
- #else
- #define PPC_BIG_ENDIAN 0
- #endif
- 
  /* We don't need to handle .word strangely.  */
  #define WORKING_DOT_WORD
  
--- 63,68 ----
*** gas-950822/gas/config/SRC/tc-ppc.c	Mon Aug 28 19:47:41 1995
--- gas-950822/gas/config/tc-ppc.c	Wed Aug 30 23:47:27 1995
***************
*** 436,444 ****
  	}
      }
  
-   /* Tell the main code what the endianness is.  */
-   target_big_endian = PPC_BIG_ENDIAN;
- 
  #ifdef OBJ_COFF
    ppc_coff_debug_section = coff_section_from_bfd_index (stdoutput, N_DEBUG);
  
--- 436,441 ----




From meissner@cygnus.com  Wed Aug 30 14:14:00 1995
From: meissner@cygnus.com (Michael Meissner)
Date: Wed, 30 Aug 1995 14:14:00 -0000
Subject: gas-950822/powerpcle-unknown-eabisim - `gas -mbig' still little ...
References: <199508301450.AAA08567@puddin.highland.com.au> <199508301450.AAA08567@puddin.highland.com.au>
Message-ID: <199508302114.RAA27719@tiktok.cygnus.com>

| Hello,
| 
| This one has puzzled me for a while.  Gas, when configured for LE
| PowerPC, should still be able to generate BE object files.
| Mysteriously it doesn't.  (ditto for BE configured gas generating LE
| object files). For instance, the assembler:

I noticed this and added the support already on 8/23.

Wed Aug 23 10:40:41 1995  Michael Meissner  <meissner@tiktok.cygnus.com>

	* config/tc-ppc.c (set_target_endian): New static to say whether
	we've initialized target_big_endian or not.
	(md_parse_option): Set set_target_endian if we set the variable
	target_big_endian.
	(md_begin): Only set target_big_endian if !set_target_endian.




From VZEVE@intellicorp.com  Wed Aug 30 16:17:00 1995
From: VZEVE@intellicorp.com (Victor Zeve)
Date: Wed, 30 Aug 1995 16:17:00 -0000
Subject: please unsubscribe
Message-ID: <199508302317.QAA10807@cygnus.com>

Please unsubscribe Intellicorp from this bboard

Thank You,

Victor Zeve
-------



From hjl@nynexst.com  Sun Sep 10 18:33:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Sun, 10 Sep 1995 18:33:00 -0000
Subject: An ELF linker bug?
Message-ID: <m0srxk6-00011HC@didi.nynexst.com>

Here is a simple test. "f1" should print out "foo". Under UnixWare,
it worked fine. But gas-950822 failed to pick up the strong "foo".
Also Solaris 2.3 got it wrong.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
----
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1995-09-10 21:30 EDT by <hjl@didi>.
# Source directory was `/home/hjl/bugs/ld/weak1'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode       name
# ------ ---------- ------------------------------------------
#    262 -rw-r--r-- Makefile
#     97 -rw-r--r-- bar.c
#     51 -rw-r--r-- foo.c
#     22 -rw-r--r-- main.c
#
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
  shar_touch=touch
else
  shar_touch=:
  echo
  echo 'WARNING: not restoring timestamps.  Consider getting and'
  echo "installing GNU \`touch', distributed in GNU File Utilities..."
  echo
fi
rm -f 1231235999 $$.touch
#
# ============= Makefile ==============
if test -f 'Makefile' && test X"$1" != X"-c"; then
  echo 'x - skipping Makefile (file already exists)'
else
  echo 'x - extracting Makefile (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'Makefile' &&
SRCS= foo.c bar.c
SRCS= bar.c foo.c
OBJS=$(SRCS:.c=.o)
AR=ar
CFLAGS=
CC=gcc
RANLIB =ranlib
X
X.c.o:
X	$(CC) $(CFLAGS) -c $<
X
all: f1
X
f1: libfoo.a
X	$(CC) -o $@ main.c -L. -lfoo
X
libfoo.a:$(OBJS)
X	$(AR) ucvr $@ $(OBJS)
X	$(RANLIB) $@
X
clean:
X	-rm -f *.o *.a f1 f2 f3
SHAR_EOF
  $shar_touch -am 0910211995 'Makefile' &&
  chmod 0644 'Makefile' ||
  echo 'restore of Makefile failed'
  shar_count="`wc -c < 'Makefile'`"
  test 262 -eq "$shar_count" ||
    echo "Makefile: original size 262, current size $shar_count"
fi
# ============= bar.c ==============
if test -f 'bar.c' && test X"$1" != X"-c"; then
  echo 'x - skipping bar.c (file already exists)'
else
  echo 'x - extracting bar.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'bar.c' &&
#include <stdio.h>
X
/*#pragma weak bar */
#pragma weak foo = bar
X
bar ()
{
X  printf ("bar\n");
}
SHAR_EOF
  $shar_touch -am 0910211995 'bar.c' &&
  chmod 0644 'bar.c' ||
  echo 'restore of bar.c failed'
  shar_count="`wc -c < 'bar.c'`"
  test 97 -eq "$shar_count" ||
    echo "bar.c: original size 97, current size $shar_count"
fi
# ============= foo.c ==============
if test -f 'foo.c' && test X"$1" != X"-c"; then
  echo 'x - skipping foo.c (file already exists)'
else
  echo 'x - extracting foo.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'foo.c' &&
#include <stdio.h>
X
foo ()
{
X  printf ("foo\n");
}
SHAR_EOF
  $shar_touch -am 0910211695 'foo.c' &&
  chmod 0644 'foo.c' ||
  echo 'restore of foo.c failed'
  shar_count="`wc -c < 'foo.c'`"
  test 51 -eq "$shar_count" ||
    echo "foo.c: original size 51, current size $shar_count"
fi
# ============= main.c ==============
if test -f 'main.c' && test X"$1" != X"-c"; then
  echo 'x - skipping main.c (file already exists)'
else
  echo 'x - extracting main.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'main.c' &&
main ()
{
X  foo ();
}
SHAR_EOF
  $shar_touch -am 0910211595 'main.c' &&
  chmod 0644 'main.c' ||
  echo 'restore of main.c failed'
  shar_count="`wc -c < 'main.c'`"
  test 22 -eq "$shar_count" ||
    echo "main.c: original size 22, current size $shar_count"
fi
exit 0

From ian@cygnus.com  Mon Sep 11 08:07:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 11 Sep 1995 08:07:00 -0000
Subject: An ELF linker bug?
References: <m0srxk6-00011HC@didi.nynexst.com>
Message-ID: <199509111507.LAA19337@sanguine.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Sun, 10 Sep 1995 21:33:01 -0400 (EDT)

   Here is a simple test. "f1" should print out "foo". Under UnixWare,
   it worked fine. But gas-950822 failed to pick up the strong "foo".
   Also Solaris 2.3 got it wrong.

I think this case is undefined.  You are defining a symbol twice in an
archive.  It does not matter that one definition is weak and one is
normal.  A weak definition is pulled in from an archive just as a
normal one is.  This case is equivalent to defining the same symbol in
two different object files and including them both in an archive: you
can not predict which object file will be included in the final link.

Ian



From ian@cygnus.com  Mon Sep 11 12:34:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 11 Sep 1995 12:34:00 -0000
Subject: problems with ld from binutils 2.5.2l.20
References: <9508031349.AA10077@nynexst.com>
Message-ID: <199509111934.PAA19698@sanguine.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Thu, 3 Aug 95 9:49:19 EDT

   >  > For the GNU linker, -L applies to all -l's.
   > 
   > This behavior is wrong. First, it makes no sense, since the order of
   > -l's is significant, and second, it makes it impossible to control
   > which copies of which libraries are linked with, which could be
   > significant. 
   > 

   The problem is twofold:

   1. gcc will re-arrange the order of -L's and -l's. It puts -L's ahead of
      -l's.
   2. One -L list is used fo all libraries in the linker.

   We have to change both gcc and ld to do the "right" thing.

I started to think about implementing this, but then I realized that I
don't understand it.  As far as I can tell, it only makes a difference
when an archive does not exist.

Support you run
    ld -Lfoo -lfoo -Lbar -lbar
The proposed change appears to argue that the -Lbar should not apply
to the -lfoo.  However, that only matters if foo/libfoo.a does not
exist.

So, it does not make it impossible to control which libraries are used
in the link.  In fact, this change would not affect what libraries are
included in the link at all, except that the linker would sometimes
fail in cases where it currently succeeds.

It doesn't seem worth making this change.  As I noted earlier, the
current linker behaviour is compatible with the SunOS linker.

Ian



From rms@gnu.ai.mit.edu  Mon Sep 11 13:05:00 1995
From: rms@gnu.ai.mit.edu (Richard Stallman)
Date: Mon, 11 Sep 1995 13:05:00 -0000
Subject: problems with ld from binutils 2.5.2l.20
References: <199509111934.PAA19698@sanguine.cygnus.com>
Message-ID: <199509112004.QAA14727@mole.gnu.ai.mit.edu>

    Support you run
	ld -Lfoo -lfoo -Lbar -lbar
    The proposed change appears to argue that the -Lbar should not apply
    to the -lfoo.  However, that only matters if foo/libfoo.a does not
    exist.

That is true.

What this shows is that even if the order of options were not rearranged,
the -L feature is insufficient for controlling which libraries are used,
for the reason that it can only add to the end of the search list.

So I guess we might as well not change this unless/until we also make
it powerful enough to alter the search list in more flexible ways.
I don't know of an urgent need to do that.



From Wolfgang.Stukenbrock@informatik.uni-erlangen.de  Tue Sep 12 03:43:00 1995
From: Wolfgang.Stukenbrock@informatik.uni-erlangen.de (Wolfgang Stukenbrock)
Date: Tue, 12 Sep 1995 03:43:00 -0000
Subject: problems with ld from binutils 2.5.2l.20
References: <199509112004.QAA14727@mole.gnu.ai.mit.edu>
Message-ID: <199509121043.MAA22533@faui40.informatik.uni-erlangen.de>

> 
>     Support you run
> 	ld -Lfoo -lfoo -Lbar -lbar
>     The proposed change appears to argue that the -Lbar should not apply
>     to the -lfoo.  However, that only matters if foo/libfoo.a does not
>     exist.
> 
> That is true.
> 
> What this shows is that even if the order of options were not rearranged,
> the -L feature is insufficient for controlling which libraries are used,
> for the reason that it can only add to the end of the search list.
> 
> So I guess we might as well not change this unless/until we also make
> it powerful enough to alter the search list in more flexible ways.
> I don't know of an urgent need to do that.
> 

I don't think it will be a good idea to change this in any case, because
some makefile rely on the fact, that all -L directives are scanned before
any other processing is done. The ld would get incompartible to the standard
semantics!

-- 
 Wolfgang Stukenbrock



From cagney@highland.com.au  Fri Sep 15 13:36:00 1995
From: cagney@highland.com.au (Andrew Cagney)
Date: Fri, 15 Sep 1995 13:36:00 -0000
Subject: (i386-unknown-netbsd1.0/gas-950912) syntax error in ld/configure.host
Message-ID: <199509151401.AAA06430@puddin.highland.com.au>

Hello,

ld/configure.host has the syntax error below.

		Andrew

--

*** gas-950912/ld/SRC/ChangeLog	Fri Sep 15 21:11:18 1995
--- gas-950912/ld/ChangeLog	Fri Sep 15 23:29:03 1995
***************
*** 0 ****
--- 1,5 ----
+ Fri Sep 15 23:28:05 1995  Andrew Cagney - aka Noid  <cagney@highland.com.au>
+ 
+ 	* configure.host (NATIVE_LIB_DIRS): fix syntax error.
+         `='.
+ 
*** gas-950912/ld/SRC//configure.host	Fri Sep 15 21:11:42 1995
--- gas-950912/ld//configure.host	Fri Sep 15 23:27:30 1995
***************
*** 27,33 ****
    # shell commands.  So we need to make this value non-empty in order
    # for the genscripts.sh call to work.  There's nothing magic about
    # the value `/lib'; it's just a dummy.
!   NATIVE_LIB_DIRS = /lib
    ;;
  
  i[345]86-*-go32*)
--- 27,33 ----
    # shell commands.  So we need to make this value non-empty in order
    # for the genscripts.sh call to work.  There's nothing magic about
    # the value `/lib'; it's just a dummy.
!   NATIVE_LIB_DIRS=/lib
    ;;
  
  i[345]86-*-go32*)



From raeburn@cygnus.com  Fri Sep 15 17:06:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Fri, 15 Sep 1995 17:06:00 -0000
Subject: (i386-unknown-netbsd1.0/gas-950912) syntax error in ld/configure.host
References: <199509151401.AAA06430@puddin.highland.com.au>
Message-ID: <199509160005.UAA01014@kr-laptop.cygnus.com>

   From: Andrew Cagney <cagney@highland.com.au>
   Date: Sat, 16 Sep 1995 00:01:16 +1000

   ld/configure.host has the syntax error below.

Thanks, I've fixed it and a similar one for the DG/UX entry.



From arnej@pvv.unit.no  Mon Sep 18 02:02:00 1995
From: arnej@pvv.unit.no (Arne H. Juul)
Date: Mon, 18 Sep 1995 02:02:00 -0000
Subject: patches to add mips-dec-netbsd configuration
Message-ID: <9509180901.AA17584@datter.pvv.unit.no>

For some time now I've been using binutils snapshots successfully on
NetBSD/pmax, aka mips-dec-netbsd.  These patches are against 950909 but
should work with the current version as well.

Most of the patches only add recognizing the name to be handled
like mips*el-*-elf.

However, there is one patch to elf.c that modifies ld behaviour on
linking: don't merge together readonly and writable object sections
into one program segment.  I think this patch is OK on other systems
as well, but in the long term better control on the relationship
between sections and segments is probably desirable.  If you don't
like this part I hope you will merge in the rest anyway - the elf.c
part is only needed to link the NetBSD kernel.

Yours,

  -  Arne H. J.


diff -ru gas-950909.orig/bfd/elf.c ./bfd/elf.c
--- gas-950909.orig/bfd/elf.c	Sat Sep  9 10:18:17 1995
+++ ./bfd/elf.c	Sat Sep 16 21:56:26 1995
@@ -1706,7 +1706,9 @@
       if (phdr->p_type != PT_NULL
 	  && (hdr->sh_offset - (phdr->p_offset + phdr->p_memsz)
 	      == hdr->sh_addr - (phdr->p_vaddr + phdr->p_memsz))
-	  && (last_type != SHT_NOBITS || hdr->sh_type == SHT_NOBITS))
+	  && (last_type != SHT_NOBITS || hdr->sh_type == SHT_NOBITS)
+	  && ((phdr->p_flags & PF_W ) || !(hdr->sh_flags & SHF_WRITE)))
+
 	{
 	  bfd_size_type adjust;
 
diff -ru gas-950909.orig/bfd/config.bfd ./bfd/config.bfd
--- gas-950909.orig/bfd/config.bfd	Sat Sep  9 10:18:14 1995
+++ ./bfd/config.bfd	Sat Sep 16 21:56:26 1995
@@ -271,6 +271,10 @@
     targ_defvec=ecoff_big_vec
     targ_selvecs=ecoff_little_vec
     ;;
+  mips-dec-netbsd*)
+    targ_defvec=bfd_elf32_littlemips_vec
+    targ_selvecs=bfd_elf32_bigmips_vec
+    ;;
   mips*-dec-bsd*)
     targ_defvec=aout_mips_little_vec
     targ_underscore=yes
diff -ru gas-950909.orig/bfd/configure ./bfd/configure
--- gas-950909.orig/bfd/configure	Sat Sep  9 10:18:16 1995
+++ ./bfd/configure	Sat Sep 16 21:56:26 1995
@@ -1052,6 +1052,8 @@
 EOF
 
 	;;
+  mips-dec-netbsd*)
+	;;
   mips-dec-*)
 	COREFILE=trad-core.o
 	cat >> confdefs.h <<\EOF
diff -ru gas-950909.orig/bfd/configure.host ./bfd/configure.host
--- gas-950909.orig/bfd/configure.host	Thu Sep  7 00:50:36 1995
+++ ./bfd/configure.host	Sat Sep 16 21:56:26 1995
@@ -53,6 +53,7 @@
 			RANLIB=${RANLIB-i386-win32-ranlib}
 			;;
 
+mips-dec-netbsd*)	;;
 mips-dec-*)		HDEFINES="-G 4"	;;
 mips-sgi-irix3*)	HDEFINES="-G 4"
 			test -z "$LDFLAGS" && LDFLAGS=-lmalloc
diff -ru gas-950909.orig/bfd/configure.in ./bfd/configure.in
--- gas-950909.orig/bfd/configure.in	Sat Sep  9 10:18:15 1995
+++ ./bfd/configure.in	Sat Sep 16 21:56:26 1995
@@ -158,6 +158,8 @@
 	COREFILE=trad-core.o
 	AC_DEFINE(TRAD_HEADER,"hosts/mipsmach3.h")
 	;;
+  mips-dec-netbsd*)
+	;;
   mips-dec-*)
 	COREFILE=trad-core.o
 	AC_DEFINE(TRAD_HEADER,"hosts/decstation.h")
diff -ru gas-950909.orig/gas/configure ./gas/configure
--- gas-950909.orig/gas/configure	Sat Sep  9 10:22:20 1995
+++ ./gas/configure	Sat Sep 16 21:56:26 1995
@@ -729,6 +729,7 @@
       m88k-*-coff*)         fmt=coff targ=m88kcoff ;;
 
       # don't change em like *-*-bsd does
+      mips-dec-netbsd*)     fmt=elf targ=mips-lit endian=little ;;
       mips-dec-bsd*)        fmt=aout targ=mips-lit ;;
       mips-sony-bsd*)       fmt=ecoff targ=mips-big ;;
       mips-*-bsd*)          { echo "configure: error: Unknown vendor for mips-bsd configuration." 1>&2; exit 1; } ;;
diff -ru gas-950909.orig/gas/configure.in ./gas/configure.in
--- gas-950909.orig/gas/configure.in	Sat Sep  9 10:22:19 1995
+++ ./gas/configure.in	Sat Sep 16 21:56:26 1995
@@ -202,6 +202,7 @@
       m88k-*-coff*)         fmt=coff targ=m88kcoff ;;
 
       # don't change em like *-*-bsd does
+      mips-dec-netbsd*)     fmt=elf targ=mips-lit endian=little ;;
       mips-dec-bsd*)        fmt=aout targ=mips-lit ;;
       mips-sony-bsd*)       fmt=ecoff targ=mips-big ;;
       mips-*-bsd*)          AC_MSG_ERROR(Unknown vendor for mips-bsd configuration.) ;;
diff -ru gas-950909.orig/ld/configure.tgt ./ld/configure.tgt
--- gas-950909.orig/ld/configure.tgt	Sat Sep  9 10:24:55 1995
+++ ./ld/configure.tgt	Sat Sep 16 21:56:26 1995
@@ -95,6 +95,7 @@
 mips*el-*-ecoff*)	targ_emul=mipsidtl ;;
 mips*-*-ecoff*)		targ_emul=mipsidt ;;
 mips*-dec-bsd*)		targ_emul=mipsbsd ;;
+mips-dec-netbsd*)	targ_emul=elf32lmip ;;
 mips*-*-bsd*)		targ_emul=mipsbig ;;
 mips*vr4300el-*-elf*)	targ_emul=elf32vr4300el ;;
 mips*vr4300-*-elf*)	targ_emul=elf32vr4300 ;;



From ian@cygnus.com  Mon Sep 18 11:48:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 18 Sep 1995 11:48:00 -0000
Subject: patches to add mips-dec-netbsd configuration
References: <9509180901.AA17584@datter.pvv.unit.no>
Message-ID: <199509181847.OAA18721@sanguine.cygnus.com>

   From: "Arne H. Juul" <arnej@pvv.unit.no>
   Date: Mon, 18 Sep 1995 11:01:55 +0200

   Most of the patches only add recognizing the name to be handled
   like mips*el-*-elf.

I checked in versions of these patches.

   However, there is one patch to elf.c that modifies ld behaviour on
   linking: don't merge together readonly and writable object sections
   into one program segment.

It seems to me that this patch could cause trouble.  When the linker
script uses SIZEOF_HEADERS, as the default linker script does, the ELF
linker computes the program header size before it knows the final
positions of the sections.  That means that it must guess at the total
number of program segments which will be required.  Your patch will
cause the linker to sometimes allocate an additional program segment,
and in some cases that will not fit, causing a fatal error.

The right fix for this is rather complex: the linker must be able to
relax the final positions of the segments based on the number of
program header segments which are required, and vice-versa.

Ian



From cagney@highland.com.au  Mon Sep 25 21:46:00 1995
From: cagney@highland.com.au (Andrew Cagney)
Date: Mon, 25 Sep 1995 21:46:00 -0000
Subject: ld/Makefile shell error for --host=sun4-... --target=powerpc-...
Message-ID: <8kNrjWP02QU6RRPN8q@highland.com.au>

Hello,

Below is a problem for someone really up on all the
Makefile.in/configure scripts.  I could include a patch but I suspect
that I make break things for another host/target ... :-)

In several places in gas-950919/ld/Makefile.in there appears commands like:

        -n=`echo ld | sed $(program_transform_name)`; \

which with the SunOS-4.1.3u1 shell gives a syntax error (after expansion) of:

	$ n=`echo ld | sed s,^,powerpc-unknown-eabi,`
	sed: Illegal or missing delimiter: s,
	,powerpc-unknown-eabi,: not found

looking in the gas directory the same thing was written as:

        -n=`echo ld | sed '$(program_transform_name)'`; \

(notice the addition of quotes).

			fyi, Andrew

PS: Below is the example output from a make install.  Notice how, even
though the above problem occures, it still manages to do a correct
install!

n=`echo ld | sed s,^,powerpc-unknown-eabi-,;`; \
  rm -f /applications/clayton/powerpc-unknown-eabi/bin/ld; \
  ln /applications/clayton/bin/$n
/applications/clayton/powerpc-unknown-eabi/bin/ld >/dev/null 2>/dev/null
\
   || /a/puddin/bofh/archive/scratch/clayton/gas-950919/install.sh -c
ld.new /applications/clayton/powerpc-unknown-eabi/bin/ld
sed: Illegal or missing delimiter: s,
sh: ,powerpc-unknown-eabi-,: not found



From ian@cygnus.com  Tue Sep 26 08:36:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 26 Sep 1995 08:36:00 -0000
Subject: ld/Makefile shell error for --host=sun4-... --target=powerpc-...
References: <8kNrjWP02QU6RRPN8q@highland.com.au>
Message-ID: <199509261536.LAA20214@sanguine.cygnus.com>

   Date: Tue, 26 Sep 1995 14:04:50 +1000 (EST)
   From: Andrew Cagney <cagney@highland.com.au>

   In several places in gas-950919/ld/Makefile.in there appears commands like:

	   -n=`echo ld | sed $(program_transform_name)`; \

   which with the SunOS-4.1.3u1 shell gives a syntax error (after expansion) of:


This was fixed on 20 Sep.

Ian



From hjl@nynexst.com  Mon Oct  2 21:00:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 02 Oct 1995 21:00:00 -0000
Subject: An ld bug?
Message-ID: <m0szyWb-00011NC@didi.nynexst.com>

Hi,

It seems gas-950822 doesn't treat common symbols right. Does the newer
snapshot still have this bug? BTW, I tested it under i486-linux.

Thanks.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
---
#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.1).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1995-10-02 23:51 EDT by <hjl@didi>.
# Source directory was `/home/hjl/bugs/ld/common'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode       name
# ------ ---------- ------------------------------------------
#    273 -rw-r--r-- Makefile
#     14 -rw-r--r-- bar.c
#     71 -rw-r--r-- x.c
#
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
  shar_touch=touch
else
  shar_touch=:
  echo
  echo 'WARNING: not restoring timestamps.  Consider getting and'
  echo "installing GNU \`touch', distributed in GNU File Utilities..."
  echo
fi
rm -f 1231235999 $$.touch
#
# ============= Makefile ==============
if test -f 'Makefile' && test X"$1" != X"-c"; then
  echo 'x - skipping Makefile (file already exists)'
else
  echo 'x - extracting Makefile (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'Makefile' &&
SRCS= foo.c bar.c
SRCS= bar.c #foo.c
OBJS=$(SRCS:.c=.o)
AR=ar
CFLAGS=
CC=gcc
RANLIB =ranlib
RANLIB =echo
X
X.c.o:
X	$(CC) $(CFLAGS) -c $<
X
all: f1
X
f1: libbar.a
X	$(CC) -o $@ x.c -L. -lbar
X
libbar.a:$(OBJS)
X	$(AR) ucvr $@ $(OBJS)
X	$(RANLIB) $@
X
clean:
X	-rm -f *.o *.a f1 f2 f3
SHAR_EOF
  $shar_touch -am 1002235095 'Makefile' &&
  chmod 0644 'Makefile' ||
  echo 'restore of Makefile failed'
  shar_count="`wc -c < 'Makefile'`"
  test 273 -eq "$shar_count" ||
    echo "Makefile: original size 273, current size $shar_count"
fi
# ============= bar.c ==============
if test -f 'bar.c' && test X"$1" != X"-c"; then
  echo 'x - skipping bar.c (file already exists)'
else
  echo 'x - extracting bar.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'bar.c' &&
int bar = 10;
SHAR_EOF
  $shar_touch -am 1002223695 'bar.c' &&
  chmod 0644 'bar.c' ||
  echo 'restore of bar.c failed'
  shar_count="`wc -c < 'bar.c'`"
  test 14 -eq "$shar_count" ||
    echo "bar.c: original size 14, current size $shar_count"
fi
# ============= x.c ==============
if test -f 'x.c' && test X"$1" != X"-c"; then
  echo 'x - skipping x.c (file already exists)'
else
  echo 'x - extracting x.c (text)'
  sed 's/^X//' << 'SHAR_EOF' > 'x.c' &&
#include <stdio.h>
X
int bar;
X
main ()
{
X  printf ("bar: %d\n", bar);
}
SHAR_EOF
  $shar_touch -am 1002224095 'x.c' &&
  chmod 0644 'x.c' ||
  echo 'restore of x.c failed'
  shar_count="`wc -c < 'x.c'`"
  test 71 -eq "$shar_count" ||
    echo "x.c: original size 71, current size $shar_count"
fi
exit 0

From ian@cygnus.com  Tue Oct  3 07:25:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 03 Oct 1995 07:25:00 -0000
Subject: An ld bug?
References: <m0szyWb-00011NC@didi.nynexst.com>
Message-ID: <199510031425.KAA23139@sanguine.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)

   It seems gas-950822 doesn't treat common symbols right. Does the newer
   snapshot still have this bug? BTW, I tested it under i486-linux.

It only takes you a minute to note what you think is incorrect about
the program.  Please do that, rather than making me figure out what
the problem is.  Thanks.

In this case, I assume that you think that the common symbol in the
object file should cause the object in the archive to be brought in.
That's the way in works in a.out, but it is not the way it works in
ELF.  In ELF, objects are only brought in from archives to fill
references by undefined symbols.

However, interestingly, I tested the program on Irix 5, UnixWare, and
Solaris, and, on Solaris, it works the way it does in a.out.  I assume
this is for SunOS compatibility.  It happens to contradict the Solaris
linker documentation: ``For an archive library, only those routines
defining an unresolved external reference are loaded.''

Ian



From hjl@nynexst.com  Tue Oct  3 08:20:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Tue, 03 Oct 1995 08:20:00 -0000
Subject: An ld bug?
References: <199510031425.KAA23139@sanguine.cygnus.com>
Message-ID: <9510031520.AA26422@nynexst.com>

> 
>    From: hjl@nynexst.com (H.J. Lu)
> 
>    It seems gas-950822 doesn't treat common symbols right. Does the newer
>    snapshot still have this bug? BTW, I tested it under i486-linux.
> 
> It only takes you a minute to note what you think is incorrect about
> the program.  Please do that, rather than making me figure out what
> the problem is.  Thanks.

Sorry for that.

> 
> In this case, I assume that you think that the common symbol in the
> object file should cause the object in the archive to be brought in.
> That's the way in works in a.out, but it is not the way it works in
> ELF.  In ELF, objects are only brought in from archives to fill
> references by undefined symbols.
> 
> However, interestingly, I tested the program on Irix 5, UnixWare, and
> Solaris, and, on Solaris, it works the way it does in a.out.  I assume
> this is for SunOS compatibility.  It happens to contradict the Solaris
> linker documentation: ``For an archive library, only those routines
> defining an unresolved external reference are loaded.''
> 

>From my Solaris 2.3 linker manual, on page 12 regarding "Archive
Processing", it says the link-editor will extract a relocatable object
from an archive if it contains a data symbol definition that
satisfies a common symbol definition.

I think that makes sense. Maybe it has been changed in Solaris 2.4/2.5.

Thanks.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From davem@caip.rutgers.edu  Tue Oct  3 08:43:00 1995
From: davem@caip.rutgers.edu (David S. Miller)
Date: Tue, 03 Oct 1995 08:43:00 -0000
Subject: An ld bug?
References: <9510031520.AA26422@nynexst.com>
Message-ID: <199510031543.LAA00584@huahaga.rutgers.edu>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Tue, 3 Oct 95 11:20:49 EDT

   >From my Solaris 2.3 linker manual, on page 12 regarding "Archive
   Processing", it says the link-editor will extract a relocatable object
   from an archive if it contains a data symbol definition that
   satisfies a common symbol definition.

   I think that makes sense. Maybe it has been changed in Solaris 2.4/2.5.

The linker provided with the new beta solaris2.5 SUNWspro C4.0 gives
the elf behavior you are expecting where only referenced objects get
extracted from an archive, for what it's worth...

Later,
David S. Miller
davem@caip.rutgers.edu



From hjl@nynexst.com  Tue Oct  3 19:26:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Tue, 03 Oct 1995 19:26:00 -0000
Subject: A bug fix for common symbol in the ELF linker?
References: <199510031557.LAA00698@huahaga.rutgers.edu>
Message-ID: <9510040226.AA04911@nynexst.com>

Hi,

This is the patch for the common symbol bug in ELF I reported
earlier. I hope it won't break anything.

Thanks.

H.J.
===================================================================
RCS file: /home/cvs/gnu/binutils/bfd/elflink.h,v
retrieving revision 1.3
diff -c -r1.3 elflink.h
*** 1.3	1995/08/24 01:32:34
--- elflink.h	1995/10/04 02:15:07
***************
*** 153,159 ****
  				    false, false, false);
  	  if (h == (struct elf_link_hash_entry *) NULL)
  	    continue;
! 	  if (h->root.type != bfd_link_hash_undefined)
  	    {
  	      if (h->root.type != bfd_link_hash_undefweak)
  		defined[i] = true;
--- 153,161 ----
  				    false, false, false);
  	  if (h == (struct elf_link_hash_entry *) NULL)
  	    continue;
! 	  /* We should check both undef and common symbols. H.J. */
! 	  if (h->root.type != bfd_link_hash_undefined &&
! 		h->root.type != bfd_link_hash_common)
  	    {
  	      if (h->root.type != bfd_link_hash_undefweak)
  		defined[i] = true;



From ian@cygnus.com  Tue Oct  3 19:33:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 03 Oct 1995 19:33:00 -0000
Subject: A bug fix for common symbol in the ELF linker?
References: <9510040226.AA04911@nynexst.com>
Message-ID: <9510040233.AA21509@tweedledumb.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Tue, 3 Oct 95 22:26:51 EDT

   This is the patch for the common symbol bug in ELF I reported
   earlier. I hope it won't break anything.

I don't understand this.  I thought I explained why it was not a bug.
Solaris notwithstanding, ELF doesn't work that way.  I may have
misunderstood your response.  Did you disagree with my explanation?

Ian



From davem@caip.rutgers.edu  Thu Oct  5 01:13:00 1995
From: davem@caip.rutgers.edu (David S. Miller)
Date: Thu, 05 Oct 1995 01:13:00 -0000
Subject: Sunos4-1-4 builds...
Message-ID: <199510050747.DAA08472@huahaga.rutgers.edu>

Building the linker uses flex, however the configuration process does
not add '-lfl' to the list of libraries to link the final ld.new
binary with.  Is there a certain reason that -lfl is not added to the
set of libs to link with?

Later,
David S. Miller
davem@caip.rutgers.edu



From ian@cygnus.com  Thu Oct  5 08:13:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Thu, 05 Oct 1995 08:13:00 -0000
Subject: Sunos4-1-4 builds...
References: <199510050747.DAA08472@huahaga.rutgers.edu>
Message-ID: <199510051513.LAA18792@sanguine.cygnus.com>

   Date: Thu, 5 Oct 1995 03:47:53 -0400
   From: "David S. Miller" <davem@caip.rutgers.edu>

   Building the linker uses flex, however the configuration process does
   not add '-lfl' to the list of libraries to link the final ld.new
   binary with.  Is there a certain reason that -lfl is not added to the
   set of libs to link with?

It shouldn't be necessary, at least not for modern versions of flex.
-lfl just defines main and yywrap.  main is defined in ldmain.c, and
yywrap is defined in ldlex.l.  Is it causing trouble?  What version of
flex are you using?

Ian



From davem@caip.rutgers.edu  Thu Oct  5 14:13:00 1995
From: davem@caip.rutgers.edu (David S. Miller)
Date: Thu, 05 Oct 1995 14:13:00 -0000
Subject: Grrr: Sunos4-1-4 builds...
References: <199510051513.LAA18792@sanguine.cygnus.com>
Message-ID: <199510052025.QAA15606@huahaga.rutgers.edu>

   From: Ian Lance Taylor <ian@cygnus.com>
   Date: Thu, 5 Oct 1995 11:13:46 -0400

      Date: Thu, 5 Oct 1995 03:47:53 -0400
      From: "David S. Miller" <davem@caip.rutgers.edu>

      Building the linker uses flex, however the configuration process does
      not add '-lfl' to the list of libraries to link the final ld.new
      binary with.  Is there a certain reason that -lfl is not added to the
      set of libs to link with?

   It shouldn't be necessary, at least not for modern versions of flex.
   -lfl just defines main and yywrap.  main is defined in ldmain.c, and
   yywrap is defined in ldlex.l.  Is it causing trouble?  What version of
   flex are you using?

Currently flex 2.4.5 is installed on the machine which I do SunOS gas
testing..  Precisely, without adding -lfl the compilation fails with
undefined references to:

_yy_flex_realloc
_yy_flex_free
_yy_flex_alloc

This could be something stupid with the way I installed flex or the
fact that is an older version.

Later,
David S. Miller
davem@caip.rutgers.edu



From ian@cygnus.com  Thu Oct  5 14:58:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Thu, 05 Oct 1995 14:58:00 -0000
Subject: Grrr: Sunos4-1-4 builds...
References: <199510052025.QAA15606@huahaga.rutgers.edu>
Message-ID: <199510052158.RAA25117@sanguine.cygnus.com>

   Date: Thu, 5 Oct 1995 16:25:08 -0400
   From: "David S. Miller" <davem@caip.rutgers.edu>

   Currently flex 2.4.5 is installed on the machine which I do SunOS gas
   testing..  Precisely, without adding -lfl the compilation fails with
   undefined references to:

   _yy_flex_realloc
   _yy_flex_free
   _yy_flex_alloc

   This could be something stupid with the way I installed flex or the
   fact that is an older version.

I don't have any copies of flex which are that old, so I don't know
what the problem is.

We are running flex 2.5.2.

Linking against -lfl will cause problems if people are not using lex
rather than flex, since in that case -lfl won't exist.  You can use a
different lexer by building with make LEX=lex.

Ian



From ian@cygnus.com  Tue Oct 31 18:47:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 31 Oct 1995 18:47:00 -0000
Subject: AIX linker
Message-ID: <9511010247.AA21854@tweedledumb.cygnus.com>

I've added XCOFF support to the linker, and have polished up the XCOFF
gas and binutils so that they actually mostly work.  The code is all
in the daily snapshots.  If you have a RS/6000 or PowerPC AIX system,
please give them a try and let me know about any problems you
encounter.  I've tried to stick pretty closely to what the native AIX
linker does, except without quite so many bugs.

Ian



From raeburn@cygnus.com  Sun Nov  5 02:12:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Sun, 05 Nov 1995 02:12:00 -0000
Subject: crt0.o location
Message-ID: <9511051012.AA05158@cujo.cygnus.com>

Currently "make bootstrap" for ld is looking in /lib for crt0.o for
i386-bsd*, i386-freebsd*, and i386-netbsd* configurations.

My NetBSD 1.0A system has it in /usr/lib.

Can anyone tell me about the other BSD variants?



From raeburn@cygnus.com  Mon Nov  6 03:20:00 1995
From: raeburn@cygnus.com (raeburn@cygnus.com)
Date: Mon, 06 Nov 1995 03:20:00 -0000
Subject: mmap changes, mostly for aout right now
Message-ID: <199511061119.GAA06769@kr-laptop.cygnus.com>

I've just checked in now some changes to bfd to use mmap for reading
files under certain circumstances.  A snapshot file should be available
within the next hour or so.  Please try it out and let me know of any
problems.

Currently the "certain circumstances" are limited to string and symbol
table reading for a.out formats, but the interfaces are available to
eventually be used by other formats as well.  There's some preliminary
code to support reading section contents via mmap, but it's not really
tested, and not used anywhere at the moment.  It's also not quite set up
right for optimal use by the linker; that'll take a little bit more work.

These changes add new interfaces for accessing file contents, where the
memory management is under the control of the BFD library rather than the
application.  This lets BFD determine whether mmap can be used or if
malloc/seek/read must be used, transparently to the application.

My tests on sun4 and linux(aout), using local disk, indicate some small
improvement using mmap compared with the old code, even though only
symbol and string tables are accessed this way.

Under NetBSD (on i386), I saw no significant change in CPU time used
(though my test case was different -- many more small files in and out of
libraries).  The linker does seem to work now, after a linker change I
checked in yesterday, based on some changes from Niklas Hallqvist; please
exercise that too.  The linker still takes about half again as much CPU
time as the system (pre-BFD) one, though the system one took more
wall-clock time in my tests than the BFD one, and the mmap changes
reduced the wall-clock time further still.  (I *think* the system was
otherwise idle, but there may have been some cron jobs running, so I
don't consider those last observations to necessarily be significant.)
The BFD linker can generate smaller `-g' executables than the pre-BFD one
due to the string table massaging it does.

Under Linux, using (a.out) object files read and stored over NFS, the
performance got worse using mmap.  My guess is that this is a Linux
problem.  I'm told the Linux NFS client code isn't particularly
spectacular, and I don't know what the mmap support is like.  Maybe some
use of madvise would help?

On host systems where mmap is not available, you'll get a slight
performance degradation compared with the older code.  But I think mmap
is likely to be available on most of the systems we care about these
days, so the tradeoff seems reasonable.

If mmap isn't available or doesn't work right on your system, and the
bfd/configure script doesn't detect that, please try to come up with a
test that does detect the problem.

There's still plenty of room for improving this code.  Using it in more
places, more efficient handling of mapping, perhaps mapping the entire
file in read-only, maybe using madvise, not modifying data in place after
it's mapped in, etc.

Like I said, let me know of any problems....

Ken



From davem@caip.rutgers.edu  Mon Nov  6 08:28:00 1995
From: davem@caip.rutgers.edu (David S. Miller)
Date: Mon, 06 Nov 1995 08:28:00 -0000
Subject: just a nicety...
Message-ID: <199511061608.LAA06016@huahaga.rutgers.edu>

--- gprof/Makefile.in.~1~	Wed Nov  1 15:50:51 1995
+++ gprof/Makefile.in	Mon Nov  6 11:07:21 1995
@@ -82,6 +82,9 @@
 check:
 installcheck:
 
+TAGS:
+	etags -t $(srcdir)/*.[ch]
+
 install-info: gprof.info
 	if [ -r gprof.info ]; then \
 	  dir=. ; \



From davem@caip.rutgers.edu  Tue Nov  7 09:12:00 1995
From: davem@caip.rutgers.edu (David S. Miller)
Date: Tue, 07 Nov 1995 09:12:00 -0000
Subject: ld drops core with new mmap() bfd routines
Message-ID: <199511071712.MAA12355@huahaga.rutgers.edu>

While building Fresco with the latest snapshot ld drops core while
linking some of the libraries under SunOS4.1.4.  I'll try to
investigate further and see if the mmap() changes to bfd are the
culprit and if not then who actually is.

Later,
David S. Miller
davem@caip.rutgers.edu



From rms@gnu.ai.mit.edu  Tue Nov  7 09:39:00 1995
From: rms@gnu.ai.mit.edu (Richard Stallman)
Date: Tue, 07 Nov 1995 09:39:00 -0000
Subject: mmap changes, mostly for aout right now
References: <199511061119.GAA06769@kr-laptop.cygnus.com>
Message-ID: <199511071739.MAA25951@mole.gnu.ai.mit.edu>

    On host systems where mmap is not available, you'll get a slight
    performance degradation compared with the older code.

I normally use a system which doesn't have mmap.
It seems to me that it ought to be easy to avoid any
performance loss on these systems
by simply using the old non-mmap code if mmap is not available.

Why not do this?

    Under Linux, using (a.out) object files read and stored over NFS, the
    performance got worse using mmap.  My guess is that this is a Linux
    problem.

This is a shame--it means this change actually does harm on today's
GNU systems.  We should not be making changes that help ONLY on non-GNU
systems and hurt GNU systems.

Can you please consult with Linux maintainers to see if this
is a bug in Linux that can be fixed straightforwardly?

If the slowness cannot be fixed soon in Linux, then please do
something in BFD to turn off use of mmap on Linux.  (This makes it
even more important to keep the performance of the non-mmap case as
good as it was before.)



From arnej@pvv.unit.no  Tue Nov  7 17:10:00 1995
From: arnej@pvv.unit.no (Arne H. Juul)
Date: Tue, 07 Nov 1995 17:10:00 -0000
Subject: mmap changes, mostly for aout right now
Message-ID: <9511080110.AA22833@datter.pvv.unit.no>

 > I've just checked in now some changes to bfd to use mmap for reading
 > files under certain circumstances.  A snapshot file should be available
 > within the next hour or so.  Please try it out and let me know of any
 > problems.
[...]
 > Under NetBSD (on i386), I saw no significant change in CPU time used
 > (though my test case was different -- many more small files in and out of
 > libraries).
[...]

Unless I'm very mistaken, using mmap is currently a *very* bad idea
on NetBSD.  The buffer cache and VM system hasn't been merged, and this
leads to lots of trouble when using mmap(), at least on NFS-mounted
filesystems - the file as seen by read/write can be wildly different from
the mmap view.  This will (hopefully) change later on, but currently using
mmap() on NetBSD in other than very carefully controlled circumstances
will probably lead to disaster.

  -  Arne H. J.



From raeburn@cygnus.com  Wed Nov  8 12:47:00 1995
From: raeburn@cygnus.com (Ken Raeburn)
Date: Wed, 08 Nov 1995 12:47:00 -0000
Subject: mmap changes, mostly for aout right now
References: <9511080110.AA22833@datter.pvv.unit.no>
Message-ID: <tx14twezve3.fsf@cujo.cygnus.com>

The file is never going to be written at the same time as mmap is
used, at least not in situations where I'd care about the results.
(If you're rewriting the input files while the linker is reading them,
you lose.)  But the file may get written by the assembler just before
it gets mapped by the linker.  Is it likely to lose in that case?  I'm
not very familiar with buffer-cache/VM interactions.

Autoconf already has one test for a known failure mode of mmap.  Can
you extend it to detect the NetBSD problems?  Would it only show up
with NFS?

I'm going to add some code so that the mmap code can be enabled or
disabled by configure options.  I want to get a release out soon, and
while the mmap code does seem to improve performance in most cases
I've tried, it's not worth risking serious instability.  It would be
nice to make it the default someday if I can get more performance out
of it, but that'll require more time and testing.



From robertl@arnet.com  Fri Nov 17 16:29:00 1995
From: robertl@arnet.com (Robert Lipe)
Date: Fri, 17 Nov 1995 16:29:00 -0000
Subject: gas patches for SCO OpenServer 5
Message-ID: <9511171820.aa20393@rjlhome.arnet.com>

Of all my patches required to host and target SCO OpenServer 5, I 
consider this one to be the most, er, questionable in its approach.

If, after looking at that, you suggest better ways to implement 
this, I'm receptive.  This does allow ELF and COFF generation with
no problems.

Thanx,
RJL


[ Yes, this is a bit of a form letter.  Sorry. I have a lot of patches 
to send. ] 

I've done a round of changes to support hosting and targeting the GNU
development tools on SCO OpenServer Release 5.  The patches have had
the test suites run on them, and I'm happy with the results.  Lots of
SCO users are interested in this stuff, as it's now possible [ for the
first time ever ] to have a complete non-SCO development chain now.

The patches have received a lot of testing and airtime, but I'll still
welcome feedback on them.  If you, the package maintainer, suggests
implementing something in a different manner, I'm receptive to that.

I understand I'll have to work with each package maintainer to get
the copyrights transferred where appropriate, so please be gentle with
me.  My employer has agreed to sign any necessary releases, but advice
on how to do that exercise once instead of nine times is welcome.

For more information about a complete GNU development distribution for
SCO OpenServer 5, see my home page at

	http://www.dgii.com/people/robertl/scods/sco_ds.html

Thanx for your help.

---
Robert Lipe     Sr. Software Engr.    Digi Internatinoal   robertl@dgii.com
*** ./gas/config/tc-i386.c.orig	Sun Aug  6 15:10:35 1995
--- ./gas/config/tc-i386.c	Wed Nov  8 22:07:18 1995
***************
*** 2970,2973 ****
--- 2970,3073 ----
  
  #endif /* BFD_ASSEMBLER? */
  
+ #if SCO_ELF
+ /* 
+ 	Heavily plagarized from  obj_elf_version.  The idea is to 
+ 	emit the SCO specific identifier in the .notes section to 
+ 	satisfy the SCO linker.
+ 
+ 	This looks more complicated than it really is.  As opposed
+ 	to the "obvious" solution, this should handle the cross dev
+ 	cases correctly.  (i.e, hosting on a 64 bit big endian
+ 	processor, but generating SCO Elf code)   Efficiency isn't
+ 	a concern, as there should be exactly one of these sections
+ 	per object module.
+ 
+ 	SCO OpenServer 5 identifies it's ELF modules with a standard
+ 	ELF .note section.
+ 
+ 	int_32 namesz  = 4 ;  Name size 
+ 	int_32 descsz  = 12 ; Descriptive information 
+ 	int_32 type    = 1 ;  
+ 	char   name[4] = "SCO" ; Originator name ALWAYS SCO + NULL 
+ 	int_32 version = (major ver # << 16)  | version of tools ;
+ 	int_32 source  = (tool_id << 16 ) | 1 ;
+ 	int_32 info    = 0 ;    These are set by the SCO tools, but we
+ 				don't know enough about hte source 
+ 				environment to set them.  SCO ld currently
+ 				ignores them, and recommends we set them
+ 				to zero.
+ 
+ */
+ 
+ #define SCO_MAJOR_VERSION 0x1
+ #define SCO_MINOR_VERSION 0x1
+ 
+ 
+ sco_id()
+ {
+   char *name;
+   unsigned int c;
+   char ch;
+   char *p;
+   asection *seg = now_seg;
+   subsegT subseg = now_subseg;
+   Elf_Internal_Note i_note;
+   Elf_External_Note e_note;
+   asection *note_secp = (asection *) NULL;
+   int i, len;
+ 
+       /* create the .note section */
+ 
+       note_secp = subseg_new (".note", 0);
+       bfd_set_section_flags (stdoutput,
+ 			     note_secp,
+ 			     SEC_HAS_CONTENTS | SEC_READONLY);
+ 
+       /* process the version string */
+ 
+       i_note.namesz = 4 ; 
+       i_note.descsz = 12 ;	/* 12 descriptive bytes */
+       i_note.type = NT_VERSION; /* Contains a version string */
+ 
+       p = frag_more (sizeof (i_note.namesz));
+       md_number_to_chars (p, (valueT) i_note.namesz, 4);
+ 
+       p = frag_more (sizeof (i_note.descsz));
+       md_number_to_chars (p, (valueT) i_note.descsz, 4);
+ 
+       p = frag_more (sizeof (i_note.type));
+       md_number_to_chars (p, (valueT) i_note.type, 4);
+ 
+       p = frag_more (4);
+       strcpy(p, "SCO"); 
+ 
+       /* Note: this is the version number of the ELF we're representing */
+       p = frag_more (4);
+       md_number_to_chars (p, (SCO_MAJOR_VERSION << 16) | (SCO_MINOR_VERSION), 4);
+ 
+       /* Here, we pick a magic number for ourselves (yes, I "registered" it
+          with SCO.
+ 	 The bottom bit shows that we are compat with the SCO ABI.
+       */
+       p = frag_more (4);
+       md_number_to_chars (p, 0x4c520000 | 0x0001, 4);
+ 
+       /*
+ 	If we knew (or cared) what the source language options were, 
+ 	we'd fill them in here.  SCO has given us permission to ignore
+ 	these and just set them to zero.
+ 	*/
+       p = frag_more (4);
+       md_number_to_chars (p, 0x0000, 4);
+ 
+       frag_align (2, 0); 
+ 
+       /* We probably can't restore the current segment, for there
+ 	likely isn't one yet... */
+       if (seg && subseg )
+ 	subseg_set (seg, subseg);
+ }
+ #endif /* SCO_ELF */
+ 
  /* end of tc-i386.c */
*** ./gas/config/sco5.mt.orig	Wed Nov  8 22:07:18 1995
--- ./gas/config/sco5.mt	Wed Nov  8 22:07:18 1995
***************
*** 0 ****
--- 1 ----
+ TDEFINES=-Dtc_init_after_args=sco_id -DSCO_ELF
*** ./gas/configure.orig	Mon Sep 18 14:31:38 1995
--- ./gas/configure	Mon Nov 13 22:36:52 1995
***************
*** 693,698 ****
--- 693,699 ----
  			     em=lynx ;;
        i386-*-sysv4* | i386-*-solaris* | i386-*-elf)
  			    fmt=elf ;;
+       i386-*-sco*elf)       fmt=elf targ=sco5 ;;
        i386-*-coff | i386-*-sysv* | i386-*-sco* | i386-*-isc*)
  			    fmt=coff targ=i386coff ;;
        i386-*-vsta)          fmt=aout ;;
***************
*** 894,900 ****
  if test ! -r ${target_frag}; then
    target_frag=/dev/null # ick! but subst_file can't be conditionalized
  fi
- 
  
  case ${user_bfd_gas}-${primary_bfd_gas} in
    yes-yes | no-no)
--- 895,900 ----
*** ./gas/configure.in.orig	Mon Sep 18 14:31:42 1995
--- ./gas/configure.in	Wed Nov  8 22:16:52 1995
***************
*** 168,173 ****
--- 168,175 ----
  			    fmt=elf ;;
        i386-*-coff | i386-*-sysv* | i386-*-sco* | i386-*-isc*)
  			    fmt=coff targ=i386coff ;;
+       i386-*-sco*elf)
+ 			    fmt=elf ;;
        i386-*-vsta)          fmt=aout ;;
        i386-*-go32)          fmt=coff targ=i386coff ;;
        i386-*-gnu*)          fmt=elf ;;



From davem@caip.rutgers.edu  Mon Nov 27 17:02:00 1995
From: davem@caip.rutgers.edu (David S. Miller)
Date: Mon, 27 Nov 1995 17:02:00 -0000
Subject: assertion failures under sunos on the sparc
Message-ID: <199511280102.UAA22199@huahaga.rutgers.edu>

It seems that if you interrupt a build of a tree halfway through, and
make doesn't clean up the half-written .o file properly, later on when
you link the screen fills with a monsterous amount of 'bfd-assertion
failure bfd/sunos.c'.  I get about 400 of them for the linux kernel
when this happens.

The error message is warranted because the linker is processing bogus
information, however this amount of verbosity is very overwhelming to
the user.  Is there a way to inform the user which object file is the
corrupt one instead during examination of objects in bfd?  If so, this
would be more useful than what happen currently.

This is with binutils-2.6

Later,
David S. Miller
davem@caip.rutgers.edu



From rms@gnu.ai.mit.edu  Mon Nov 27 18:30:00 1995
From: rms@gnu.ai.mit.edu (Richard Stallman)
Date: Mon, 27 Nov 1995 18:30:00 -0000
Subject: assertion failures under sunos on the sparc
References: <199511280102.UAA22199@huahaga.rutgers.edu>
Message-ID: <199511280230.VAA19387@mole.gnu.ai.mit.edu>

    It seems that if you interrupt a build of a tree halfway through, and
    make doesn't clean up the half-written .o file properly,

How come Make doesn't do that?  Make is supposed to delete the current
target if you kill it after that target has been altered.




From davem@caip.rutgers.edu  Mon Nov 27 18:35:00 1995
From: davem@caip.rutgers.edu (David S. Miller)
Date: Mon, 27 Nov 1995 18:35:00 -0000
Subject: assertion failures under sunos on the sparc
References: <199511280230.VAA19387@mole.gnu.ai.mit.edu>
Message-ID: <199511280235.VAA11911@huahaga.rutgers.edu>

   Date: Mon, 27 Nov 1995 21:30:28 -0500
   From: Richard Stallman <rms@gnu.ai.mit.edu>
   CC: gas2@cygnus.com

       It seems that if you interrupt a build of a tree halfway through, and
       make doesn't clean up the half-written .o file properly,

   How come Make doesn't do that?  Make is supposed to delete the current
   target if you kill it after that target has been altered.

I severly apologize, it now seems that I am getting bfd assertion
failures like mad even for what appears to be correct builds of my
sources.  This is with gcc-2.7.1 and binutils-2.6 on the sparc under
SunOS.

For all I know, make was doing the correct thing.

I will hunt this down some more, it looks pretty bad.

Later,
David S. Miller
davem@caip.rutgers.edu



From davem@caip.rutgers.edu  Mon Nov 27 19:52:00 1995
From: davem@caip.rutgers.edu (David S. Miller)
Date: Mon, 27 Nov 1995 19:52:00 -0000
Subject: more on bfd assertion failures.
Message-ID: <199511280352.WAA02796@huahaga.rutgers.edu>

The failure occurs in bfs/sunos.c:sunos_scan_ext_relocs() in the
following assertions:

      BFD_ASSERT (r_type == RELOC_JMP_TBL
		  || (h->flags & SUNOS_REF_REGULAR) != 0);

The sunos_link_hash_entry looks like

(gdb) p *h
$3 = {root = {root = {root = {next = 0x0, string = 0x6e290 "_pte_exprotect", 
        hash = 299445140}, type = bfd_link_hash_defined, next = 0x67aa8, u = {undef = {
          abfd = 0x1cc}, def = {value = 460, section = 0x69c70}, i = {link = 0x1cc, 
          warning = 0x69c70 ""}, c = {size = 460, p = 0x69c70}}}, written = false, 
    indx = -1}, dynindx = -2, dynstr_index = -1, got_offset = 0, plt_offset = 0, 
  flags = 2 '\002'}

and r_type has the value '8'

I'll keep searching.

Later,
David S. Miller
davem@caip.rutgers.edu



From hjl@nynexst.com  Mon Nov 27 20:01:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 27 Nov 1995 20:01:00 -0000
Subject: ELF weirdness
References: <m0tJDVE-000GOwC@gwar.ardi.com>
Message-ID: <9511280344.AA02910@nynexst.com>

> 
> This is an ELF-specific question, so I thought I'd ask you before
> looking further.  I'm running gcc 2.7.0.  I have not yet installed
> 2.7.1.  Compiling this program with "gcc foo.c -o foo":
> 
> int
> main (void)
> {
>   static int x __attribute__ ((aligned (16)));
>   return 0;
> }
> 
> Results in this error:
> 
> gwar:~$ gcc foo.c -o foo
> foo: Not enough room for program headers (allocated 5, need 6)
> /usr/i486-linux/bin/ld: final link failed: Bad value
> 
> 
> Compiling with "gcc -b i486-linuxaout foo.c -o foo" works fine.
> 
> Does this happen to you?  Is this a known bug?  Thanks!
> 

It looks like a gcc/gas bug. In c-common.c around line 515, there is

	align = TREE_INT_CST_LOW (align_expr) * BITS_PER_UNIT;

It seems to work ok with the a.out format. But the gcc for x86/ELF
outputs the .comm stuff differently depending on if the symbol is
local or not. If it is local, the alignment will be divided by
BITS_PER_UNIT. If the source code is changed to

static int x __attribute__ ((aligned (16))) = 0;

gcc will complain:

warning: alignment of `x' is greater than maximum object file alignment

But gas seems not in sync with gcc. I don't know who is correct. I think
gas may be correct. Gcc may be changed to

	align = TREE_INT_CST_LOW (align_expr)

and output local symbols with log2 (align) instead of divide it by
BITS_PER_UNIT. But I don't know if the changes will work on all
platforms.



H.J.



From davem@caip.rutgers.edu  Mon Nov 27 20:01:00 1995
From: davem@caip.rutgers.edu (David S. Miller)
Date: Mon, 27 Nov 1995 20:01:00 -0000
Subject: more datapoints
Message-ID: <199511280401.XAA05548@huahaga.rutgers.edu>

The linker produces the proper final executable with binutils-2.5.2

Later,
David S. Miller
davem@caip.rutgers.edu



From davem@caip.rutgers.edu  Mon Nov 27 20:37:00 1995
From: davem@caip.rutgers.edu (David S. Miller)
Date: Mon, 27 Nov 1995 20:37:00 -0000
Subject: bfd assertion bug found
Message-ID: <199511280437.XAA07279@huahaga.rutgers.edu>

It seems that the linker interprets arguments differently in 2.6,
if I specify '-N' to the linker in 2.5.2 it produces a static final
object, in 2.6 it sets config.dynamic_link to true.  This is what
causes trouble when relocations are being scanned.

Later,
David S. Miller
davem@caip.rutgers.edu



From hjl@nynexst.com  Mon Nov 27 22:06:00 1995
From: hjl@nynexst.com (H.J. Lu)
Date: Mon, 27 Nov 1995 22:06:00 -0000
Subject: comm/local/ELF/gas/gcc
Message-ID: <9511280605.AA10129@nynexst.com>

I am kind of confused by the asm output under x86/ELF:

1. There is a limit of MAX_OFILE_ALIGNMENT in bits for maximum alignment.
   But it only applies to symbols in data, not those in bss/common.
2. __attribute__ ((aligned (n))) doesn't do anything useful if n > 4
  for integer or 8 for double. Should a better MAX_OFILE_ALIGNMENT
  be defined for x86?
3. The x86/ELF gas is kind of strange:

	.local x.2
	.comm   x.2,4,4

and

	.comm  x.2,4,16

mean the same alignment. But I checked as on Sparc/Solaris.

	.local x.2
	.comm   x.2,4,16

and

	.comm  x.2,4,16

have the same alignment. Personally I prefer Solaris. But if most of
ELF/SVR4 as does the same as gas, I guess my opinion doesn't count
much.

I don't know what the correct fixes are. I hope:

1. Increase MAX_OFILE_ALIGNMENT for x86 to 0x1000 or somthing like that.
2. Change gas to work like Solaris.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com



From ian@cygnus.com  Mon Nov 27 23:00:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 27 Nov 1995 23:00:00 -0000
Subject: more on bfd assertion failures.
References: <199511280352.WAA02796@huahaga.rutgers.edu>
Message-ID: <9511280700.AA07388@tweedledumb.cygnus.com>

   Date: Mon, 27 Nov 1995 22:52:09 -0500
   From: "David S. Miller" <davem@caip.rutgers.edu>

   The failure occurs in bfs/sunos.c:sunos_scan_ext_relocs() in the
   following assertions:

	 BFD_ASSERT (r_type == RELOC_JMP_TBL
		     || (h->flags & SUNOS_REF_REGULAR) != 0);

   The sunos_link_hash_entry looks like

   (gdb) p *h
   $3 = {root = {root = {root = {next = 0x0, string = 0x6e290 "_pte_exprotect", 
	   hash = 299445140}, type = bfd_link_hash_defined, next = 0x67aa8, u = {undef = {
	     abfd = 0x1cc}, def = {value = 460, section = 0x69c70}, i = {link = 0x1cc, 
	     warning = 0x69c70 ""}, c = {size = 460, p = 0x69c70}}}, written = false, 
       indx = -1}, dynindx = -2, dynstr_index = -1, got_offset = 0, plt_offset = 0, 
     flags = 2 '\002'}

   and r_type has the value '8'

I don't understand this.  The value of SUNOS_REF_REGULAR is 2, so why
is the assertion failing?

Ian



From ian@cygnus.com  Mon Nov 27 23:04:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 27 Nov 1995 23:04:00 -0000
Subject: bfd assertion bug found
References: <199511280437.XAA07279@huahaga.rutgers.edu>
Message-ID: <9511280704.AA07439@tweedledumb.cygnus.com>

   Date: Mon, 27 Nov 1995 23:37:29 -0500
   From: "David S. Miller" <davem@caip.rutgers.edu>

   It seems that the linker interprets arguments differently in 2.6,
   if I specify '-N' to the linker in 2.5.2 it produces a static final
   object, in 2.6 it sets config.dynamic_link to true.  This is what
   causes trouble when relocations are being scanned.

It sounds like a bug that -N does not cause a static link.  However, I
do not understand how it could produce the symptoms you are reporting.
I have no trouble doing a dynamic link with -N--the final output does
not run, since the dynamic information is misplaced, but the link does
succeed without any assertion errors.  I think you must be seeing two
different problems.

Ian



From davem@caip.rutgers.edu  Tue Nov 28 00:08:00 1995
From: davem@caip.rutgers.edu (David S. Miller)
Date: Tue, 28 Nov 1995 00:08:00 -0000
Subject: bfd assertion bug found
References: <9511280704.AA07439@tweedledumb.cygnus.com>
Message-ID: <199511280808.DAA11308@huahaga.rutgers.edu>

   Date: Tue, 28 Nov 95 02:04:04 EST
   From: Ian Lance Taylor <ian@cygnus.com>
   Cc: gas2@cygnus.com

      Date: Mon, 27 Nov 1995 23:37:29 -0500
      From: "David S. Miller" <davem@caip.rutgers.edu>

      It seems that the linker interprets arguments differently in 2.6,
      if I specify '-N' to the linker in 2.5.2 it produces a static final
      object, in 2.6 it sets config.dynamic_link to true.  This is what
      causes trouble when relocations are being scanned.

   It sounds like a bug that -N does not cause a static link.  However, I
   do not understand how it could produce the symptoms you are reporting.
   I have no trouble doing a dynamic link with -N--the final output does
   not run, since the dynamic information is misplaced, but the link does
   succeed without any assertion errors.  I think you must be seeing two
   different problems.

And whats even stranger is that I used binutils-2.6 until today with
no problems, but I made quite some extensive changes to my sources
before I did the first build which failed, I must be tickling an
obscure bug of some sort.

Later,
David S. Miller
davem@caip.rutgers.edu





From ian@cygnus.com  Tue Nov 28 08:55:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Tue, 28 Nov 1995 08:55:00 -0000
Subject: comm/local/ELF/gas/gcc
References: <9511280605.AA10129@nynexst.com>
Message-ID: <199511281655.LAA06540@sanguine.cygnus.com>

   From: hjl@nynexst.com (H.J. Lu)
   Date: Tue, 28 Nov 95 1:05:35 EST

   1. There is a limit of MAX_OFILE_ALIGNMENT in bits for maximum alignment.
      But it only applies to symbols in data, not those in bss/common.

The problem would appear to be that gcc defaults to value of
MAX_OFILE_ALIGNMENT to BIGGEST_ALIGNMENT.  For the i386,
BIGGEST_ALIGNMENT is 32 or 64.  It would be reasonable for
config/svr4.h in gcc to set MAX_OFILE_ALIGNMENT to 0x80000000.
However, I don't know what the consequences are of requesting an
alignment larger than BIGGEST_ALIGNMENT.  Is that supposed to work or
not?

   3. The x86/ELF gas is kind of strange:

	   .local x.2
	   .comm   x.2,4,4

   and

	   .comm  x.2,4,16

   mean the same alignment.

This was a gas bug.  It is fixed in the 2.6 release.

Ian



From joel@merlin.gcs.redstone.army.mil  Fri Dec  1 13:47:00 1995
From: joel@merlin.gcs.redstone.army.mil (Joel Sherrill)
Date: Fri, 01 Dec 1995 13:47:00 -0000
Subject: PowerPC Instructions
Message-ID: <Pine.SV4.3.91.951201151523.10603G-100000@merlin>

Hi,

I have a user submitted port of RTEMS to the PowerPC (IBM 403) and it uses
some instructions (or alternate names) he added to his local gas.  I am
using binutils 2.6 configured for powerpc-elf.  I know of the following
based on the error messages: 

/usr1/tmp/cca004pL.s: Assembler messages:
/usr1/tmp/cca004pL.s:54: Error: Unrecognized opcode: `mtsprg3'
/usr1/tmp/cca004pL.s:56: Error: Unrecognized opcode: `mtsprg2'
/usr1/tmp/cca004pL.s:131: Error: Unrecognized opcode: `mtexier'
/usr1/tmp/cca004pL.s:137: Error: Unrecognized opcode: `mttsr'
/usr1/tmp/cca004pL.s:143: Error: Unrecognized opcode: `mttsr'

I am not a PowerPC expert by any definition. (OK I do own a few PowerPC 
manuals :).)   What is the best thing for me to do?  I see two options:

1.  Merge his patches.

2.  If possible, change the instruction names to standard ones.

+----------------------------------------+--------------------------------+
| Joel Sherrill                          | Sr. Computer Scientist         |
| joel@merlin.gcs.redstone.army.mil      | On-Line Applications Research  |
| Ask me about RTEMS: a free real-time   | Huntsville AL 35805            |
|   multiprocessor executive!            | (205) 883-0131                 |
+----------------------------------------+--------------------------------+



From ian@cygnus.com  Fri Dec  1 13:56:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Fri, 01 Dec 1995 13:56:00 -0000
Subject: PowerPC Instructions
References: <Pine.SV4.3.91.951201151523.10603G-100000@merlin>
Message-ID: <199512012156.QAA17270@sanguine.cygnus.com>

   Date: Fri, 1 Dec 1995 15:19:15 -0600 (CST)
   From: Joel Sherrill <joel@merlin.gcs.redstone.army.mil>

   I have a user submitted port of RTEMS to the PowerPC (IBM 403) and it uses
   some instructions (or alternate names) he added to his local gas.  I am
   using binutils 2.6 configured for powerpc-elf.  I know of the following
   based on the error messages: 

   /usr1/tmp/cca004pL.s: Assembler messages:
   /usr1/tmp/cca004pL.s:54: Error: Unrecognized opcode: `mtsprg3'
   /usr1/tmp/cca004pL.s:56: Error: Unrecognized opcode: `mtsprg2'
   /usr1/tmp/cca004pL.s:131: Error: Unrecognized opcode: `mtexier'
   /usr1/tmp/cca004pL.s:137: Error: Unrecognized opcode: `mttsr'
   /usr1/tmp/cca004pL.s:143: Error: Unrecognized opcode: `mttsr'

These are all ``move to special register'' instructions.  If you can
find out the appropriate special register number, it should be
possible to replace them all with the mtspr instruction.

Incidentally, gas already supports mtsprg with two operands.  I don't
know what the other two are.

If these are standard instructions for the 403, then you should patch
opcodes/ppc-opc.c and send in the patch.  Look for mtmq to see the
mtspr variants.

Ian



From joel@merlin.gcs.redstone.army.mil  Fri Dec  1 14:51:00 1995
From: joel@merlin.gcs.redstone.army.mil (Joel Sherrill)
Date: Fri, 01 Dec 1995 14:51:00 -0000
Subject: Some PA-RISC 7200 special instructions
Message-ID: <Pine.SV4.3.91.951201163415.10603K-100000@merlin>

Here is a patch to an older version of gas which was sent to me by the
submitted of the RTEMS PA-RISC port.  I do not know if the patch 
correctly applies to binutils 2.6 but I do know the instructions are not 
in the file.

[Yes I am cleaning my plate of oddball tool issues this afternoon. :)]

>From tbennett@divnc.com Wed Sep 13 09:53 CDT 1995
Return-Path: <tbennett@divnc.com>
Received: from ogon.divnc.com by merlin.gcs.redstone.army.mil (5.0/SMI-SVR4)
	id AA01349; Wed, 13 Sep 1995 09:53:49 +0600
Received: from divnc.divnc.com (divnc.divnc.com [199.72.130.1]) by ogon.divnc.com (8.6.12/8.6.12) with ESMTP id KAA20221 for <joel@merlin.gcs.redstone.army.mil>; Wed, 13 Sep 1995 10:56:47 -0400
Received: from uh-oh.divnc.com (uh-oh.divnc.com [199.72.130.18]) by divnc.divnc.com (8.6.12/8.6.12) with ESMTP id KAA28777 for <joel@merlin.gcs.redstone.army.mil>; Wed, 13 Sep 1995 10:56:45 -0400
Received: (from tbennett@localhost) by uh-oh.divnc.com (8.6.12/8.6.12) id KAA27893; Wed, 13 Sep 1995 10:56:44 -0400
Date: Wed, 13 Sep 1995 10:56:44 -0400
From: tbennett@divnc.com
Message-Id: <199509131456.KAA27893@uh-oh.divnc.com>
To: joel@merlin.gcs.redstone.army.mil
Subject: Re: Opcodes
In-Reply-To: message of Joel Sherrill (on Wed, Sep 13/1995)
References: <Pine.SV4.3.91.950913092709.29048A-100000@merlin>
Content-Type: text
Content-Length: 822
Status: RO
X-Status: 

apply this to include/opcode/hppa.h and rebuild gas.
--tony

*** /tmp/geta27888	Wed Sep 13 10:56:09 1995
--- /tmp/getb27888	Wed Sep 13 10:56:09 1995
***************
*** 372,377 ****
--- 372,385 ----
  { "fice",       0x040002c0, 0xfc003fdf, "Zx(b)"},
  { "diag",       0x14000000, 0xfc000000, "D"},
  
+ /* Following group is 72000 specific */
+ { "mtcpu",      0x14001600, 0xfc00ffff, "x,^"},
+ { "mfcpu",      0x14001A00, 0xfc00ffff, "^,x"},
+ { "tocen",      0x14403600, 0xffffffff, ""},
+ { "tocdis",     0x14401620, 0xffffffff, ""},
+ { "shdwgr",     0x14402600, 0xffffffff, ""},
+ { "grshdw",     0x14400620, 0xffffffff, ""},
+ 
  /* gfw and gfr are not in the HP PA 1.1 manual, but they are in either
     the Timex FPU or the Mustang ERS (not sure which) manual.  */
  { "gfw",	0x04001680, 0xfc003fdf, "Zx(s,b)"},


From joel@merlin.gcs.redstone.army.mil  Fri Dec  1 18:51:00 1995
From: joel@merlin.gcs.redstone.army.mil (Joel Sherrill)
Date: Fri, 01 Dec 1995 18:51:00 -0000
Subject: Some PA-RISC 7200 special instructions
References: <Pine.SV4.3.91.951201163415.10603K-100000@merlin>
Message-ID: <Pine.SV4.3.91.951201204629.28565A-100000@merlin>

Boy do I feel sloppy... I must have forgotten to actually include the patch.
At least it is not there now.

On Fri, 1 Dec 1995, Joel Sherrill wrote:

> Here is a patch to an older version of gas which was sent to me by the
> submitted of the RTEMS PA-RISC port.  I do not know if the patch 
> correctly applies to binutils 2.6 but I do know the instructions are not 
> in the file.
> 
> [Yes I am cleaning my plate of oddball tool issues this afternoon. :)]


apply this to include/opcode/hppa.h and rebuild gas.
--tony

*** /tmp/geta27888	Wed Sep 13 10:56:09 1995
--- /tmp/getb27888	Wed Sep 13 10:56:09 1995
***************
*** 372,377 ****
--- 372,385 ----
  { "fice",       0x040002c0, 0xfc003fdf, "Zx(b)"},
  { "diag",       0x14000000, 0xfc000000, "D"},
  
+ /* Following group is 72000 specific */
+ { "mtcpu",      0x14001600, 0xfc00ffff, "x,^"},
+ { "mfcpu",      0x14001A00, 0xfc00ffff, "^,x"},
+ { "tocen",      0x14403600, 0xffffffff, ""},
+ { "tocdis",     0x14401620, 0xffffffff, ""},
+ { "shdwgr",     0x14402600, 0xffffffff, ""},
+ { "grshdw",     0x14400620, 0xffffffff, ""},
+ 
  /* gfw and gfr are not in the HP PA 1.1 manual, but they are in either
     the Timex FPU or the Mustang ERS (not sure which) manual.  */
  { "gfw",	0x04001680, 0xfc003fdf, "Zx(s,b)"},


From arnej@pvv.unit.no  Sat Dec  2 12:57:00 1995
From: arnej@pvv.unit.no (Arne H. Juul)
Date: Sat, 02 Dec 1995 12:57:00 -0000
Subject: .gas.warning sections
Message-ID: <9512022057.AA11248@datter.pvv.unit.no>

I have been looking at getting warnings from gnu ld when
used on mips-dec-netbsd platform (this is "plain" ELF on
little-endian mips).  This deals with both GCC, the assembler
and the linker, so forgive me if this message is rather long-winded.

So from looking in the GNU libc it looks like this should be
done like in this simple example:

#define link_warning(symbol, msg)                       \
  static const char __evoke_link_warning_##symbol[]     \
    __attribute__ ((section (".gnu.warning." #symbol))) = msg;

link_warning(null1, "This program uses null1(), which is pointless.\n");
int null1(void) {}

At first, this doesn't get through gcc, I just get
"section attributes are not supported for this target".  From
looking at c-common.c this is because ASM_OUTPUT_SECTION_NAME,
which should mean that the target platform doesn't support
arbitrarily named sections.

Now in config/mips the only file defining ASM_OUTPUT_SECTION_NAME
is elf64.h, which has this code in it:

/* A C statement to output something to the assembler file to switch to section
   NAME for object DECL which is either a FUNCTION_DECL, a VAR_DECL or
   NULL_TREE.  Some target formats do not support arbitrary sections.  Do not
   define this macro in such cases.  */

#define ASM_OUTPUT_SECTION_NAME(F, DECL, NAME) \
do {                                                            \
  extern FILE *asm_out_text_file;                               \
  if ((DECL) && TREE_CODE (DECL) == FUNCTION_DECL)              \
    fprintf (asm_out_text_file, "\t.section %s,\"ax\",@progbits\n", (NAME)); \
  else if ((DECL) && TREE_READONLY (DECL))                      \
    fprintf (F, "\t.section %s,\"a\",@progbits\n", (NAME));     \
  else                                                          \
    fprintf (F, "\t.section %s,\"aw\",@progbits\n", (NAME));    \
} while (0)

This is probably really an assembler question:  Is all this stuff really
necessary, and what does the extra @progbits mean?  Stuffing this
code into netbsd.h as well seemed to work ok, but then I looked a bit
further, and while svr4.h has a somewhat simple version of this,
h8300/h8300.h has something more like what I had imagined:
#define ASM_OUTPUT_SECTION_NAME(FILE, DECL, NAME) \
  fprintf (FILE, "\t.section %s\n", NAME)

Stuffing this code into netbsd.h instead seemed to work just as well.
I would welcome enlightenment on this issue. (Maybe it should
be common code in config/mips/something.h?)

Another (maybe somewhat irrelevant) inquiry:  With any of the
two variants above gcc accepts my test file and gas produces an
object file with the required section.  When linking a 'main'-type
file which uses the symbol in question (null1 for my example)
I also get my warning:
tm.o: In function `main':
tm.c(.text+0x28): This program uses null1(), which is pointless.

However, if I change my test file to have *only* the warning section
for null1 (not the function definition itself), I get the following
behaviour:

gcc: Internal compiler error: program ld got fatal signal 6

This is if the program doesn't reference null1() at all.
If I do reference null1() it works right:

tm.o: In function `main':
tm.c(.text+0x28): This program uses null1(), which is pointless.
tm.c(.text+0x28): undefined reference to `null1'

This seems to be a (probably obscure) bug in ld, but hopefully it
shouldn't give me any "real" problems, right?

Yours,
  - Arne H. Juul



From roland@gnu.ai.mit.edu  Sat Dec  2 13:49:00 1995
From: roland@gnu.ai.mit.edu (Roland McGrath)
Date: Sat, 02 Dec 1995 13:49:00 -0000
Subject: .gas.warning sections
References: <9512022057.AA11248@datter.pvv.unit.no>
Message-ID: <199512022148.QAA14056@churchy.gnu.ai.mit.edu>

> At first, this doesn't get through gcc, I just get
> "section attributes are not supported for this target".  From
> looking at c-common.c this is because ASM_OUTPUT_SECTION_NAME,
> which should mean that the target platform doesn't support
> arbitrarily named sections.

That's right.  This should be defined by the tm.h file.  It seems there is
no existing GCC target which is set up for proper use of ELF on MIPS.

> Now in config/mips the only file defining ASM_OUTPUT_SECTION_NAME
> is elf64.h, which has this code in it:
>
> /* A C statement to output something to the assembler file to switch to section
>    NAME for object DECL which is either a FUNCTION_DECL, a VAR_DECL or
>    NULL_TREE.  Some target formats do not support arbitrary sections.  Do not
>    define this macro in such cases.  */
>
> #define ASM_OUTPUT_SECTION_NAME(F, DECL, NAME) \
> do {                                                            \
>   extern FILE *asm_out_text_file;                               \
>   if ((DECL) && TREE_CODE (DECL) == FUNCTION_DECL)              \
>     fprintf (asm_out_text_file, "\t.section %s,\"ax\",@progbits\n", (NAME)); \
>   else if ((DECL) && TREE_READONLY (DECL))                      \
>     fprintf (F, "\t.section %s,\"a\",@progbits\n", (NAME));     \
>   else                                                          \
>     fprintf (F, "\t.section %s,\"aw\",@progbits\n", (NAME));    \
> } while (0)

That code also appears in config/svr4.h; its purpose is to select the right
section attributes based on the symbol being defined.  If it is a function,
the section is read-only, executable; if it is a read-only variable, the
section is read-only data; if it is a writable variable, the section is
read/write data.

The @progbits could probably be omitted, but its purpose in the ELF
.section directive is to indicate the type of data in the section is
program data (as opposed to symbols or debugging info or somesuch).

> Stuffing this code into netbsd.h instead seemed to work just as well.
> I would welcome enlightenment on this issue. (Maybe it should
> be common code in config/mips/something.h?)

It would be lovely if there were a config/mips/svr4.h or somesuch, for the
various MIPS platforms that use ELF and SVR4 shared libraries.  Kazumoto
Kojima <kkojima@info.kanagawa-u.ac.jp> may have done some work in this
area, in his port to the mips-gnu platform.

> Another (maybe somewhat irrelevant) inquiry:  With any of the
> two variants above gcc accepts my test file and gas produces an
> object file with the required section.  When linking a 'main'-type
> file which uses the symbol in question (null1 for my example)
> I also get my warning:
> tm.o: In function `main':
> tm.c(.text+0x28): This program uses null1(), which is pointless.
>
> However, if I change my test file to have *only* the warning section
> for null1 (not the function definition itself), I get the following
> behaviour:
>
> gcc: Internal compiler error: program ld got fatal signal 6

This is clearly an ld bug.  Are you using binutils 2.6?  You should report
this bug to bug-gnu-utils so it can be fixed.



From ian@cygnus.com  Mon Dec  4 08:25:00 1995
From: ian@cygnus.com (Ian Lance Taylor)
Date: Mon, 04 Dec 1995 08:25:00 -0000
Subject: .gas.warning sections
References: <9512022057.AA11248@datter.pvv.unit.no>
Message-ID: <199512041625.LAA20339@sanguine.cygnus.com>

   From: "Arne H. Juul" <arnej@pvv.unit.no>
   Date: Sat, 2 Dec 1995 21:57:49 +0100

   #define ASM_OUTPUT_SECTION_NAME(F, DECL, NAME) \
   do {                                                            \
     extern FILE *asm_out_text_file;                               \
     if ((DECL) && TREE_CODE (DECL) == FUNCTION_DECL)              \
       fprintf (asm_out_text_file, "\t.section %s,\"ax\",@progbits\n", (NAME)); \
     else if ((DECL) && TREE_READONLY (DECL))                      \
       fprintf (F, "\t.section %s,\"a\",@progbits\n", (NAME));     \
     else                                                          \
       fprintf (F, "\t.section %s,\"aw\",@progbits\n", (NAME));    \
   } while (0)

   This is probably really an assembler question:  Is all this stuff really
   necessary, and what does the extra @progbits mean?

Yes, all that stuff is really necessary.  I'm not sure why you say the
@progbits is extra.  It means that the section contains data that
forms part of the program image; by way of comparison, a DWARF
debugging section contains data, but it is not part of the program
image.  This ASM_OUTPUT_SECTION_NAME macro is very similar to the one
in config/svr4.h, except that it uses asm_out_text_file instead of F
when selecting the section for a function declaration.  This is
required for the way the MIPS backend handles global pointer
optimizations.

   Stuffing this
   code into netbsd.h as well seemed to work ok, but then I looked a bit
   further, and while svr4.h has a somewhat simple version of this,
   h8300/h8300.h has something more like what I had imagined:
   #define ASM_OUTPUT_SECTION_NAME(FILE, DECL, NAME) \
     fprintf (FILE, "\t.section %s\n", NAME)

It's definitely best to tell the assembler the flags and type to give
the section.  It never hurts, and sometimes it is required.  You also
need to keep the asm_out_text_file distinction in order for functions
to be put in the right place.

   However, if I change my test file to have *only* the warning section
   for null1 (not the function definition itself), I get the following
   behaviour:

   gcc: Internal compiler error: program ld got fatal signal 6

This is a linker bug.  Here's the patch.

Ian

Index: elflink.h
===================================================================
RCS file: /cvs/cvsfiles/devo/bfd/elflink.h,v
retrieving revision 1.21
diff -u -r1.21 elflink.h
--- elflink.h	1995/12/01 19:47:51	1.21
+++ elflink.h	1995/12/04 16:14:12
@@ -2508,6 +2508,12 @@
 
     case bfd_link_hash_indirect:
     case bfd_link_hash_warning:
+      /* We can't represent these symbols in ELF.  A warning symbol
+         may have come from a .gnu.warning.SYMBOL section anyhow.  We
+         just put the target symbol in the hash table.  If the target
+         symbol does not really exist, don't do anything.  */
+      if (h->root.u.i.link->type == bfd_link_hash_new)
+	return true;
       return (elf_link_output_extsym
 	      ((struct elf_link_hash_entry *) h->root.u.i.link, data));
     }



From joel@merlin.gcs.redstone.army.mil  Mon Dec  4 14:37:00 1995
From: joel@merlin.gcs.redstone.army.mil (Joel Sherrill)
Date: Mon, 04 Dec 1995 14:37:00 -0000
Subject: PA ELF core dump
Message-ID: <Pine.SV4.3.91.951204160305.153K-100000@merlin>

gcc 2.7.2 and binutils 2.6

config.status:

#!/bin/sh
# This file was generated automatically by configure.  Do not edit.
# This directory was configured as follows:
./configure --verbose --host=sparc-sun-solaris2.3 --target=hppa1.1-hp-elf 
--with-gnu-as --with-gnu-ld --with-targets=all 
--exec-prefix=/net/merlin/usr1/oar/gnu/cross/hppa1.1-hp-elf/ 
--prefix=/net/merlin/usr1/oar/gnu/cross/hppa1.1-hp-elf/ --norecursion 
# using "config/mh-solaris"

I was linking a long list of objects using an explicit invocation of ld.
It dumped core.  Here is the gdb backtrace:

GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.14 (sparc-sun-solaris2.3), 
Copyright 1995 Free Software Foundation, Inc...
Core was generated by 
`/net/merlin/usr1/oar/gnu/cross/hppa1.1-hp-elf/lib/gcc-lib/hppa1.1-hp-elf/2.7.2/'.
Program terminated with signal 10, Bus error.
Reading symbols from /lib/libc.so.1...done.
Reading symbols from /lib/libdl.so.1...done.
#0  0xef77846c in _smalloc ()
(gdb) bt
#0  0xef77846c in _smalloc ()
#1  0xef7784b0 in malloc ()
#2  0x47964 in elf32_hppa_size_stubs (stub_bfd=0x85a68, 
output_bfd=0x84dd8, 
    link_info=0x82e08) at elf32-hppa.c:2819
#3  0x2bd24 in hppaelf_finish () at ehppaelf.c:171
#4  0x294c8 in ldemul_finish () at ldemul.c:90
#5  0x22718 in lang_process () at ldlang.c:2786
#6  0x24608 in main (argc=39, argv=0xefffe7b4) at ldmain.c:295
(gdb) 

The only "exciting options" are these:

-Tdata 0x40001000 -Ttext 0x00001000  -a archive 

I started with a hpux ld command and have only changed the text and data 
address arguments.  Looking at this closer, I don't have as clue what the 
-a option is supposed to do.  

How should I approach this?  What can I do to fix it or what information 
can I offer which will help to fix this problem?


+----------------------------------------+--------------------------------+
| Joel Sherrill                          | Sr. Computer Scientist         |
| joel@merlin.gcs.redstone.army.mil      | On-Line Applications Research  |
| Ask me about RTEMS: a free real-time   | Huntsville AL 35805            |
|   multiprocessor executive!            | (205) 883-0131                 |
+----------------------------------------+--------------------------------+



From joel@merlin.gcs.redstone.army.mil  Tue Dec  5 13:22:00 1995
From: joel@merlin.gcs.redstone.army.mil (Joel Sherrill)
Date: Tue, 05 Dec 1995 13:22:00 -0000
Subject: more on hppa1.1-elf ld core dump
Message-ID: <Pine.SV4.3.91.951205143621.19688F-100000@merlin>

I am trying to build RTEMS (i.e. cross to an embedded target) using a
solaris2.3 (sparc) -> hppa1.1-hp-elf configuration on binutils 2.6 and gcc
2.7.2.  ld core dumps on two of the approximately 90 RTEMS tests.  The only
thing I can think of that these two tests have in common is that they both
use floating point.  The other tests avoid the use of floating point.  Does
this hint help anyone? 

+----------------------------------------+--------------------------------+
| Joel Sherrill                          | Sr. Computer Scientist         |
| joel@merlin.gcs.redstone.army.mil      | On-Line Applications Research  |
| Ask me about RTEMS: a free real-time   | Huntsville AL 35805            |
|   multiprocessor executive!            | (205) 883-0131                 |
+----------------------------------------+--------------------------------+



From hassey@dg-rtp.dg.com  Thu Dec 28 10:42:00 1995
From: hassey@dg-rtp.dg.com (John Hassey)
Date: Thu, 28 Dec 1995 10:42:00 -0000
Subject: Pentium Pro changes
Message-ID: <199512281841.NAA20698@bigbird.rtp.dg.com>

  Here are some diffs which add Pentium Pro instruction support.
  Could someone with access to the sources install these and send
  me e-mail.

  thanks,
  john.

diff -rc2 gas-951221.orig/gas/ChangeLog gas-951221/gas/ChangeLog
*** gas-951221.orig/gas/ChangeLog	Thu Dec 21 04:28:58 1995
--- gas-951221/gas/ChangeLog	Thu Dec 28 13:27:02 1995
***************
*** 1,2 ****
--- 1,7 ----
+ Thu Dec 28 13:22:59 1995  John Hassey  <hassey@rtp.dg.com>
+ 
+ 	* config/tc-i386.c (md_assemble): Fixed test against registers
+ 	when trying to determine operand size from destination register.
+ 
  Wed Dec 20 14:57:17 1995  Ian Lance Taylor  <ian@cygnus.com>
  
diff -rc2 gas-951221.orig/gas/config/tc-i386.c gas-951221/gas/config/tc-i386.c
*** gas-951221.orig/gas/config/tc-i386.c	Tue Nov 28 14:21:17 1995
--- gas-951221/gas/config/tc-i386.c	Thu Dec 28 13:36:14 1995
***************
*** 1,4 ****
  /* i386.c -- Assemble code for the Intel 80386
!    Copyright (C) 1989, 1991, 1992, 1993 Free Software Foundation.
  
     This file is part of GAS, the GNU Assembler.
--- 1,4 ----
  /* i386.c -- Assemble code for the Intel 80386
!    Copyright (C) 1989, 1991, 1992, 1993, 1995 Free Software Foundation.
  
     This file is part of GAS, the GNU Assembler.
***************
*** 1155,1161 ****
  	  if (i.types[op] & Reg)
  	    {
! 	      i.suffix = ((i.types[op] == Reg8) ? BYTE_OPCODE_SUFFIX :
! 			  (i.types[op] == Reg16) ? WORD_OPCODE_SUFFIX :
! 			  DWORD_OPCODE_SUFFIX);
  	    }
        }
--- 1155,1161 ----
  	  if (i.types[op] & Reg)
  	    {
! 	      i.suffix = ((i.types[op] & Reg8) ? BYTE_OPCODE_SUFFIX :
! 			  (i.types[op] & Reg16) ? WORD_OPCODE_SUFFIX :
! 			  (i.types[op] & Reg32) ? DWORD_OPCODE_SUFFIX : 0);
  	    }
        }
diff -rc2 gas-951221.orig/include/opcode/ChangeLog gas-951221/include/opcode/ChangeLog
*** gas-951221.orig/include/opcode/ChangeLog	Thu Dec 21 04:30:26 1995
--- gas-951221/include/opcode/ChangeLog	Thu Dec 28 13:35:17 1995
***************
*** 1,2 ****
--- 1,6 ----
+ Thu Dec 28 13:27:53 1995  John Hassey  <hassey@rtp.dg.com>
+ 
+ 	* i386.h: Added Pentium Pro instructions.
+ 
  Thu Nov  2 22:59:22 1995  Ian Lance Taylor  <ian@cygnus.com>
  
diff -rc2 gas-951221.orig/include/opcode/i386.h gas-951221/include/opcode/i386.h
*** gas-951221.orig/include/opcode/i386.h	Fri Oct 20 18:22:05 1995
--- gas-951221/include/opcode/i386.h	Thu Dec 28 13:36:20 1995
***************
*** 758,761 ****
--- 758,795 ----
  {"cmpxchg8b", 1, 0x0fc7, 1, Modrm, { Mem, 0, 0} },
  
+ /* Pentium Pro extensions */
+ {"rdpmc", 0, 0x0f33, _, NoModrm, { 0, 0, 0} },
+ 
+ {"cmovo",  2, 0x0f40, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovno", 2, 0x0f41, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovb",  2, 0x0f42, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovae", 2, 0x0f43, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmove",  2, 0x0f44, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovne", 2, 0x0f45, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovbe", 2, 0x0f46, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmova",  2, 0x0f47, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovs",  2, 0x0f48, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovns", 2, 0x0f49, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovp",  2, 0x0f4a, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovnp", 2, 0x0f4b, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovl",  2, 0x0f4c, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovge", 2, 0x0f4d, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovle", 2, 0x0f4e, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ {"cmovg",  2, 0x0f4f, _, W|Modrm|ReverseRegRegmem, { WordReg|WordMem, WordReg, 0} },
+ 
+ {"fcmovb", 2, 0xdac0, _, ShortForm, { FloatReg, FloatAcc, 0} },
+ {"fcmove", 2, 0xdac8, _, ShortForm, { FloatReg, FloatAcc, 0} },
+ {"fcmovbe",2, 0xdad0, _, ShortForm, { FloatReg, FloatAcc, 0} },
+ {"fcmovu", 2, 0xdad8, _, ShortForm, { FloatReg, FloatAcc, 0} },
+ {"fcmovnb", 2, 0xdbc0, _, ShortForm, { FloatReg, FloatAcc, 0} },
+ {"fcmovne", 2, 0xdbc8, _, ShortForm, { FloatReg, FloatAcc, 0} },
+ {"fcmovnbe",2, 0xdbd0, _, ShortForm, { FloatReg, FloatAcc, 0} },
+ {"fcmovnu", 2, 0xdbd8, _, ShortForm, { FloatReg, FloatAcc, 0} },
+ 
+ {"fcomi",  2, 0xdbf0, _, ShortForm, { FloatReg, FloatAcc, 0} },
+ {"fucomi", 2, 0xdbe8, _, ShortForm, { FloatReg, FloatAcc, 0} },
+ {"fcomip", 2, 0xdff0, _, ShortForm, { FloatReg, FloatAcc, 0} },
+ {"fucomip",2, 0xdfe8, _, ShortForm, { FloatReg, FloatAcc, 0} },
+ 
  {"", 0, 0, 0, 0, { 0, 0, 0} }	/* sentinel */
  };
diff -rc2 gas-951221.orig/opcodes/ChangeLog gas-951221/opcodes/ChangeLog
*** gas-951221.orig/opcodes/ChangeLog	Thu Dec 21 04:32:55 1995
--- gas-951221/opcodes/ChangeLog	Thu Dec 28 13:35:25 1995
***************
*** 1,2 ****
--- 1,6 ----
+ Thu Dec 28 13:29:19 1995  John Hassey  <hassey@rtp.dg.com>
+ 
+ 	* i386-dis.c: Added Pentium Pro instructions.
+ 
  Tue Dec 19 22:56:35 1995  Michael Meissner  <meissner@tiktok.cygnus.com>
  
diff -rc2 gas-951221.orig/opcodes/i386-dis.c gas-951221/opcodes/i386-dis.c
*** gas-951221.orig/opcodes/i386-dis.c	Thu Oct  5 22:18:18 1995
--- gas-951221/opcodes/i386-dis.c	Thu Dec 28 13:36:27 1995
***************
*** 525,529 ****
    { "invd" },
    { "wbinvd" },
!   { "(bad)" },  { "(bad)" },  
    { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
    /* 10 */
--- 525,529 ----
    { "invd" },
    { "wbinvd" },
!   { "(bad)" },  { "ud2a" },  
    { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
    /* 10 */
***************
*** 547,551 ****
    { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
    /* 30 */
!   { "wrmsr" },  { "rdtsc" },  { "rdmsr" },  { "(bad)" },  
    { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
    /* 38 */
--- 547,551 ----
    { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
    /* 30 */
!   { "wrmsr" },  { "rdtsc" },  { "rdmsr" },  { "rdpmc" },  
    { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
    /* 38 */
***************
*** 553,561 ****
    { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
    /* 40 */
!   { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
!   { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
    /* 48 */
!   { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
!   { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
    /* 50 */
    { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
--- 553,561 ----
    { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
    /* 40 */
!   { "cmovo", Gv,Ev }, { "cmovno", Gv,Ev }, { "cmovb", Gv,Ev }, { "cmovae", Gv,Ev },
!   { "cmove", Gv,Ev }, { "cmovne", Gv,Ev }, { "cmovbe", Gv,Ev }, { "cmova", Gv,Ev },
    /* 48 */
!   { "cmovs", Gv,Ev }, { "cmovns", Gv,Ev }, { "cmovp", Gv,Ev }, { "cmovnp", Gv,Ev },
!   { "cmovl", Gv,Ev }, { "cmovge", Gv,Ev }, { "cmovle", Gv,Ev }, { "cmovg", Gv,Ev },  
    /* 50 */
    { "(bad)" },  { "(bad)" },  { "(bad)" },  { "(bad)" },  
***************
*** 640,645 ****
    { "movzwS", Gv, Ew },  
    /* b8 */
    { "(bad)" },
-   { "(bad)" },
    { GRP8 },
    { "btcS", Ev, Gv },  
--- 640,645 ----
    { "movzwS", Gv, Ew },  
    /* b8 */
+   { "ud2b" },
    { "(bad)" },
    { GRP8 },
    { "btcS", Ev, Gv },  
***************
*** 1271,1279 ****
    /* da */
    {
      { "(bad)" },
-     { "(bad)" },
-     { "(bad)" },
-     { "(bad)" },
-     { "(bad)" },
      { FGRPda_5 },
      { "(bad)" },
--- 1271,1279 ----
    /* da */
    {
+     { "fcmovb",	ST, STi },
+     { "fcmove",	ST, STi },
+     { "fcmovbe",ST, STi },
+     { "fcmovu",	ST, STi },
      { "(bad)" },
      { FGRPda_5 },
      { "(bad)" },
***************
*** 1282,1293 ****
    /* db */
    {
!     { "(bad)" },
!     { "(bad)" },
!     { "(bad)" },
!     { "(bad)" },
      { FGRPdb_4 },
      { "(bad)" },
-     { "(bad)" },
-     { "(bad)" },
    },
    /* dc */
--- 1282,1293 ----
    /* db */
    {
!     { "fcmovnb",ST, STi },
!     { "fcmovne",ST, STi },
!     { "fcmovnbe",ST, STi },
!     { "fcmovnu",ST, STi },
      { FGRPdb_4 },
+     { "fucomi",	ST, STi },
+     { "fcomi",	ST, STi },
      { "(bad)" },
    },
    /* dc */
***************
*** 1331,1336 ****
      { "(bad)" },
      { FGRPdf_4 },
!     { "(bad)" },
!     { "(bad)" },
      { "(bad)" },
    },
--- 1331,1336 ----
      { "(bad)" },
      { FGRPdf_4 },
!     { "fucomip",ST, STi },
!     { "fcomip", ST, STi },
      { "(bad)" },
    },