From raeburn@cygnus.com Wed Apr 27 10:29:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 27 Apr 1994 10:29:00 -0000 Subject: last night's snapshot bad Message-ID: <199404271729.NAA19654@cujo.cygnus.com> Due to some problems in making last night's snapshot, I've deleted it. If you've already updated, please back it out. Sorry. Tonight's generated diffs will be based on the previous snapshot. I think I've fixed the problem for the moment. From TRANLE@intellicorp.com Wed Apr 27 11:41:00 1994 From: TRANLE@intellicorp.com (Minh Tran-Le) Date: Wed, 27 Apr 1994 11:41:00 -0000 Subject: What is gasp ? Message-ID: <199404271816.AA20717@bridge2.NSD.3Com.COM> I have just noticed that there is an executable named `gasp.new' being built in the gas directory. What is it ? and where do I need to install it ? Thanks, Minh Tran-Le. ------- From raeburn@cygnus.com Wed Apr 27 21:15:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 27 Apr 1994 21:15:00 -0000 Subject: What is gasp ? References: <199404271816.AA20717.cygnus.gas-local@bridge2.NSD.3Com.COM> Message-ID: <199404280415.AAA21950@cujo.cygnus.com> Date: Wed, 27 Apr 94 11:14:36 PDT From: TRANLE@intellicorp.com (Minh Tran-Le) I have just noticed that there is an executable named `gasp.new' being built in the gas directory. What is it ? and where do I need to install it ? It's the GAS Preprocessor that Steve Chamberlain has been working on. It doesn't necessarily need to be installed anywhere, and is independent of the assembler itself. There's a texinfo file for it. Play with it, see what ya think... From mellon@ncd.com Thu Apr 28 11:07:00 1994 From: mellon@ncd.com (Ted Lemon) Date: Thu, 28 Apr 1994 11:07:00 -0000 Subject: Feedback on ld circular reference resolution code? Message-ID: <199404281807.LAA01708@pepper.ncd.com> I sent in a patch a few weeks ago which adds an option to ld which allows a library to be searched more than once, so that when object modules in two libraries refer to each other, those references can be correctly resolved. I haven't seen this code appear in the tree, and I haven't gotten back any kind of flame indicating why it might not be worth adding as it stands. I would appreciate it if one of these two things could occur. If the code isn't good enough for some reason, perhaps I can modify it so that it is good enough. If it's just that nobody's had time to look at it, I'd at least like to know that that's what's happening, and maybe how I can help to make integrating the change easier. Thanks in advance. _MelloN_ From ian@cygnus.com Thu Apr 28 11:35:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Thu, 28 Apr 1994 11:35:00 -0000 Subject: Feedback on ld circular reference resolution code? References: <199404281807.LAA01708@pepper.ncd.com> Message-ID: <9404281835.AA20647@tweedledumb.cygnus.com> Date: Thu, 28 Apr 94 11:07:26 PDT From: Ted Lemon I sent in a patch a few weeks ago which adds an option to ld which allows a library to be searched more than once, so that when object modules in two libraries refer to each other, those references can be correctly resolved. Well, firstly, I haven't really had time to look at it. Secondly, though, I don't really understand why it is needed. My first inclination when seeing a new feature is to say ``no.'' The GNU stuff is already, IMHO, much too large and complex. Adding features makes it worse. It seems to me that you can just write the library name twice on the link line and get the same effect. Why is it worth adding such an option to the linker? How many people will ever actually use a feature which is not necessary and is only available in the GNU linker? When discussing a new feature, I don't think it's enough to say ``here it is;'' it has to be a major lack to not have it. Despite these arguments, the FSF requires a new linker feature for Hurd support which is somewhat similar to yours. They need to have some way to search a set of libraries as though they were a single library. It seems to me that that would solve your problem as well. If you have good patches for that, I would certainly put them in. In fact, since this feature must get implemented, it seems to make your proposed patch even less necessary. Ian From raeburn@cygnus.com Thu Apr 28 11:39:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Thu, 28 Apr 1994 11:39:00 -0000 Subject: if anyone's interested... Message-ID: <199404281839.OAA23125@cujo.cygnus.com> The regular gas docs are there too, of course. I don't think this gets automatically updated, but the stuff there now is fairly recent. ------- Start of forwarded message ------- From: crash@cygnus.com (Jason Molenda) Date: Wed, 27 Apr 1994 23:17:03 -0700 To: raeburn@cygnus.com Subject: Re: What is gasp ? In cygnus.gas-local you write: >It's the GAS Preprocessor that Steve Chamberlain has been working on. >It doesn't necessarily need to be installed anywhere, and is >independent of the assembler itself. >There's a texinfo file for it. Play with it, see what ya think... A perfect opportunity for a shameless plug :) -- our WWW server has all our docs on it; http://www.cygnus.com/doc/as/gasp_toc.html . ------- End of forwarded message ------- From rms@gnu.ai.mit.edu Thu Apr 28 12:06:00 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) Date: Thu, 28 Apr 1994 12:06:00 -0000 Subject: Feedback on ld circular reference resolution code? References: <9404281835.AA20647@tweedledumb.cygnus.com> Message-ID: <9404281906.AA28860@mole.gnu.ai.mit.edu> It seems to me that you can just write the library name twice on the link line and get the same effect. You don't know whether twice is enough. It depends what is in the two libraries. Maybe -la -lb -la -lb -la will work, for the current version of the libraries. Maybe for the next version of the libraries that won't be enough, and you will have to change it to -la -lb -la -lb -la -lb -la -lb. From ian@cygnus.com Thu Apr 28 12:08:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Thu, 28 Apr 1994 12:08:00 -0000 Subject: Feedback on ld circular reference resolution code? References: <9404281906.AA28860@mole.gnu.ai.mit.edu> Message-ID: <9404281908.AA22838@tweedledumb.cygnus.com> Date: Thu, 28 Apr 94 15:06:31 -0400 From: rms@gnu.ai.mit.edu (Richard Stallman) It seems to me that you can just write the library name twice on the link line and get the same effect. You don't know whether twice is enough. It depends what is in the two libraries. Maybe -la -lb -la -lb -la will work, for the current version of the libraries. Maybe for the next version of the libraries that won't be enough, and you will have to change it to -la -lb -la -lb -la -lb -la -lb. I believe you are discussing the feature you have requested, which is different from the feature that Ted implemented. His implementation appears to have the effect of repeating the library name at the end of the link line, and no more. Maybe I misread it. Ian From mellon@ncd.com Thu Apr 28 12:15:00 1994 From: mellon@ncd.com (Ted Lemon) Date: Thu, 28 Apr 1994 12:15:00 -0000 Subject: Feedback on ld circular reference resolution code? References: <9404281908.AA22838@tweedledumb.cygnus.com> Message-ID: <199404281914.MAA02386@pepper.ncd.com> > I believe you are discussing the feature you have requested, which is > different from the feature that Ted implemented. His implementation > appears to have the effect of repeating the library name at the end of > the link line, and no more. Maybe I misread it. The feature operates as RMS described it, not as you are assuming it operates. Why would I go through all that effort to implement something that could be done with a trivial command-line hack? _MelloN_ From ian@cygnus.com Thu Apr 28 12:24:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Thu, 28 Apr 1994 12:24:00 -0000 Subject: Feedback on ld circular reference resolution code? References: <199404281914.MAA02386@pepper.ncd.com> Message-ID: <9404281924.AA23494@tweedledumb.cygnus.com> Date: Thu, 28 Apr 94 12:14:45 PDT From: Ted Lemon The feature operates as RMS described it, not as you are assuming it operates. Why would I go through all that effort to implement something that could be done with a trivial command-line hack? I apologize. I must have misunderstood what the code was doing. Let me back up, then. I would still prefer to see a feature more like what the FSF is requesting. One that would essentially treat a set of libraries as a single library. One problem with my revised understanding of your patches (and please correct me if I am wrong) is that the libraries are researched after all the input files have been seen. This will not work if there are any object files which come at the very end of the link, which is generally the case for COFF and ELF. For example, gcc on COFF or ELF requires that the crtend.o file be linked last, after all everything else (except a possible crtn.o) has been linked. Do your patches accomodate that? Also, adding new fields to the BFD structure itself must be avoided if at all possible. I am constantly being beaten up about BFD memory usage, and doing a link on a large archive can open hundreds of BFD's. Each new four byte field in a BFD structure can lose a noticeable amount of memory. Ian From rms@gnu.ai.mit.edu Thu Apr 28 12:29:00 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) Date: Thu, 28 Apr 1994 12:29:00 -0000 Subject: Feedback on ld circular reference resolution code? References: <9404281908.AA22838@tweedledumb.cygnus.com> Message-ID: <9404281929.AA28951@mole.gnu.ai.mit.edu> I believe you are discussing the feature you have requested, which is different from the feature that Ted implemented. I haven't see his code. I saw only his textual description, which made it sound like the same feature we asked for. From rms@gnu.ai.mit.edu Thu Apr 28 12:42:00 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) Date: Thu, 28 Apr 1994 12:42:00 -0000 Subject: Feedback on ld circular reference resolution code? References: <9404281924.AA23494@tweedledumb.cygnus.com> Message-ID: <9404281942.AA29017@mole.gnu.ai.mit.edu> I would still prefer to see a feature more like what the FSF is requesting. One that would essentially treat a set of libraries as a single library. We should have both interfaces for requesting this feature. One is with a virtually merged library, and the other is with command line options. One problem with my revised understanding of your patches (and please correct me if I am wrong) is that the libraries are researched after all the input files have been seen. This will not work if there are any object files which come at the very end of the link, which is generally the case for COFF and ELF. Indeed, this feature should not be limited to coming at the end of the link. You should be able to specify a group of jointly searched libraries at any point. From robertl@arnet.com Thu Apr 28 14:04:00 1994 From: robertl@arnet.com (Robert Lipe) Date: Thu, 28 Apr 1994 14:04:00 -0000 Subject: if anyone's interested... References: <199404281839.OAA23125@cujo.cygnus.com> Message-ID: <9404281554.aa08193@caddy.arnet.com> > A perfect opportunity for a shameless plug :) -- our WWW server has all > our docs on it; http://www.cygnus.com/doc/as/gasp_toc.html . > > The regular gas docs are there too, of course. I don't think this > gets automatically updated, but the stuff there now is fairly recent. Well, at the risk of offending the EMACS users on this list (yeah, yeah, I'm the only one that isn't) this is enough to make me go look for texi2html (mentioned on Cygnus' home page) and use it as a way of having on-line hypertext-ish help without groping around with info (which always frustrates me enough to just read the *.texi or *.info* directly.) Thanx, guys! I didn't know that was out there. -- Robert Lipe, Sr. Software Engr, Arnet Corp. robertl@arnet.com From mellon@ncd.com Thu Apr 28 23:13:00 1994 From: mellon@ncd.com (Ted Lemon) Date: Thu, 28 Apr 1994 23:13:00 -0000 Subject: Feedback on ld circular reference resolution code? References: <9404281924.AA23494@tweedledumb.cygnus.com> Message-ID: <199404290613.XAA19700@pepper.ncd.com> > I would still prefer to see a feature more like what the FSF is > requesting. One that would essentially treat a set of libraries as a > single library. Sounds fine to me. I haven't seen the request from the FSF, though. Could I? > One problem with my revised understanding of your patches (and please > correct me if I am wrong) is that the libraries are researched after > all the input files have been seen. That's correct. > For example, gcc on COFF or ELF requires that the crtend.o file be > linked last, after all everything else (except a possible crtn.o) > has been linked. Do your patches accomodate that? Nope. I hadn't thought of that. However, from what I've heard, if I were to update my patches to do what rms is asking for, this would satisfy your objection. Although I do use ELF, I haven't had to use crtend.o, so I wasn't aware that it was an issue. > Also, adding new fields to the BFD structure itself must be avoided if > at all possible. I am constantly being beaten up about BFD memory > usage, and doing a link on a large archive can open hundreds of BFD's. > Each new four byte field in a BFD structure can lose a noticeable > amount of memory. Well, if we use your description (hundreds of BFDs), this would mean at a maximum that we'd be using an additional 8k, since if you meant over 2000 BFDs, you probably would have said ``thousands.'' I don't mean to belittle the importance of conserving memory, but I have to admit that I'm having trouble getting worked up about this. Certainly it would be bad to add fields that serve no purpose, but I think this is a weak argument against adding the feature we're talking about. In any case, if I can get a description of exactly what the FSF wants, I'll be happy to modify my patch to provide a solution. I could probably make a guess from what's been alluded to in previous messages, but I'd rather get it right the first time. _MelloN_ From raeburn@cygnus.com Mon May 2 10:42:00 1994 From: raeburn@cygnus.com (raeburn@cygnus.com) Date: Mon, 02 May 1994 10:42:00 -0000 Subject: gas-940429: missing opcodes/disassemble.c ... References: <199405021450.HAA29455@cygnus.com> Message-ID: <199405021718.NAA02720@cujo.cygnus.com> Date: Mon, 2 May 94 07:49:06 PDT From: Minh Tran-Le The file `opcodes/disassemble.c' seems to be missing from the gas-940429 snapshot. Here is the error I got when trying to build it: ... make[1]: Entering directory `/gnu/src/gas-940429/opcodes' gcc -c -O2 -DFASCIST_FDOPEN -DAIX386_CORE -I. -I/minh/gnu/src/gas-940429/opcodes -I../bfd -I/minh/gnu/src/gas-940429/opcodes/../include -I/minh/gnu/src/gas-940429/opcodes/../bfd /minh/gnu/src/gas-940429/opcodes/i386-dis.c gcc -c -O2 -DFASCIST_FDOPEN -DAIX386_CORE -I. -I/minh/gnu/src/gas-940429/opcodes -I../bfd -I/minh/gnu/src/gas-940429/opcodes/../include -I/minh/gnu/src/gas-940429/opcodes/../bfd /minh/gnu/src/gas-940429/opcodes/dis-buf.c make[1]: *** No rule to make target `disassemble.c'. Stop. make[1]: Leaving directory `/gnu/src/gas-940429/opcodes' make: *** [all-opcodes] Error 1 Yup. I forgot to tweak some config files to ensure that that file would be kept in the distribution. I fixed it the next day, but someone deleted our copies of gzip and GNU tar, so the snapshots aren't getting made. I'll try to work around this today, so tonight a normal snapshot should show up, including disassemble.c. For now, just remove it from the makefile; nothing calls it yet. From raeburn@cygnus.com Mon May 2 13:19:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Mon, 02 May 1994 13:19:00 -0000 Subject: release time Message-ID: <199405022019.QAA02994@cujo.cygnus.com> Because of Cygnus' schedule, it would be very convenient for me to make a net release in a week or so. And it's been more than long enough since the last one; several new features have been added that should be made available. I think the snapshot mechanism is going to work tonight, but I'm running it now myself just to make sure. So there ought to be a snapshot there later this afternoon or evening. (The tar file is prepared for installation, and diffs are being generated as I type this.) It's still going to be missing some big stuff: the file renaming DJ pointed out was needed, and some MIPS patches from Ralph. Those will go in this week. There's some smaller stuff too; I'll go back over my mail. Please try out the snapshots and let me know of any other serious problems. If you know of significant changes made to any of the programs since the last release that aren't documented in the appropriate NEWS files, especially if you made the change yourself, please add a note about it, or send something to me for inclusion. If you can debug some problems on VMS, please let me know. I'm told that sometimes the first useful symbol in a file gets confused with "gcc_compiled." by the debugger; I'm not sure what's needed to fix this. Ken From raeburn@cygnus.com Wed May 11 00:33:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 11 May 1994 00:33:00 -0000 Subject: branch made for gas, binutils releases Message-ID: <199405110733.DAA14299@cujo.cygnus.com> I've made a branch in the Cygnus source tree for the code to be released shortly. Thus new development work will stop showing up for a little while. I'd like to do mostly cleanup work at this point, for the next few days or so. (DJ, I still would like to get your changes into this release, if you can get them to me quickly and they're reasonably straightforward.) People working in the Cygnus source tree itself: Look for branch tag `gas23-binutils24-branch'; that's the branch to check things in on if they need to go into the net release. See also tag `gas23-binutils24-branch-point'. I do still have a few items on my queue to do in this branch before it goes out: + Some of the renaming for DOS (8.3) compatibility is still left, but I think only a couple cases remain -- linker test code, and c++filt. The rest should be done now. + The Sparc Solaris assembler should ignore `-q'; using that option makes the native assembler much faster, so it'd be nice not to complain. + The new i960-coff code needs more testing. + And I've got a few test cases to check in that I've been keeping in my own private copy of the sources. Please test this assembler and binutils out, and let me know if any serious problems remain. Otherwise, it'll go out largely as it'll be in tonight's snapshot. Ken From dj@ctron.com Wed May 11 06:22:00 1994 From: dj@ctron.com (DJ Delorie) Date: Wed, 11 May 1994 06:22:00 -0000 Subject: branch made for gas, binutils releases References: <199405110733.DAA14299@cujo.cygnus.com> Message-ID: <9405111324.AA17632@delorie> > so. (DJ, I still would like to get your changes into this release, if you > can get them to me quickly and they're reasonably straightforward.) I've got it all done but ld and gprof. It's mostly straightforward so far. I expect to be able to finish tonight and get diffs to you tomorrow morning. Most of the changes are in configure.bat, a few Makefile.dos's, and some go32-specific files. Also one new entry to bfd/targets.c. > + Some of the renaming for DOS (8.3) compatibility is still left, but > I think only a couple cases remain -- linker test code, and > c++filt. The rest should be done now. I only saw cdtest-foo.cc cs cdtest-func.cc, which happens in two places. The rest of the files came off OK. From dj@ctron.com Wed May 11 20:05:00 1994 From: dj@ctron.com (DJ Delorie) Date: Wed, 11 May 1994 20:05:00 -0000 Subject: patches for djgpp compatibility Message-ID: <9405120307.AA25344@delorie> ld was tricky. I ended up changing genscripts.sh a little, and generic.em a little more. Both changes should be unix-compatible, but some of the shell constructs were just too complex for dos. When will they be replaced by a C generator program? The rest of the programs are mostly configure.bat (and makefile.dos where needed) changes, with a few minor code changes here and there (all conditional on dos, of course). All new emulations for go32 (and BFD descriptions too) to match the specific COFF variant that djgpp 1.11 uses (underscores, ctor/dtor sections, no stabs, 4k data start alignment). Extract this in an empty directory. The file names may not match due to the dos 8.3 restrictions. The files in the "diffs" directory are the diff -c3 outputs, but named after the files they are diffs of. Files with a zero-length "orig" are new, so please make sure they get distributed in the snapshots and official distributions. Please refer to the file changelog.new for more comments and the changelog entries. Please let me know when these will show up in a snapshot and I'll retest them all. DJ -- begin 644 tocyg.tar.z M'XL(`,J6T2T"`^P\:U/;R);Y:E7E/_0RM3?890SF.2'<;!PP";,\4IC<;#:3 MTFU+;4N#K-:J98PGE?^^YYQNR9(L\TC(9+[3Y_W2$8['PZ$(Y+`5 MBLF3'_.SL[:VO;G)GC#\62O]9FQC8VN;L:VM[.C2EQ&/+X7+)G[BL4]PYS/S0Y9XXJGE MI`K$1)C$OE`MQGI^Z`AV]&S$0IFP`1_Y@<]CO=N3$Y9(-A0)[/?#H7IJ^2%< M`&#,]16`Z(\37X9-%@6"*SSZ4C`U!B1@O6(>CR(1XBD7T]^`W_75G!?S\`C2=\RMIMMKZ^N[&^ MN[;&VL^?@TH>_,8.X`"`S9;=/UXY22S#EB-'==SV*?#[?E_$R?3S4ZO6()21 MD2U7`E\UOT[,-<`L9G!]=2@WUFFU(\.!/P0"6WV>[+)QY/)$+PO@@TJT3#1@ M!3M;SBZ+Q4A>"2.R<>@@QQ1P>X)R`6R<%B?$^@/W\[T/*6"?6^G(.!8.R(W' M(#Y%RJ'D.';,1D<.!BM(%F*HJ<9OSQ3;/SL\1!`CGK!E?^/7;5RJ]6$<@B`4 M@!:J3E`,=(3!79<@T&I]O8BA'^I%N9-!5:)(Q@F1+R-'ND+=Q`)0/<.!'%3: M/.3?LC%;OYH(C9)78H8(KWS0GA&HJI:1'X+&!^J.@BJC&;C?AJ48C8.(QYP4 ML:4`2X4V*6?,).OEQDVFZ5)\`(E1/[4=)DBCP$KI9A`/9YQ?V`]\$Z]#(@EW8>G/68P\-G M"9A]Z,)ML#AP"]=,3<.$7[>*B*'S"(?^8-I2PMTEGBW!)[8R6`*S4`G8/*`$ M'P,_%*UY37(%>!98$K("),85FR!6\!MHUR0HX!A!T%\U8XRJMA3H;FHL9.Y_ M#*.(M5OM=M$6"$`!Y"Y0$R53=L5C'_E!KACIY\&$3Q4*6?E@,(`5D)8L-8E- M2FK9>6*$`ER:9O2VM"9'L1Q4:HE6S/[8#]R,%VP0RU&>,^#QI#%.#YSW[QWVR9O!/$#>$JYB=Z`QT]VZ"-&)%4(D#V+,5+#.44]Y>( M50,),BCN](`=FV\-P;*,"`%;@>*:CO@RTXT&/@F;F#D"P[/#L7??4/G]- MK$CAHM]\:CW&^_(/1+3AZ@\^@VVN[6QM+ MQ?/7R!\BW24< M3T)5-+#\`5OZ]_82^_O?V1)6,DM0KT(&[?T*0BG<]'Y=A4N%VP2D%PD'2B:H MG[#R8Y^HWF5Z-?N,914D[R-L&F#]9=%V<>TGEK6+*S60?:-X4'ZQK*M"&3RM M<60TS5HIZ)RR+P5X.:P6`WQ+F-T$TMHE>/^*_E\WFAZL_WNC_6^TMU/[;V]L MK8/]M]LY$:?OK,P+1/);L"T[C,-616&._+.`'S^3U<>F'1 M[>6Z]<5B;!+[B5AN-W$_MG3^%'*P#)_K]1?65\M2_E")9,15NGZUP4(H_*&> MYX%*^W38L"1'L3P529TU5G'K4"1CWS7;X+\8OL>JS`U5:Z(6MYWIH7I.?F$D$[Z_5XG_;_,%N?M_T%+__O6 M_^V=G6VT__;FSJ/]_RS_KQ__/53V?R_Y;^S@+$A[;7/CT?__)/EGS]^?/*#\ M;XC_VVO;V^U4_INH*"#_[?;C_,]?\@,UV1O]/-\\FUU!W[^23".156@8&_%1 M_>O#`VRAQ#R>MJ#T@A@:34%]O`1G9-::[#F4@L_7X?^-IIZ:.8R%8#TY2"8X M0W0HQZ'+]6S/4>@0B`]00B8B9/TIVY\.P[%B/7UHR[(N<&R`'DC#[X@#(I!5 M``Y-C8P?`A[L$.\?"/T$'8_;^@G5. M/[(/G?/SSNG%QQJ!3K7('`]OFH'_ON$#Z>=-C:>GOC M>9.][W6`W,:J9?WBATXP=@5;`G?;\I9R%](T,W\---JLLU8;5J^[?W%T=LJL MVH7VTY9UT.WMGQ^]P\M6K06U>^B[LU?V(I$ZN6LU'4/YZ; M!(*B$F078K8=23\$Q:6]V>B:59MX/F(N8AR-88Z(<3W#F9$`U"X`S0>H"6P8#AW*%5L\S7X0C*NDPY-X>",?&*_'+ETTP*Y7.N8$C`=PT M*]'FQ^%E*"F:*80:X!\"[PAJ8%\6PX@E`R4B`&2W:$ MBA>.4=$*\"9G+]L&N@")I6"TT:->XU&:7XXGG$M; M*R:LQ*%`*:.921C[3E,_J_;J.A:#+[A57_L*ODM?.R0@ZFN+&'2&L6OB8YCR M0Q71="C*(!#(?[6`-.P0]*E1T`2S`%Z"[`$HV#^8MED;XI@NAFUTMBU&)DB? M0=Q(F)\8&64HI+U@0B".02::>/IL^^$5#_R"VS M0)`CR#@/P<;+*&84DD9%I0)!T&?IQ",*R`/I]@7`,[XD-8Y4@V@X3KC-[#RK M9MS*B$\Q:&=>PD5?`'S"@&_X:BP]1:XD?#E3$S)B<-/CX1!CE8%2:/@`].8KMZUD]@7(6<`P*U'(;^G\97*VH9 M^;.3%^"M5^C8 MZ0Z&88RFUM'IV4'7JLV6-1EK,A-:LP_6P=G^P8'5>__:A-_\CE(`)F',!3Z% MN5,\I8EWG8`A_S$@*'R^`KD53SUIBQWA0Q&*_LK,R$-:>RDHN/2GX--E#"EI MDTQ$JQL%3ZN6!BV:XB6CAG`BLS@SBQ=@S6@\7<1IYHR53A9F7LS00&J"A^_M M78,)OWQIU49BU#>^&R,19!6Q1,7`>$W!3FG)0PX:D6'G@WWF=RA^:(%G9JE] M1,O,[:>@_)#"`QZ*&88Y;S".T?BMF@N!%=>\0E/Y0NG2U]G+"SQ04H.9I#$- MQ6#8DF,;V`[.&:,K@WB3F0EFN^3/B'GZG0+V"K9_`:0AS4^^@K>.AV,*.:,Q MN'4PT`@'=P$"/A9S7Z#N9ZJ0NMMT#Z!@T@_29C?C5,K?J7X)@EZ1D,XX0X4M M8UY]=N!*\5NL7,'[,%X$/=J][>K`,S&V"$2G%,;\U#*BSWZT6*_XL+S>6 M<75]Y25JSSW99+3C`'\`1[*#[^OT;.ST%+F/9-6"Y"_=!9%F?S/[V M-Y9#H?1UAA'[CQ3_.R#-=K/%J+B0]4.NRI9M^_#HN&O;3=L^/CJ%#_4FP_2@ M#E3^`HX'A&'5('CFLS:=\T(N(Z[S;EF[O=T*[MN')Q=WE,!R)1V?EL'.Z^DM M?5#]\[=(!%'Y!@2_53+?1DXFJ_N+*@VJQ3<:M,0TT28_PV"7UEIZC_80Z-FT MNV3:6Z95J8:F$PU,VQ*(]H/4`X,[@^R>81D'7E:ZXR`MV%,G!);K.$!^N;(S M;ENW*[!-`F[1X&F>R*`W$F#4H(='_W72;>H+%$946DZ#Y]+:"]$]<>/-8.$M M7PBQZ%X8C!;=DAP*_44W$W'IB>M%=Q5D4`OOR<4GJN>7Z;VO+]#*OS08>*,) MCUT0A1/P.`UNC:]6"Y4:C=VH*@*"D'D)2?1`,KOPE8!5K#?)4>L+)%DNJ`NF M>=IB+OV0WL-)$R[1&K::K#<.SWJ;3?8^@+3Q&JXF#L8?QFA"I8'J]P)[7((M M&3J6&'4KLI*=6@Y#T^Z!,TP3P.17%%XA`E.\I8U42-,1<(QQ>"L!+$O)431D';0=KOO#^WH5H#ZO43J=JI%,/4:>QYTA^&P M#6TS&0;0,4SM$W:*:^&,$RJ(L8P@J\1R7IF'QYWWO2PG-G; M>]OIV>?=X[-]_-IJM?;V#NQWG3?=`ZJ9`#,\9@*X,-G_`](WFXY]80+1K7C! MF93ME'"BUY"L&4Z0>MM%O/!*YSB/5Z][89]V_]$]MX_/.O/HF8,,?EH6J%[< MP790B.$C"*:ZS(323Z,:@])H4>A7CIBU#+4,#Z<0-2"4>SQ2[)_VLYRRZG4V M",N%/-/&:^:P")SB[$!ZWPEK2>U;C1J`G'CL>/Y5]I;J##*/;0"A(>:#O88^ MXM?^"#1YEB=G9U$EO@#R.,21+'RERL.^(9P!@&S$*1"A01PJ30(-46&H6RNQ MP#:'%AP2@AUIP]\26(@1>I\=R0FH*\`"J-WL1=U8%S5JPJ,(\W)Z70L,BVH` M;*=CZS<+SMDN:>;>L?=-H)&CF+<,8 MW[/#8.C*[(UA8X+@(ZY&W&18#?P*+NQZ>[..W>W.20_R%'Q%3[M`(JN!TW!F MJV8(09AM3J_>!N]L6]O M/P#V=P&R`/O"U@786Z_G%'SF[-4BS?*^3[>\A]`N[SOUR_L^#?,>0L>\[]0R M[_OTS'L(3?/NKFNZ06M>9B9/;=H;NR;?1W^JNRR48N0]J)5+10H]VUD)U*1J M`E68FG^F*XD-)VS9@9O:@/9GXM\,ISII4]0JO&:Z&?1+<8*Z5:A MJ-;G0D)R]U,_T(-$!YA%L5#OPZA)?_:B"H,FYAZF#QI()2"/N14E>EQIIPGN M'=#"J)XFRP518Z3#P[[,)@/R*F(JA'SA_]O[DW?V1>,J!M*]G5C+6L;FT>4FNV$FFN:I9C'A`(+;!PO,+@:HLL2`-[/DU7! M;(U#1UWF'M#H>01,B.=58^XX(^0Y_BP\*T\OIT=N:9(-5-/C7GQPL(BH.4:7 MSFDB-#M*XMF!Y_C'%?(UEDF934:X\"@3B><%M^C()GMW<=YD<^W&&W_0QO1F M[:+_%&0=A+XAH)OO:-!?P8C@:^Q?X4-4G8[>I/C[9^\^5F@]V3!`L@TDNH#0 M*K2_L"[E!ZTM"C5%#O4HM>`\HCI%IIX/E6/Z^9'F%WJ!^0"6C'I0N*G5W@7+NFLFSL+62BQOT+?4G9I2]N[L[YSOOSWZ1Y4$5#".(YN#^RV')7U'7">8 M3+E4%=N$8VD=)"FA@PK)8UQ3NJNCM`,#O50" M@03?[O(+#0?L70P3[U;+-]FEC`/6@).;]SH$=H$>C\/D=N1P.39,W.M9K4`6 M2'Q;=HB8:5Z62J(J"],@4,WWSMW9NMJ[>QY/7 M9\>]"NNB^#X=@4[9XRC"AB4VV*JR-UI4NH&//FWZJTBVQJ-T'R)!F%3?,C"Q M&5>13B*C?&4'TN&!'?"^J-J.KZJ$Y9TT?A0*CCTP6E$!F=!V17\\3'%#%M/4 M82'OF>=+M=45=CH0*$,?\,9,QG"M+.5[QKQ4)S2[*,FTM6MMI"@L7L(:\Z<9 M5.?%=XM7R6\NR'9.C3$1O"N5-Y!W9QAEC&8Y9&H2Y17+_6;45$VPX]ECZR:; M(ZW)LH7UA;PH*_.WROLA.)'#PP@PSX$2ID1;%0M*ZPP7#`_*:6G)4N>4@9ON M_"Q'X`%V/QJ&A3EC7N@/*UA2CE.9..9]0-E7XV/P:H:FYPF'-4P">R,2#>.` M%X!+>U9R,*"IK'R\;6`8*5^">+T`5"&\-8@L8@"$AM?$TTYZ?NZ4Z0,^?D@M,(X@^=.)E`W3IO$-^/$H$"A^![X]C;/@'4QV'^E,] MHZ*4&$%N$J>@<*"'QI=AI_[3>GHT6%<0F584_5'!+\_DEO&D0H!DDXU",9$Q MBWPS5I7Y_/0\G2I"\F(!RGM+`*5';(OB)P&X(7P6(@(MKHA)&@CUA7!B=AP5 M8U+U.;?4_HOCDL9B<1T/2J,M]+ZQZ@ZA"OB/;Q84IZ5DJ.5`,QN9BAC;,$`U M_9Z<)-(VEV:Q;;DQS\&[6WVEW6J`^%=*X2/7(87AUTI5F@VQ8;:,*@\^*5=) MWZQ@'\Z/+BJK'V&217PYH%S_+&JJS7O$(I@YN6O'-4E([Q4S@?D34R%LCC^.CT/ZO$07](PS9/ARK,.+-3[.+-DU]I M]_PZ75AQGX8Y/*X\7??9VG4O6LA=U[C.JK.`4`S2L+"^H#8IDC=?Z&LYYQZI MZ(<;_\O>F[+R86I2JV M6$G`I+.FQLJ,C9>1P^LG@[K2Z.%@SA$!IO*P]#46G\FI@@P*%C?LN6YKQ;_P M._W839>W"(T0^!'`O1E@*J!/*KZ9E44"]'08-K+@5V5-\35 M97#H[X'],+>N^WZOTS1#RC8/\V61#C%T2_A[<^I(D>]$)8M&AEUAGR!+7#+C^%)`:I)%,S<0.X!/HK422`7(%XNN:6%!ZW]'J*ET8=Y:V30B)&N*_H6GF:1A!Z2* M!)*,YK3T]@%-?G+>R+<\LG$IKY#M)NG,*E1&CE1.C'C#2!2+65%*_&HC&\(W MR>@Z&@6]*$]&VCO=01L.W2.T9)"7_PCGESAZ,Z`RQEP#]:[)$!>84XA639U> MP(8AHIZ%I8UB,)D`]CI7"J^?A_UEYB2=/@BW-#'#B(UF.=M5`O"KC]Z3UBYJ M/T+/MM+*-%`?V&^%9\'4(EBBUQE$,^&80MW.:-2="6QU)J`!AJ4@M*>4.".4 M(9/`H!>:V:4$H:D%T?ZM>[Y6)7#Z%6%:VVYAZN[<@NW!P)]?"OVS+U#JX>;J M_%+2X86[PN47ZTUO\^'[!4H]7*04Z3H.%D`P&L"!:$ZQS?4;S!\47FR06L"H M&U!Z2G8P;WEQ@=E+@LKXR$#F%"3?3+-61OOAQIP"L`;8`F!:@0$T<1:U9N:W M!^.K:050P7Y*%I+XK+8Q?T;3F`U[4.=J5@%2XI^2WP]&`'[&.M-15V;E@_@W MGHE!][I_U9C732HTKRF\(UB;6F`>Y746H#RRS9B2APM]%H8Z?]R?56+N:)A" M,]L"=G+6C*9/[&441E.'JM_MS6&P7&(FE^$BO$JG%&&3E2F9PVAS=?;:C-HS M6(&8Y MN\#`1[8WJTQGV)D-)(S.9^;/PW(T]&=C,(`2S<`IXKG:IHX9%6M(DJ_YD? MX@D%3VP2,P"&K!)1Q&:">B*#Y"MF%> M"WA_UAKW!CBO%ZTSQX:4;NO(\:;/KFR$GEAA#D^@,,Z7@9"+\0I!9;2+(KQG MUT,]]1Q32&9J23^>H<\I\52];292Y1P23YT4J=/RTUO7YXI$ZL.T5+-1QY.= MXT1!,XYGS_*[Q`EO"I`3V$7Z"Z"7(6@ M7Y>+3E-,T@J&#MQ4N0`1>[NSX*+3)T=1LJGQ`S8[2$%O#0"A1T[GHL&8'#AT MK[7S&%H?:%Y*VL?.]N<.&'38.?@4L%]'&(/.1!8#RL3E1_CC#4R1GW?%&1Y" MTXL\2+*3Y(E(^(G.29Z#''X1._X4*&'#31`X@"P'U_1+:-3*T3J[:`$+')S] M>]F!!1[1#X$O7K-7"%ECO!W0S9.VQ+7`<-XLU<1.5`99ET7N=GW@XFR[&)>L M-":A`>:O7.R]?O_DIK_[\,R7KVE)RC MD^=Y3S][_"!G-Z=E]\A6D&^#7^:'V(E*YW_C"8D=TA)=B) M2E M.%VAPNS=87Q.64-TZU!0%Z'R\:VS5.)M&"2A#\'3)CF[Q`"RE/@6-O3`,5\= MDO^D?ACGDV1FR^JA48&+46UT8XE[;K\?7I-_(3E8=J*BZ%9K^C&G.(=VXH(341_$C@Y=6,MHZ',481X[61488*M%\V]?,N`@T6'G&$7< M]-A7JA@-&^^.1)([^S\AX:+&/PY#_+#E$B861O:FB\:.5),%B>'9LO'35;+X M_O&^@1L[924+`JO4Y=S#5J)8YO1XQ[0=.U29@KKD:RBZ6]=E$^W2RH5C30XH$PB=<,D)A'V3Z!+;ZJ^-9BQVHTB-4JS5$UR@B.D@E$9D+ MN!ETSNWZ(O]S8FSH9L#BE\E,'@,36/`Y\*;'..RS[MI;,4ACA-!`OP>+94Q> M(7'ILMJ):^>HS2748$Q.+>D]13MG$=EJU&Q;/F!-_X?^-;FFZ436,:)XN!'7 M`03+>`_0L;3IU,`.JP"$V,:+U[=KBO?*PR6*5*0CPQJ>L6-S0\/;UK%B)HKD MRY(S>>C.TX!YS]\<.A[8'#^0GG?R\^'1ZY/]$]Q>K_V(=#8E4]Q<9F514!S?*!B-M)-1!TDO8[#$H+RF!KD@9D>5,S'P,L09 MZ%%4G`%B#_!0D$TZ*!G6C2#:I_:BV9XQPP\PK>*M1#OF$_=I MXJDQ[,O[J5Z/YG@;LW)67I*/>`F*5+D8&1(%LM@ZA52WO+B.ZA8%0G*;6-&/ MP$K>504(I,&DJ%P>'F=@P;]7?E?M64!U*_4K$UE%<::M:07Y8LC"G@ MDW:C%?GGP1:-D2R6)HHK='E!U`FC1,PY9U'9)J=<*-M_#Z36[`UL9L'24#ZO M/M*`X%`4GR2I`7J$+B-YS,1!*) MQ@S2?T@%IZ=/?<]]VI)AO7]?(X\]3^EE3BKFBT_(M$J?9](ZXDPZX:[5(]D5 M:FZ:)U2B!8%'N&$ARVIA>>:)<#E6FIS/3<]BIVW1VQR=Q&%5L MO35&U#W@&4XIL:V:/TTZ$J!=L32U^:U&IBG@<>V^WU4JL#A'#UDN@JR2B M&&HLTDT<&9!MJ]4MO<,?[ISN_U@W!U*0;EZ]WC^H'VM*Q\9&:)(H5PE#K=3U M\O4C$+'+#U97Y5($5>*UUS1B1IV1IVU@B?\$*%)&>+7!&NX$D!FK.,77W,S' M48[('2XOH@]A%[#H!EK>T(J**"FKHY^ MV&`%IGR,9_#2D*5U&^.QDM,#@%Q@.[G4J0?2MND$KLVO%_^GT_\Z\3\J%/.5 MXW]L;#Y8I_@_JW?Q7[[*GWLX!3J$E4)GU^A)GRA^K+PH/<4S<*$$*=_O(@(??4EX0)N:<^.U"(YT7#9JN# M>R/\'@P#]-J\K>\,/5\.*(`9#U,R'F+&HY2,1QZJP2<[CFF>5N"8R*-D+^RVW!)>*Y29 MA!\@.K^LPYD&IA+FHQRUT0/]R>D.)77ZT0AEVV)3)S9>'Q^].-YY1>U(6MYD M[NV<[L1S/%@[V\H?PK_L)Q.^ADUO5_\N7GC/]D^.#O'8TXG"OO=JYW_J^X?/ MCR`!MWWJ'BSK@_UG6-/O$V'L[C9@A3:>O=D_V*/V=G?SB/?NWOXQ?3.MYLNE MDAF$W9,Z>MO`-O=+\)\I1+^Y;AX.!J^QY?>M8."A=WU(/-$#Y?%1DE&1&#B^ MAYP(O;NK"WS$QGLSOMWMAY<>FAJ\Y!-=J8TE3\*>]7LL3S/VB1KX'M18:3S; MV?V?^N'>B5921DZ'7M/U6H\`TB6]>I*UAF9W[.D8VL#(%^+1E7PEV$;9:Z;? M+0)&`*3M-]_3'<)E.'Q/^];ULO9.KRF&E1ZD1\#',A>MLQHK499"_A>QP-]= M2($"\@1?TPG0T`Y`+*C_[O34_\"1H07[!["J(*I!UELQ&S27X[$!$1PZK+61 MP^<&Z'7@XZ5LB-[![ZF5XDH1L2C0+[S>9U>]A;C*003C&/#%SB`(!]V`MQ1Y M+<%9M#H"6`AZ03S9V@T;#-%IN$47-TJ\-^"="0!IV81,>B\P+`)YOJ?MG#R' MAI?];DB>6'4P!=B,+4`H!U#P$E.-+LE[4<=>I5J7-.SVCER$,3S6R.@;X0B` M:!3R):)%(%VDYG<8'(`>;6#6\!=:],!/)-.0G7_AOS"F%T&??@TI`5VQA5A; M0F.$I!8/_\ABP(`D,&,(BJP6N+!VN!6BKACFZ;-Q2'9-5)U,MJCT5,(B+30@ M)RT[+*!RU.&+T?=!,$`*BJ[[35PYVG^X:!C%M?N)U/20@"B(;.W5SN[+?9`+ M>.B:@W$1%7<87_I"%.PG/9R[GQNQS\'`*8MOB<[7HTVG)#Y0.E\/8U^=062_ M1!7#)O`+FOVF8=:_\9W,?G[PK^P'/7C9SS^P21[Q0)5"85A(F:S.Y%M%O[4J M,/"1\>+(88PXVHBH['!PJWLJ=BXE64^'=\1%XI2GB9K4\2%27JM:+LD$#>N^ M2%I3C#X]\]F?:U7^C8ZWI7_G1?T<;1+TD[!),&^*DH*!2)VYIT\RH'`2W.GG M[XW8MS/E]&GG'#^=2:?/A_%/.^WX&9MF3##S3!_.1./W.`[:G6O\_D/GDGI/ MD9>^^;1DR]^V%_+]4'>#OVT_Y/MAXMOTA+\'FGSYT\&=$OBGT7'>7EN6KJ!^E\T@Q+$:?.H<'UJD&"9CG>4=TU[MSD&R2 M7L&+LL$1A8VOG$]\HG8^ZT*7[AE._@NY>*,#T1>&.,:`(<_K"!&.FG:E$9[VS5W*>=# M_X+C=311).ST.;8'UO<\DL@;IT>-USLG,CI9/DALFQ-%EE*=@]IV_-C&^62N M'8T@3WY)^LXQ).T1D:,3BH0:8%"T4?(^WM@@0Z M'C;UB8-6/%`FB#@#,H@,@6,L1R4XENT?D)@C`EU3"W1-Q9]:;&PZG(#EQ29V MT9&;9$,C@%:E&HN, M34=DE-9I#Y+?8^>W;-E.H[2G2ZYLJO+%7+III.&FC@O'M;5PVV0ANC-+41C@`R&V#36DU1(;V_ M-:V)D_RFG8UKGW%-1X02%%A$L$W@/M>TEF%8S,B[_%MFS\J9_%MF@OJL95G. M0?%3RDC?M7@M`!E[5\JU<.)3I?%`L4`P0Z&%?^JNZ$V5@>C-6S!N:XKJ$CV1 MX"'_FNXXXH_Y>$B==@0?`T9+3B:7>^[(0/J#B+E5%W"FG56/BT0I-;1EG.%^T4(S\ M0KGNI[L)-Y7=@:4YLP4WE=U_F\ILODT^1C;U,;+I>2\U'R.2EB"&;?HZK\B/ M*_@7AP`]&\%/O1PQ)`)\!NYO.XWZPX#D>3&?,F4"DU3\H]'X+((/8*FT0MN: MN7)I^"#V1WC5:H]HY0WE/9 MO2.\,8/M3.[.8.M;RL5$"P!>.CRJ__3ZZ/BT1M=]1S_6CX_W]^HGVY#U^N71 MX<\U=MVO[Q_IPZ._8:=[&C3;(9H7H()K-.Y@O*+@"F\#TAZ%H*"$N+3Q`%RP MMP3P/%2M#QU5PRK-8-H0+3U=<(3(WEW_JE$$M%/L^4 M$K)QQKJ#:<>.,5I+BA0"I9*^S,GL.$Z_BA+VU38Y#Q0(::]IL<0;)RD9+;$X'R MM5[D(4^&7>APYNRIXKGB#"]SOIW-;LF%G^K@=!D6H;8P-`&R(+;(`Y)8.H>_ MH0PE*K6"21V578&R6R8QKP`H%H6\K,D((K^IZ#=%#-[BFT!8E5CRB<;'<_E0 MS<%%X\O8NZ7TZI:N;JO?FQ1G`[]^1ZD9SB/*.8'$65VRL!PEXBW@L2VN$>-( MP?9`!E\%CD5^'=,$%G7">[1JV!&4/15ZGF=N2VN.S&TG;)K<3R<'5/:50X"] MYJVY^-T`(/'OVL*]L(3 M?-AY<6*Z0SG*/`F55V#[M"]*R2^0-EIA`]\BNM?$DFN:#%>`VZW\/[9[7BG5 MX;\!_-<9L%`"\H_?BWAGID<+!,,`5!R@AJ$L;T[1J#VMU96B:5Q^S8)50`[_6JI M_7<`A]?QQ6C4BDHCF",5D;VYOIU`A7=4)]/:\M?:<`2X'[U_HS8`AS6_QZ_= M1A5(J;.SZ$%T?LKM)6E)P'Q[I?=$DT'#^>'B:JTD%E#;]+8U["N3!?-!=F9CS/I9B)"4_= MDYT2BVW)$S0P78Y8#*`EK"FP3($%11(-)#8TS6YXANK^=NBFM&8*W+PU4Q4I M_I4_?.]Z^X5Y9_(DD\]^?*TX)E'D2`I2T=JX#W#T*A)C4!\D"PK>2.2!GK$P MM&DD9L;XV(=@M9\Z?,CM(#DE8NCBSA^5V\6K*SRPN&J6]'Q)/`LJ(#@V&9]"+)AX.CNN[1X?/]U_`1AGKM>=( M'#6EG$5/S2![UE6U!,)MY[V$//)9M8UT<^/:$_>^-P6!>C[HFX(M_7T,"DM< ME!1F8;E3D%BU7JJ4*GP+_N/KG=.7GGW;J]E;#,^\J=64_LF)\D944_:#,^21 MIN;>8<`>[,,"@65Q#^4),B_:W$!*96_2@P;:"FB7G)&*E=M-JT,QR0:]WK70^R%S%*LZ]-_'YCW:"C\$F29[5;K.WG8_ M/"`2NL>LH2+@;EU+3SI9SB994NY>^H@=_-2`S%]^W5;OLI+`AP?IWN\%]7L+ MYO;W=]FM+!QH#"2CSF"\$EG=EP_A>WPE"LYQTL_&G2YM2!P[#1T_^A@Z_=:& MT!N&^)B4>?KC=@SS3(9$YU<[_[W]._KT6([*[TJEE7)YV1;A$ON'ID1IY5UI MLL2/VTM+`*?T.XAF,'!+4`/UY267QUAJ9*19.03^J)Z8#)O^H^BB0CZ.XQZN M0#V0:!A%>R.O/_%):Q_%]%D*.D[E:N9:B,2-V#./%;V7/WXLG,B] MI_9%AX[B^XF3"NM`@AQ$1$;+E0[_:(8GE5"H1-4D*(:\XL7N[K)QUP1"PI`> M9J\+HL3"-G#DV<8MA&?+V&NMCVPAIA281Z\[XOL3-9E8<.E$&(]X8C2<7=.! M4&8EMY32J;*'6]-FS*INI)1$;2N]9(IH88AF[\4_5#;9Q:QS=MRBD`[T:DO% M6Y,#\N>?J`;8&4[D$/W-&)-X:1Z6*7521R91W^;-`>*.3P*&R1(0TV_\%A*E M^4JHXWGZ.&EOD$H)?TQ0EUQVZ--6`]^@$6M1+8BG(VZDCII/B)]XX88*T["J MR;M;AVRS2["<*ZR?&(6\AK)+?\^*OKD,0*15'\S&5_*P8@V900GYE,&@B$,#_R=USD(I7AN`#YFQ)Z42(M4&/QPW`WH3(,65#X^PONL M9\J(P^8?J>Q%LZF*KUYE&<5*S=FM'5RJPO^6@><=J<.C4T#IH'Y:Y\WU`.1L M7,X,7&RY2LNPZTA=P5T#2U[X_!U+.`JT>'R!A56$W:Y_$4@=[K@G/::QA#,_ M]3X^I+,F35H M;DE[Y^;Q8'P.?K8Q=^7%48*4Z?A2YJ(H\T).:='S<'476??*N4<6/:1S?&>_ M1(%#6WK(_03-!(0U],<1#.>\8BD2H!M);H)N']3KOXTT\_L+[!W5<@A9I%Y>\V*5;S=ZZ94IE_9LO[Y_$[^<\G5MS1D"GI5V@ MA@:V'M;W#QLOM]-NT3Q/KX::>]^WI9[B3F:&&L?!JKOSML,V M16%/!?ZPB]JP_@CMJ=ANG*0DXDQX78&2Y+YU;T4&TJ,.BR"HTOX>?P,?\1P4 M:FGH3CPF4-DB3L[F^@2&'MX"7PR!/JF+Z"@)]<+V3^UMRA.L5WT"G.-#F0RS M)^Z`^:HW'`.I0%&\[K6+*2H_U4I53\M+.?T[#\*I/$E`J2R4$OGR:9FD7]LQ M+<*6LTZ%Y3(KLY56-)IE-83&"6CF<>JX8,X3.QJS5Y\=-#WY>CC1K1#WUO=#5;J*(PF]OP\ M:@3;\D)?IG<+]<@63:7S>`/FDD;_F-^$6S+EBGJR`?OL%`-=#``5A&QX0GR M`'L-CSJD9#`"O[5H@9Q=1)82G<`6E49LV==LO0=E#U^HG>>G]6-;KZ"`#[S= M/SA0+X[4SMN=GZ$18VI0,TIJGK$ZJ!E]-4\78KTU*R7#-RM".&DX<)F!3*?O#&'Q*8_,I@&`M,)Q'14\;?M2T2I_S:*C<5T//U6.OQ33]DH.* MJ?.&VHZJHX]C]6\\HQ=1Q80@38X,*>XV+_C@]IX3. M%M*@#04_4M^N6?W&?R;\1#D%DDH:L)QJRM)1%6=;31@0U MHS;K7!.(NIC5'//$M*&FE6MM8:MRQK\\;593,QJX_]2TI*W):D9)>/9.8.&D MP-?L;.U7N7F"L[7J. M6=;7XE9BR5&AY"]O,F:?7HO;HB68%R=_*5^S)N,UQ]#MVU(UF]AIC+3!7:(T M):_-IL6_?B5XKMN+FFL4Z#EN+6J.A:#G>J*HN?:"GN/ZHN88#WJ.$XR:8T7H M62<6-6M1Z#E.,FJ.>:'G>.^H.;:&CL*>QM.J[%GW&K6X(:(7\[51B]DD>C%G M$+6XB>("NS47_5+"9A<)-;:)]!S_(S7'0-+5-%1Q54/K@Z#FF$[.YD`+8NQ9 MSPDUQQ#SVRTZXRBE9JQ!/78]4Q.+T+_F/E<[N*BY%JL^0UJ*S M_.(6KG])FPG#22_F1:06MZK]F@@\%-84L^3]B@@83A>S'OZ*"!A^$+-6GB*F M,%*3K<]?`5.1HN.-:V%K;5ZG+?F87:VMGQS9A_&1??BU1]9L/S%K[_F\\R_A M,HD,.7NFGFW3#[U3SK>S#\M3WLBD]2!YRDT;17T1XUK)?\5)'`Q<%LF&^5^K M>7D%<7P`_-6[@O&K4XMY'/C+.NS8SGOL+JDFK@V,E;NM#M]IBP"3IU(A9CI= MU(Z6:J[K!#NH,UNFX6JRY'DL\XZT$,QS7)=_N+.%ZJJO%7*@D2MLL>W*?KSCPEW=@RHV6 M.*"KN4Y@%L-JY@1\@7)#W(UC+>&29KYJRI<=KQU7@#77_\TW'Y,88G%O/'_U M(ZCKJ;`6\_OSSZ@AD'#R64LZ)_KK7QOC/@AK"7=(7T2UGNO.L.:Z5O)K?^O\W\W^[:GQ__"U;[^F9\_BN5ZH.[^%]?Y8]VV';N M=:ZE> M*Y:,1PWM`QED;_@3?TX9Q21/UK)1^Q`E=< MG9@G.RI+M&V)1(P@N(%^W[498+^AT09"LQR?BY>S\[^411-RZFEFFZI.$;^ M*#PO:I?2^!O;U&721]"KT?#=K=.OS?]O4PRXR?Z_MH'RWVJULGJW_W_3^4?F M0-SGJ\K_,O^5];O]_UO,_UFG/QYUNK=\"%A\_:^OP\$/U_]J9?-N_7_#^;_5 M0\`<^1^FOIJ8_^I:=>-N_?^GR_^:&A.'@%+I'0B:[\A7Y[NVEI&-5]TOD\=C M;;I"^>>W^D\MP\;7?[?U%US_+,[_JYL/'JQ6\?YGX\$=__\V\W_[US_S^?_: M9GS^,?[[@SO^_Y_._[NMK\GYI;7_`)X_<_T'O7$7W7&5OP7_?[!1K>#ZAX/@ M@SO^_VWGGZ@]:G\%_K^^7DW,?V5C=?.._W^-/R>[Q_NO3QN'.Z_JV^2B[^C- MZ>LWIQCV\=7.Z7;6+^E;]:QW6O_IM'%RNG-\VMC9VSO>7KVJK%97O=<[+^H- MBJ.)"<`[3^HO7M4/3W7:^BK^\0Z/#K'D7F,2S*J'H1:WL17/\UR4\%8YB5*' M%7;.S],Q\A_.Q:AR$WS^`]<_NBW\%OQ_;;6R0>__J^MW]S_?>O[9>7GG')W& M?J7[7YI_Y/]P$%B[X__?=O[UTV#0^XOW_\VUU0TS_YNKZZ01L'JG__-5_HB_ M[*@==+LJ:@X[@Y$*>AURF+TK$7"**T7X#7^CXNB(0SB1O]]H?!:-.B-R^!^5 M/'3E^B18^EA_]>9@!R/!T![^J=14CQ_7CYY[Y15N3+N\G?1XZ:)14MIK97UO M__1[M5+V$`+2IP2-4DB\G;[?51=R>,/$B\Z'H*\FL/"`TG;AP$;^=U5N-Z\J MCQY5"OCWFGH^#`)U$IZ/+C%D^'.,/N-CIPIJO]\L8=6WP\YH!'`!S9-1\"%0 MNVV_=Q8,NQCI(<*4I\WKB_XX*L$AU_-B_01Q&@/;J1<'>Q1"2[WHC]4!Z^I* M4>VQF5P(!^AAG7'94M?AF%PR#P,,VC3LG(VA\QV*-%&&'O?"%IRY/8PCT&]Q M7"\U"H:]2$>=>''X1E&$1QBFU^.S;J<)33>#/OJLA78Q!48=Q]_#XM-&8DL% M'0H<]D'"0%1U`P*M`+/AY8`"`.&A"@=8*8_QD<1!O-1+Z;#MEPFKT`X'@0G3 M0*&7V(WU^;A;\##TV-O]TY='K+RLWNX<'^\&?G]T#3A[K^H@VT'YG6?[!_NG/P/:ZOG^Z6']Y`3CCZ@=]1HDP?U=()YC M]?K-\>NCDSJ&)`N(Y+P9PWE.TT$AYT=^IPL+POL9)D^"C+31H_XP:`9`GAC: MB"X/YLZ1YW?#_@6[V!XYX[:%02;Z(7K?!L(D5_T3L^R?-"87E7=/ MA[[(DHI(UDG0]R39>"%60L^Z5;N)FEJW)ALKTX.EEDQ#;I!,(Z:5K-N)FM0H M.LJ'X?T0=EK(-29ZU.`(,`U8LS"E0`H[KTY4+H?E\_DM79UBT:RDULU.?Z16.A$BAD!<)+RY2.3RWD?HRWD?S2QD+C*9#+#"_5(`<\J$H/1V37.G M%`]#@W6@&KX3?55M4Q0D3(()Q8/.IRWO'@9@.U<`%&%)*PCIDQ?OLS>GTSGI MID=;N]/Q+0^W`,_$#.FK[-+NT:O7^P?UQOYA%ID/AG4[(2B1Q/5%Z" M7_UW[\I>)2K_5LZ6O25,Z\./98^WKUG[UT<8=NH6=$YZ!8.Y"A.JF9+W]!]^T$IC%%ZH0;9\PS&Z;(MT(1ZW80`3U5<4WR>[ M%#6ST$ON)*`[@=[5^/U,(RW\+WT8Q1N;/M\>0` MG358D*^I[[PC`Q4\46GY'OJ M1N=DZO27GY7OJ2\Y+=]3GWU>]F";I]`TL%V7O/#L'_JG-QC"VKJ"W^5Q-"SC M?MC%1,*J,8+QCM!2HH$A:-6V1Y%O396E'/_,>V>=/D-/\A[TVM<%70`H5262(0F3*SJ=BU!Z!3.J*1E5S%A+ MR5C#C/64C'7,V$C)V,",S92,3IF0\Q(Q'*1F//)2`DQW'-,_& M>4SD4;+',8`H2X8T7X8T#/@3`$<9<XY+LN]C`8Y@ M.PR!YGD/B/`D+5A1QX2HF$`\"B")]`VT6([:GBS+4M16Q:8NWGA]?/3B>.>5XO#IE);WW.";Z3D_H2@8RU+%T?8RSDS: M&LLOQVM6W*J[BY*L(UG;_8/]K8ID)WW M;/_DZ!#'K(.*4Q@LL@0C&H5]_EO]JN.PD=I2(K-XK8H'B32)N4K%32D,UO:[ M=U#_*='2>3>XHK\FV[%96\H!*2D(#H_%@=]LPQZ.;#=4&/4;V"23H4C^<([` MXP.706HK=L_#$'UG#/UA)X@D(!X,4P,CNN.FAZ'SKOF^/.P'9KG(94\.T(?M M$_90V$BZP?F(>#^%:,Z=.NT"(!U@%PFV1FP8_K7\&#\+("-T,<*W#OR,>PDO M@R(O@P*VKP,D1O&^:61E`[R`S4B6;M0NH=1TA-+!90<%`?AU33@/@T'7;^*^ MR[N5]))?+Z`M/10%$YBQYU_SSJB#2==,H>V4/GEF,+=QCG9:&)PQQ-<2,^H" M&-&A&)&7./.P_W9X($;"$Z!?*)&@,!7A@1`?0>C]AT(X]HS\./0O>L!-8#(/ MX>SV8[V!&&!46\3@V@L52'#8MMHF$`3L`$`SQ2*0& M;^]H]\CU%_P2X!"P45>QX#/3XZ/GS;>*2B`ICB/1(B&GQ%YJ@+T[DBGW,28A3850M7G!.+-1\RK MN+W!FBDWAQB-R60!=9\D&.E%LXDEX9^2/\E+8[G"H"F@WV#8Z8^*G%5$!(JX M61%[5<`IFZ;)^JLW.(`]F'"\(8%9W?WIIQ0(?%Q4J5'PF7UNZ MF&7RD&Q2D=-#6V;W.[_HCX4UXL0]W_^I\:I>DRB%;@-GP\!_']'":K;PZK^D M!.F+^_=Y\QB-!W(ZX_D!1M(++L/A>WKL3W@CU[]I]?UW5.WQTM+'X=A M..H%GW!)P?^#JP'(.O*/.PA6W43BW,^LN!6O80;%9-/>=_SF\+1^DD2(UYR& MVPK^X<-HE8?C/CU]I*)D<)I==RM1R:!E"Q!B@I=,E_YL[.[>@%B^B%9,BYIB M3'A>F_452?>F%!K'$7#_Z:<8XDZOY(,X[$4HHC:(&\"QNJT2!BY%YL(R`[!, MVEY1E&_Z`[I;I^,VKB3$2X1P.$(BD85]KD/V_PIU+X1S@=`.2P0V"GPRTP*U M=[!'8C1LFMRPYT$RA@V6C+Q7>OWRZ/#G&@9I!W3OW5,O*8*S7-V2[!_A`3DB M5?Y.T[D/PU`Z)WI\Q_G+]I]/CG<9>_7E>Z>#) M)1CS"!@S'')).F/EC]]1CE#-=M!\OPP'Y]+)F^2!RB4,.(LTP4<8V(RB$,3;E#JQW"D,)'?)\;I)0S1 M_B'_/G5^[[J_A=!*IO5=:CP14OXQ]BBYZ:&@Q8<0%I!TG%X?Q<3]9_7CTY\Y M#Z,/G@7#T;7]!84(=7,IC^@'W?Y[CC011.,^!H0)G-@^`6F/P[\?@#;A7XP; MC3[!SYKHI#N0F!`!1B7"?QV7HOA;7'EB)1W2@7^@X[L@..N%?0%`7@VQN6Z+ MD:&&-A^^EU"$,&M5CA<11-!HE7_JP#52_H/?[W2[OL[15?]X^#[JH)?D`#UH M=RGB5F!CEU!+&$BA@2_STQJ9'XUS:^>+CH8 M^!P30;G`^T&1F^(P"7L.\Y1\_W#TAT7_H8 MIZE/(,SHO&Z+`YG)&Q/_N!K0O_0X@3^Z?O\"?@!:HAN"B:3H@3\^!%R?;OSP M5W`5C0=Y44(`$P$V_U$_K!_OG-;W&DZO4>+EOE%D45OF9:*,Q@U$,'(-XQTE M"H0")-0=#_6(A81!J'L9:KQ#%\U0NASJ9SY*^1!(>>R>E*'._6M02`&].6%@^\NM&T-G)"B,5[;%LQU/&;C=8&G9Z.F#%4+=:(> MSCCR,BPP_:&R<@C()L0E$H"R*#;WQM&(%J1O[BK,RW)659[\4%4B):&UFJKP M%TE1E.KL,#?;JXI[\'/GS<&I7=_;RP;?9$3'?/9(SPI3U& M[S5K:9?)<7^3RJ6\WX\Z3;K[,7JFDUJEV2UL`;;+HADPNAX$ MI!>P]/'??NF_50J1\FNU$@C"9[ MHM1J-J^>R#R/>FAAB:O-34AR/6&4-6%V75SD!W44R?95<3?HQ5:VE"CJGI5_ M@U-W:07?%7/YK7)KV9PV.!<5WDHK/5)C2"D0E3FK?"7_7DC^8V2YI6N0+=43 MS=08A=32ISV(1?_(R$OU!@Y'\L"G/WCY,P\H4^!*L+)!YF.F2GKG@ MF+JA2?Z7X&5@S-W6N*#'5SW34/*_=)S\A<;(I_'1]T_3D-'Y,_#11:;B8V#, M0TD*>G+!-9534>Z7C)!`F,NEV"F*W++-1*?]Y?BT%T2H[I].4:]!3'J M>?JB=29&T9=C%"V($:SZ:/H:B[YL?44+K"TXANF+\:E8K/PX>A>/KI9>J1D;-G31N7^$)T&(I&A]YP9J-$1>:BU;P=O,B/C7V8 MFBJ"Z`)?0N46R%PA1$IZ02OHCOS-AU,1T_E?@I>!,0\M*>C9YZM9XT4%OG2\ M&,@BXX4E/?M...ML\L4S:8$L26_+,<^ZLP?HZ%RK2DF?>E&<.$Q;X.L,$+7GF<7OJ.I3\+T6) M8"R$E1XI?&>?A17F?YV!@I8\^TP_!Z?NUT.JZUE5@:EW%KK`%]U9+'(;IEOR M6.,`<#R;A964^!IH<5.>Z%),O;&@W"]B!PQA[IT%%O-<18UI*#E%ODA<1PB+ M[3:V1<]1*YEZE#`EOAB]Q;8<4]2S:BTS:0P+?!T2@Y8\JU,S2ZSY2A?!NBG/ MLVJ"B-614=5@Q3'\933%\EKYS'FJA]I:H2)T5`[G@M(Z@JA-G="0A@.J:98`&EI.0F,C0#&"LT9XYG?AI#CLH&IIQ`:B^(JLU:L9#AN, MCB,RESDETP/4F%#-\9#,P5K!&>K9^Z3@C_J3J!AZJ4T4C!X^`@0`[!X`D#L. MS]0Y++E(D3T0J4R*1>=9(!8E9+#&%I)Y>M4F2YMQO_-_8]::*:E=/X)]ZUI` M411 MY2?IKJE!.(+>=V`$C?>#C2BBPAC#9OD(KZ,,"^V"M67`62/N85))Z/JD9PP2/+R[(WL./.NB& M[)Z'!;6-7WP(@8/O??8B"V# MBO10F75`7C%Z/KZ[N@89I5(I"X6&/5(41[3^#I^C<`QCI'&#A-X'NR[HQYG_ MWL"^=\]9&+C.IF@(H?8BZ5CV+5#G""$9;?N5GEB0E#UV8+8-GEF\.QKHT_)Q=]@,PZ'"HB_/7U!JB=$*8 MF]_S2FOL8Y;-<^IP#^S'O/*F%['OV3T?P9;29-B'7Z[VB..Q4#9I]LP&L7ZK0J3EK&P>=@3['4L7.XNU\_ M22V%K8GJZKNL$17>9:=A)EKL6%:$B>EEK6([%K<2Q_0:KID5UG&^%ZA%IF)N M-4Q8H![9D;GU2!1*KY<^U/?4CX:SQ?B8U<)&MG4(;*N.;(LXFP,;O1CQ!S`\ MAY]BNN:CHA+XSLMD,JC^5BF4?YO:<&GEWKVR:BUC*Q9>,<[`/;*MJ&DK&:== MVDDFU@M;GR?7@MEC'%,AMNO:)AK?0HNM<#B2Q"VW'(O-VU8/SA06=PZQTFQ[ M!J7YAU-:K-)BI=/MTZ88I[D5X<_I[@$2P?'.\<_;<9.P49-L>X?^\#K>'.I< M,C).9;)2XW(@L(OY$@CH1;3A1TLDS"@6I;/V&&$D165JB6R/%79WM[,FO0'' M@*SB4T`LF2MDN<9//\7R?OH)ZXB13")'UT/%4%9U7EKZN_I^6ZV:F69E99$G M6+3`;CJJRZQ2>AC&3+A9`%;7P:A$A5&K6&RGF!*-,CE]*CX/`WT6X5FZQP>Y74 MQJJWTLX:ME/E=JJI[:S=0CMGL/:CT=`?8&MK7J;9&U`/\,/0FRE$AOI\<-+V MSTAON_?OJYB?/SK8!.8;W0Z2A5I-+!B+8M$A7^?C?M/Y"L-2N,BTBM5;95*SW`F<6\K@$N/)@A-9V\`1Z.BYVGU9W_T?.0N=8/K> MT>X;C/5!]S\F`]V%Q)5R+F6N-GQ MNW@;1?9EN7Q4CJ[A?GBQC3N@FX<\_R5*K_UG5FH.;5:,KK>`G MN13R6A\ZM(.@&QS^IQ:SR2B)#PR5:#SFQ0)OY:)QKR=C8!Q?;"=\72Q9EQCL M$`,=\>13V\,-`*T_)A#"1%TF,PV*6X@,L,]#95SHA7T,;Z;.AN$EFII[8JGV MY?U>RFF'0WG7O0F6Y/V*VIG9W4E$$OUU6D"(NL[TWNOEB1/LW8L"O,$>V?M, M')!L+\H6X.\@RQ;FV5XO2]Y,R!,?.?M@'UFGPVOM[L,G]V_]D?7P45+J0Y5N MVM!?"2RLP3`8X*W;/_S^HXKX#Z)K&+^/7@#92T@!#BV!!8(-$4X#6+BPPS:# MB-P!X/498(:W,<4.W<68&IW^!_%B&L'"QXL\]%,2#M_[0W07%\7]D!2K"EU/ MG<&1Z!I(XHH=]K&//^NL)"J@CD,PPIL_^-,,A\,@&H1]'%JT+4("BL0;3[(J M75W)12TZ5KFOX+B$]T_?Y[!D2/84%_W!,',)$:=EJ=YK@;CB-`#C;6 M>-6GIBQ2?JD7I:\^+V-LP=Z]Z_3)N1KGB+$7G73+3YO*^*LI_L_^P4&Y@&FX M`R72W5J_R;Q`X=\`'\#L?`+R;T^;[G=4_EA:*13*'\MNVE/%YG8VY;?$@)1M M?Y,%L>')PC"UR0JIW.E/-OHVOJ3'RJJ\J3<"CZ4^WC4H(;M_-70 M?V4?UG(-!Y0SB:ZXT2=.*XB*@X#*%7N]/)%)[U^73,I/^R%VL#^*E_PG)I[> M/.(ATNDM1#H])IV>2SH]3KI%TNFED$[`I!/<<9B_A$B"!3E,L!"9!$PF@4LF M`2?=(ID$%#/C(JC4T.JZ":T5^=6+4_&3G`@LY:R[@[S[9F[*Y9HM^5!;2F1_ M6ZS;RDM+U=26J@NV5'5;JLYN:2VUI;4%6UIS6UJ;VI)_@<_9([6M\?,P'(@_ M1#^6-27MXRQW^#UY2I-DD(X7+DM+*%D+U'P9/S&O#Q/5"HHR5QIN?-"Y5RNJ M5,J+_7:+_G6FT\"HIL"H+@*C:F&LI3D5/OM0O_S?X%=3&O#$*T.Y7B/W(=5;SN(_*Z;`#TA!OXEB- M(QN/&6(2?(:A3B+)7]\A?]TPPMGW*6Z MLW1O,OQ8.7'XE?$9!GY7QHC^4:;OL7%RB<><0C5]N:.;A*),`W`X@.,"]*J& ME[C&5TW>T6K@#-@G_+/VU1]]I3A!GD-4HMX[[T]U@>?2X@>5'8!`AH>WIH_/ M#NB]]0R?*\(Q/I>%S*#J$T_7\;N>BCS[7M-)'H@+DAL,D%!A2??-$ M\6G((3JVW0WQ6-V$DZ/?O$Y4TAL;GP;I_#R\&%/3<)@Z/#I-E-=;.[9"SDJ: M73]J%U0XP%2\L-XY.9W;!OO<-%YI48LIN!IE8[4H<-6'X%VIF?4\#RD;Z#\` M1A6IHGL!N5+ZI=GN7O^J]`_/O.W4%,YBPL>SN8UEU^HHDDR4JB2NCBKL);QB MOAVG*HZ;(NL&Q<)#!]8`;>D\[N,;$XPG%"#N_O;O,YU7;[%?%5AHQC]+-@M@ M1[_+6Z!>'<9'-WKE[K8D%Z\`38>7EOJ3!>5%\<\_'=S%,[$@\"N_*SWTF/'RTO\0&+^\G19>C)6@4H4TC-#M"VW&V:6_9^5&2';CB&Z? MPW/K7*OD8<4:-HF1>V->MU[.\+^5NG/)>SUBHF\'\ZC4`9,$?^=U#M'BN6GR M,:/^I"1.EJUW1>2\W6NZHD-]0W+#S%T;CON1RI);SU>OLMR)2FVVSS`7OZJX M$5J^I_T[[=4/ZJ=U=?IR_T0!DZZK8E$:'$C0#,`-%'BR'4Q#UXT2!:@4_")U,Z8$];W3UDW M]>GW1DOU^V4WFZ%@ML#[?IF0J!%"S@'TMU)IRM"4"[!`EM5C*U$\P$BI45'X(`F MN#OT]C3N]:[E[EM<=C<#A9$WQEHE4W,"K>:%UZX>E:M9J'P"\'2+M2G]%@T9 M[8"]@3Y:\U9')IZ.W19_4`D=3N,'W1\,`G\HU]PIT7G;?O,]_-:+""_.9<&6 M^.5MP75GR[[F\#10]O"%VGE^6C^V]0IJ_U2]W3\X4"^.U,[;G9])KT)\%M:L MB\B89K?5Y(:=L],*FMV25J'7&>$9=+OY?J8:^#E(,OTBZI9/5+<:XJ(=GM#\ M-CKAK/EM#D"L`NX9;XHUZ]ORJ_0@Z>+2Z+(;%7:KU.[JNVM?:]H?9,VXXOS6 M`S_I;9.G(C'PHFIO/%76K`_1K](#C>T42X&T<1?&&M6:^W_QST'+OSF:`(,Z'L3+9F7/5^3>39+:_+!`E%S[J_ MK3FN@__I=AA-1-PC,Q-FX'5OM.??FO5^_)7[`G)(.!C-6S'43^G,%*8^G;Y< MLM)3Z[&+XQJY.EZDTVD=1L`+=CHV4<*V$^(`N7VV_H*-F^::O2[]9Z$SO3J2 MO#HQTF:&9,YT#\V&1>ZGM6_6J=W[D@&/;90+[+!QCH1"Z_YS]?/1F[@@^K)^ M7$\*G]Y_2OQ7;4):OKTVU/KJ@XV-:?%?^4/BOVY4UM-9O M./_HA%',P?_2^+^J\F"UDIC_ZOKJVEW\WZ\3__>`C2,DKAY>LZX]W%2[1\^? M2]PWLIVEB&`G/QZOE:JD*G>R>Z3>]#M7"A+@?\!)2QB&LJK:D(MV$E!`6['2 MN7]T&2HLH:T;.>2?WU>G_G47&GW<\?M/F]<7_7%4:H:])R4R2&4_]_7#T^.? ML^J''Q3]VFZ04VSK)ANO2,>PC71&.D2N'SG&GO`=#ELV\-GRIV5^Q(S:0;?+ M!M3F&0(V#]QP,1;O_N'^Z?9RJ=/OC&`;^ZA6\\A$_+.(4'GX6_* MP\LGCOX>BU>>FPQ@GO>6/J(';1NL$\,F4"=S2Q_IWT]YSSNI[U*(#`H%CV]E M([7T\;A^<+2[@]K@]]7)_O]"GY^GK?X04-4 ME6DG#96`\A/-G451Z@`PM#PTN;.W=RQ?T!K4^:@R^$>W"A#R\GOWZ-6KH\/4 MMH'.MYUVW=PB?"%]?$K+0.*@#+QA.X-_5.[PZ.!H9R\//4=DJ+%?)/M7W2W\ MBD;#>/ED<2S`-3YY2&*WS?^UM_92U/XZ\=_5Y@8(!\+_'U0W.?[[@^H=__\J M_/][';GW7CQPJ2HZCA[:%-[1^.(HRA6W"1/&X;3N`8PWD7\1U!*@Q,!00E4[ MMN8QT^UW&*B8PY38:!'T5&8_J8T3OS?H8LA2;&H"[W+K'ST@Y&(K^!"6Z:]N M2\5#H[*'F&(T[N-_8;1>JI36J/W4#`P6P'[Z[^%3?&O<#"+Z+EW)/V=]^:'_ M'VG-<\=C>VG=FXRBLK21#*ZZO;3I M68+='=,_96$KR5[9 M6#V>MA'&4D[,#2Z7"+P1KP9_[JE##LTKWVF!@#MGGFN*W`=!ZF."=A"PP,T8 M$`[2MEC^RSR2Q$ MD,XY7&[8#[2SEWAC[-C&;X[8M(WB&O+[(TGS8K-!UB8J'+")"\>?YMB5&$O; M:92,;W!M342S:M`%2YZ6VXY"KFBQT(O.!`*GK)*4-$/0B81QL#&U#HLU#+IB M?:-RQ:$Z[_H7>5UW[-3M=MX'"`X8"-1::84KVE-0S&XVAR:=,2#]&0C@FL'" M*M>#@P[)O61XBQ(IQD=&ASH#V(,,L+/9T`X7A08"_PNT86R@6`OT[WX6ESZ^ MWGE1I]\@8^);*C+Q'DXB*KLT=@[V7QQB<>-(:H//0GWT7$3/MIYV0*-W<#XT MQ2>U_-AL&D]P7Z7)!(@RD8!EO+G&-BSP1%(QF5*D7[EXES[E/WW*)J'U4\#U M)^`U4FH>IM0\G,2DE%)UF%)U.%DUI>8XI>9X$MTA5L5`K:A9LCU,0-E.*6]D M@$31;/I(9KU<:4$.TLP[;*W\FUI90L7V)W*;JO79)F6`JZ'MP7AN#\:?O%TX MNIX>O]G%X]'V5\!O;/&;B]XGSQ[=O@9N%K7^7-SZGS!..LSLZ<[Q:0./M%#F M\.@0U_]>(Y$%M)9(`>[PU_>G;SMT.+=#AU\#HS-`B:Z.LDL3XC,)5TOQ*G2O MM'OTZO7^0;VQ?[B-#D5B.SA(\)/--$L30K/NQVG]U6LH6Z>21?'3^*D4]/X9 MWQ#BY_\+.-Z_5%JWEH;<^[_UE8W-\S\5ROT_K>)[W]W ML_/7_RFO>&I%[8:#:R"$]DCE8-^M/'JXIHX#V+E&D3Y9ONEWR*YD=(TINWZW M`Z>+?LNI1B=>-"-`)PVHG!,URJ0CCC2(1U\HPOXH#ZZA-XAC%;P`4ZV`_%_,&-\"^I9 M,'P?=(-KPK4#0XR&,H0KG&B7EQ&:G-U:89.,=OB\C*Y(R&5L#PT&.GXWLB-) MYU&JXO0;(5$;?3(J\%$/9-0A-5\+HL?>93'Q',[78YAO;(DH),(Q.VG-I^B.XQ1J,CO9D3G4>A4+P0Q3<8;;Q2' M`)M(AVY;B"`T1N9FP=Z##CL`!56J1D&?*2_B]S\`0-K()T?/3]_NH$[(B7I] M?/3C_EY]#V9YYP02EI?)&>O;_=.71ZQ#@MX`C^LG)^KH&"'L@S"X#^4!P/'. MX>E^_:2@.)@VG#@*IN+!_JM]]EE4@$;KNAI"L#71X=&K^O'N2_C<>;9_L'_Z M,[7^?/_T$%M\?G2L=M1K.`#L[X*X>JQ>OSE^?712QZZ40:;MG/?A](ZW$B.T MYH7E@,Z'\`ZF&75:O_R*TO'3W+V\;`"9C=*ZRFGZRZO-^< MJS*M*0(G\.7&^7%T'95''=34>>+1)1RR&7INRP#%-=%#+CLG[C3?PR0%_S<. M^LUK31L8:+'3#W0-:`G-Y6`:4>$\1,\HP[!_44"OT+#FQ\.^6BV0QY>>L:'C M'@B$LB>AL3,O_[?Q]OCH\$5FU?.H2"[O??0R?$$$=`>@H'Z`M():S4\OL]E,CQH.3T86$O&,4<"&(A@934% M!A3^Y-UMF__6\A_]_=7DO_7U!P\J1OY;6]\D^6_]3OZ[D__NY+\[^>]._KL] M^8^E(/5C_?@$G6-F-TJ;*K=+.G?Y;$(^),'0K!^4#3V2#;^$5[SKO_-2F<6[ M_BRI710&16+MNAW^ML):59$DHC MT7-$E9AB7057XB@%EK9Y+-.2*$.3Y'I$V']4V5XS'/='6550V4:C1_;DXP%^ MKJI/6VA@/\*EVO2'K<881F,(,C2N/)0UL4,G[*7E,M"E%"KZ8203I_3?L7V$ M=!:U&M'HNALTQ#L'2I\(9@>F<``R-*^QYR?/%173WJYPM%!S/N5]-$F9E95HP"7Z7?0:`0DHRD;A<-3O#F1H>9P! M(ZS^R^JO7*%8M.`QX_Y]_DUQ3%AXQL\S>E_=5J?';^I;`@Y?+7.*L&$OXC_\ M(,BI[6VU7%Q6>05'@!PEY1%P)@(>`=.9T^6H`,506?:7:^QSW8\U14EGP\!_ MOZ5+GNF2&JGG.PI.]KNM>W[_/1,4ST&JA"D].U4F3IY#H87URA$R- M(+5&,&_T`S/Y$X`8L\5!/9_=I>>I"#Z?T:7SU!KG\_`XG^C2^90NS07U?@+4 M>]Q^IX"SA4;AE"+OY[48Z1:C>25/EVO(W[*G0U\K>F_143QLN<:`KGJC'*K^51D_]`0_YC>+=E`I."Y M;CL:`;B_RO\=89_-?&OUB_]<>]7_%57Z,6<]`)1^L*D M()%$>S;_^:7X?++\^632>Y&[0OR(\*]3_.N/&*Q.#_`KHE()Y.&(P:^BQ'KZ M->[ALGIBVCY-(8B<,H^Q(\;K,MI)%=QH@D^'S M[=P6+GIAGVK-@^\4?/'JZ-`%G@%Y(H/"!%[!D)=BT972(QMA=IE*HTY/#H17 M`/.#E2)647L.ME?X.QK,"M?S^]=TA1>A MV(R&'6&_]7?*AK$"8:3I]Y=1NZW;+8"L1]%)<,>G\PI6*]E^M?\`#.1*;LL, M-Z;"4%-WJ`0N1:%V2^P,,S)@"[0-,3JX^B:0OR`E-E[X="H]PQ.!3W[)V"./ MP0N*]C$)L9I='>;7`,A%>0=&*\P@`02C`>4I0PKZOFZ"JJCE2!RU.,B@-T,D(!?:)@C\ESB^DR3T>*+P$P+L,./U' MU[VSL*M&;#K%ZJI(U_H(D\%"K"U*6J4<8_`*#]1^4^LCKZBCOKZ;=P&2=C9T MF`]'?`5NCD9VJ=&I`3J1R4"19F^`J$,*'LB`%N#O!MH"`R,T3+N@#M\<''`Q MI`TNNLVI8D`#/&H8NI6$K/7@X.!*]>^Q#8HXT1#Q@"`6N&V*`IG78"VV^?1B3I_!$!Q?/#*%Q2/*X[7O830+^R`1?T?U`YLA)2A='^' MP44G8A=D(_4/[H+=FO[!A\E_J,?<-/R\?S__4;9]XDC`PT;7S;Z='WEDIPGI.4.G7N^3W0*_25F M.EOZ6)O)`+MZ#SWC%,K-]$,`%LEIE-O*X.G6)':$2E&!G]MMC`=`?HTS#!F@ M9/Y@JMF\$H.QFJ`!J("MQACH=AAX9+-&ZVG4]ONXI?:#H,5*SN)8/WQ?LL4L M/^_`!*SF9=@_FDTSA4IEX">HLP!@J1=0O!==`+^5'LDRRN=)>#!B&3?%6Q0. M!8Q!3D9G925_UR#-P14,X0*-,MRX#T_#'-0Y>XR?LH=_'%#W_H))AB(I]RLS.&W&,$M%W)(7 MQ:^`.&X^Y$AU]>IO5TS@BLA9&BL^$>YIOH6!@OB8Y>G!>S`"AP-4,P*.#@+ M2"%0V$&?2%7C@>.M8*P+V4"4(YS`16)E)W\8F*?_&T./SM7L8E#C,M MFAE-\*:)&2]6MLQ^G!G*?AR7$7%1PV39XY;>HB=$&6XSL5G[0CJ9%2@/OXT$ M0H,F5ZCZ),5[.\JA1K[C6NX.S?`:9]?D9E=O/%DRC^?#(RE52+VX4#D)G+N` M?'+-9AB^#^#X`GQ+6:G5K>[V0/-+Q0Q3"<<W&+!]M$B M@40P".'<[K$<,PV[3T)7[N%;#.HNW..WO@RX#-'*=135/#JW``,8^O0F1:=2 M//&T\4$5.0@4'S1Q1"^"J.#),0?I%L^=)4VA?(#'OXBG.L\=.DT+E.BA%H1" MJK#EIN#)9:!O%$A68N6CH7\)367@OUCRAV!X+5G\C_!"`@%$9L$9K/3D^"U] M^![P,<)>-+51?J,0YR`6.;%NB=ZHD: MC1&P<\>AKR3.L=V<^H&1-1*!,M\5^(^1)^Y847;[A`(E*-?`U@;N"EVK:B(B M.0UI'%<5PW2J&$:FDQ'E&T+B*A.0J-_J1I"H"KUQQ#;]"?Y^LO/J]4'=X?!Q M%C_@8N$!,>(_"$&-P#,F?\%D@G([R2*Z?ABQ>3^F# M.8Q;J1M>PMSCKO3F!PY7B@/I-7$_H MV$7^+`((*S$8Y^*R(3CIU]VSE7Z4OC;:>J!JPT MY'LSCTH3'-.Y6P*F:1C,K\@VI,/$+/%3^F*^"65^T0;VJ<>G8(FC8.AA:T9+ M=@8)LC-3^*VYLRY3L-ESH.J9%*AFEERH!N4%(-I!!VG13(;=/VQ^P6;+Z3%Q M=K0RH,OE94.`21^(!!^7<%8P1W-WT00!KNUC0,NX?DAFI0E214NKAD@1.J-W M02X<#Z05.,@X&UY>:Z%@U:F%93-T+BCXO1E&#E@(QG!-OF#KYO4A*I\H:MZQ MI653CDG4"LMZ^3OE\!Y%W=^.84B[\[R5@#$N?IZZ$&@J?L4-F\7DO]%3#?X] M]/%]&A8X$`&]0IA;!&>@[7$QT:7")*(S2`0$!\`@9\`:<%/`F.M<\XR%,FKL M(8OD_+C.+X[]KMJBGX_ILH1^ZY=U+H=T0@6)A(FF M@<"A)&5LZ7SZ!PK`OPTJ1&S"K-:)0X];WEF)=,&R%:]CCC<3;4RMPJLL48,Y M329!*DJD>C-7]@`W22^I\V,FR!PP)E7,YAR%X@Q-EOP-3D,I0[S0B2C]LO33 MY/E&CP7Q+7FN'(#H/Q!WAIKA8-K*H*H9$G5[4+&7<(^AAG,E9[<,=5`_.3E] MN7,XH8OB5G\RM?J+X_K.:?TX"4%RZ__?FYV#TR/"?O+*8/)8A=C;%T!A?W)] M920[YX7"2GLY4KC5;P8JUT^P`LS/._MQ&K2I5V&)QP.NJP;-97[]T+>AYOK+ ML)9I;R#XW\2=OU2*W?HC_\J8(RCV498=PV52H5,A'0HUVX.//!T1M>2$Y?0E MJCX*53:GW3$XXW2.8Q<_43J*:H+R+YU?4;XPJ'WR]#-A@L^FO"GQX-$PC_O! MU2!HXOM]_>BY\L]'LN/@7=K?6F4S]!&+T[$Q+Q8["9DR^?IM+HYW)O1+D)-; M'1-,89UK2+^F@#7]"S$YR9Q2S"R\[!^UAT%`>GH1>H2E2I@W:'9)UV$``)I^ M'^IC/3K%82!VZ*!N<@CB!ZK,`Q<>7J,D`_D(+:*17&6-"?I=H4O#"`_KEWU] MZ6W-1%H=GYR5*X7&CUU_0`$YQRAG0T&/#2-'?K\9`#:CRR#HR^WC,+R,V,/= M^=!OZC!"=J?UZ#Y/G-O1%4%S&+0Z(];A=OO``T:NN^Z#'C:B%NG6HG^< MKDO*G^IF?_YTZGZX8=T/#N:H2EN\V9_[+MKZ"=W!";I2?$+]^?-Q,9.1WRJ9 M`+_=*A;@K$\N;C&^GYGY:3KZFP'Q6V;FY^?@@\M"]#2:[-AVI,0>];$,E@?X=#`:]:4HP>[2S*S8O990"7'#^B;#F7EF&*? M-ZD6E/F'HT#3;*)PR:P>0Y]FT`):]L?8/5,&Z*N`I+4U";"35E[03?M'L<.(R_31=!]P6H%!;0,;G*3 M.8#$?47:U*0]NZUXFK[DK<*ABE^)5Y!$CLVS:-Z,2^98@J8;+P2:LQXB1B'A M"/(+4T[&:)K]@T8[J6VFCU9Z-]L61;+(/1`)84CF_8J33<]DHL6,BOHZ/AX,9&`GBY1-9B\Q?+2Q^(E2B[;D<3^/M:8Y>6`H[7ZW8:Y":?=/E(H MPM7L<;)%R4EIM*N>;.LNZU8=ZL%/O?BW5:_31SS-XLG#*/?\JQRM3XVZ*;-E@Q-$=)!!$",(S:1G@0<*>/`)":/&'ZOXKM-/TJ+%[M%=/`T#F!(EF'ZLXV"DZ?#,7:V*U.E/T*Q$8G@P% M2]HC@4SE7<=<7CD]*:@9W9I^:96`@IPI5M,:EN#Z.@O#KF=U&',H#.F''*WM MK%#76=YP@!:#85\L?%EMG2P9Q*2`U?ZM&0'+5%())3LRI-W"K0\Y@-AW&\,G M/,:3ZE$0=>!8R[7)GZRTR*H"?/%"0B(E9Q`_TO'#)$:Z@;>^F('_$O$R&UG) M]/!\0&_K+"%3\8)G>((@Y61&>&T!:/W?&(W;KQ%S-@B.9$D2GL::`+$Q*H]Y M]_I-C(*UU0+!P"=LKH&?T0_/3IXWT$7M`:N1=LZUS_P<$]I4*X36![EN+X[#G:7+X58 M`\X:+"1*4?1TJ^@]**@?9()8[8X50?&[A+>H6RF]Q^%:=6^SED])6Y-_CY87 M&!YDK1@(H`M'`?6WY@*#4U`=.SZ6DM0.'**8MM&)E*47?7H#(@O?^]=P',P= MX:$-M?Z[04]=2BY#B44NLKJ33#ZEO-"7Z?,V]3E&5FS*YR`&`T&V-Y:2MU31 MASWQFDZ2;)N-L9F5.@D5;6'+$1(-5_=3UD!!K83#%0G*H+>O,1S_U07NM$4? M57"YN@6?Q)WG"/4OB/:GK`V]4%D-T1Q7?P=R[E\OTY+WFQC)`@>,U?NI/-_V MZ6+:$4OF]])R095"5K`AU6`NGL'5GOE]:1D?>W%K4%T?9/W(KFAG-5N]I0ET M>4LT>LQ2>$LQLU*L0:LO6]G^3VOV+Y=H,.SWTK*C()=Y%<<^*$[-(](W1TB.(03I3C$H*N1_!R!L>`QTQ/-&M,:]UJ5VLY"H!@*80& M6G_1C2,/D[PZKE`(,.-015O[#34Q2]`0#%\0"!N]]-F2+1)ZH<9U]#'X?S,8 MHFL?:*\?-$&B0V=!:'>I3C!1(W"+S.3)NP]]X M!\L2&=[:4$P/NG5I=3YTT%P[7U+[C!3#0-\^.)KDPZ:#M!?!?\/>^1C6=`=D MC>#\/$"G,W@M2X5D"IAFU.M@V/8'&/7<80$]OQ4H[607%WIB65BVBKKEY@/6 MRLILD9^.PQ*[4PES;F9BAB@"_ M5N0U"'YSX5E,O,+2:Y&]\A1(.;0,+G%_D??^M;RCP@'F/"K_M6TL'O^A4MG;?R,`_I/,_^;:7?SO;S+_<#CKG,&V7_ZF\P_R?W7U;OZ_Y?SW M)`AGJ15&?W'\ETIEH^+,/\=_K]Z=_[[*GY65%96(`9U&`IFW('>_`AF\4E&K ME=KJPUKU(9P3'ZU_YQ6+10SP>Q,`U5IUH[:Q*0!6XG\H`@ M.XZ*K:!G4LY;<-1IMNUW-_1'K"QNTBZ"43A(?E;<[R$J`3G-]B(8`?,5GD4C M.#6:;]+(L=D@*Y,JM9N`KW!^UZ1XM68 MX8!T_:"+X6VDB6Z.FZ+YP-P$>*5J&F':`F'<>`N,#([J.&K`WD=)D13UY(J\:I79Z\0'O8Y-%QX,6ZO#0ON47V6*KU-;?6!++ MS1BCNX5\V_(_B2RW$P-F7OS'S4J2_U?6JW?\_YO+_TP""+_M/J MSI;Z'Q6J%_V?GK=N_`[SY_=^#U8T'=_<_WVC^;SO\[USY_\%F"O]?N^/_WX;_ M)TD@RP!-OO/J-M:H[;EM/'PUL]?21'2N1_QC<%6\F? M@N_WW$!4?OKVZ'CO9/]_ZT_+:]7RQ1,Y8D1!"PNAZD`Q@&*_E:-WY:<2D>/I MNW*9DY?*[\JP#DSDCB=I]<^53405\?-6L=-'=)_@[U+;[0XG\#]?/J.Q,4J= MT]FC%)O56?S_-J_^%^/_USN+_4^L"_U^O M;:PO?NN_OCGCUA_OLI6]S';NK_=+\:OMV(4V:C;5\/8#5Z6O4T?^$.W*$*+Y MW5P(]MY)_:"^>]KXL;Y[LOT#+LHFL,;&AZ!9^`'U*/UP/,(OPF*%@1(>PV8; ME:>H2?-QLS9WCG=?[I_"KS?']9-M5*W'%AL(+=E<[(U$>F_>(P8`V+X_N%D( M"MT[ZV\[3O*`XC?;0:RT]$D_MPQMKM9?-T\K\5<5=/AL/H:!^X"!;ITMS)'S M-()C?1%8F-$PL-7:?F0?\PUJUAS[6%M=75Q MWK^V89]\RROJV?,]=>8WWQ?1)!KEHOW^*.@J6&1J]^CY\"FAIV@I-1K/&(`Z^V]YQEK.SS%_+XB:P\X`>)FQ MAX@!T:8*"`_QTNJK6^HZ')//FJ%5K$;+&M1O+`.T7@@K^AKA=,1L0RR(4+5: ME"I?'+Y1+X)^,/2[ZO7XK-MIJH-.,^BCEB0TC2E1FU23:6^$&M/&9DN)>J^6 MF:NZ#0%8`.)"(#E_A)@/)7)0GNQWT&[75)W:?]M-XTN^'0ZT6Y`1NQ=AU>#S M<;>`(-!CAZN1*QJT/V\9[=_@@SC8Z:`C<-2(1M_@?=*^1@A)+5L8V;E*MDJ= M!&1T@P!FC/$Y31.,8PL5UF'GU3W_&:96K$3(Q@DVLP`UF97/Q[6YT\<"#MI5 MBX*W'8SEV_=S;LM"[@ MYZL=M5JMK#TJJ#FS%5Y:,[3W=5R2%HWIDOFO3X\5S(.?4I'E*+72Z0_&QMW^ M1#G"CP.C-=*PE"B]I&K2Z*%1U460SV_I00&>BZY]HK"'=.A'Z+*F#6MF3/8` M'<-XV??010$R+1*"`!9ZXV'%2\']C M&AL'S=@8S")US$]2NYCFNH1LK#^).E6<"-4$P:DX@0G^0IX4U,,DI:T;)S>^ M8&R&7BENT=0ELA5OW*)J,](6!>5^Y"+0-I,FBLUFK8@7%`,/;\.8/^39N;R& M+\\]=OB-"Y8X*#K*19#;T[B342!TVUJ1&Z`?#?9(XF^9OC5UD=UC;(D1D0%? M&P_1M:A>:7U-I9D8/0,!'AWOOU#WQ3BB():EE!A;J[PW,83XDO;)9+2O#9U< M\,11<`OW(VVFVF(0.=J[Q.CGCV!(-LGDC8.!8@V4;L@2/$_&'8PA8,40J"TV M*R'7.6Q-XB*68SV#[C4UP$'5N$6&T`_[16J:T"2VQ2X-D&V==X(NFTH9J&3C M`N=?%CPSL4'J!Q<4*(D\?%GR+C[Q6RT0:0OBG`\-E=#CV+7MP^[.P6YC9V^O M?K@'V#6'(;L?8O-9-IP-,;AJUV\&+N_L.\/@#CD*!H?UMQ-3BFF)&;40X@/' MN`HGO0AE3#!6LG'M!COO!#4!RM*(IF4.`*D9E#CBA)7%=M.V""";,FAFV7[B M'QB-,WU1)'>R*7Q8@ENQ22],5E>F@6RX:=G*>`>D.Q$F$K.M<,64O47S M>+2BU@X;I=W+(4IN"!EV5P:`#0#'#7&PT:I:@J8*$C1O:%P5^*WT49P[:B0; MB8K.WM'^:>XJSS<42J%3AUSN2OV@_E\[O!R%Q2>M:-1`5S=Y]2?D4);DP#%0 M*@W5&R&92TJB".O8.AM"E'HV*EQE:CT2?YEUV$:74:E,HD*AQ"Y2O4MNS`R MMLI-L*E.8D-'E*O48#H+(V.K+(B,#IDNN?X9CDA.:GV:6!7$.`[#2]5%ACQ% M<.OTX:3,DMF(G/F,!\Y"G+W=?TH(91/4+C^1>?SR*PR6(X=\7/U4D%\5\ZMJ M?JV97^OFUX;^]?+H[>F1RATW]O:/UZJ%A$]5Z#0OM?)<]ZL\D*N%C)J$P=;@ M[<[Y:#8DAE%-A4'!T7+HO@]M0M'Q^#;3<4%5R:,A!CT!Z`QC+1W(&1PB$$XJ M%ESSW(>-([7RH-G0$0YG=F/62``"@S":/YY&=(*=O--OH(>Q<]CG&U"?9(T" M`K/9MH206R8IO!>+*=@PG&RK,URK9E,H@PRX%Z8,D(>F#*L_ MQ#"-#9#.26J9!E&&]>I<_A22!"*[SCR4YL'16]1B<(A<\H54=WU?F]YOQ>=WYO.+\W)Q;SDK$[818#Z+L..U_RK"?KU[_&\FB+@3]DW( MFN\MO@I1[^V?O"9)Y$X0F2#K?S=!Y#^-KED2N1-$)@C[WTT0^4\C;)9$_I,$ MDH_`CHR\NYZH_[O;-@Z.JLR"N(Z-:"?'ZTF[LJ4.6\ M^JBN2D.^EMW6+QODD9JO<77E9SM[KW9>X"/*_MK#3?/E%L$,5>$.[(ZC4=A# M:D9*0%]WI78*2L>G/[^N5VG%YDCCMC$8#0LX1#2B?(.L[JL< M5B@^X6ZXXW345R>[1^B2\4JME:JEJKACI%5C_?=>D,X112R[#%4)GT_B"AX1 M/TJ:ARH?7S)AQ($LZ8T0GV^#9HA!3?JDN$`PJJC"H55%R,E@/R0?NZ)]02_! M]-[6O[8*?_SJ9B[;]5"=OCUJ[.V<[C1.ZKLG"5T64]=7)S"BC<.C@Z.=/?4G M?ST[.3&**H[VG@\\R1_RLS2^7!CGQ>AM&9\4V<>F@U-DX74BI=^8I;[3\`3N M4$.R&OLGC9.7.\?UO<;!_K/CG>.?G:[L+5V,_7+,<7Z`^((4&='(+7]YGO4"FRQ?VI^@N7.PDZ% M3]/Z(=NZ!Z56HI")UD!"/4M2KN$Q&`X1(:M;H]]R^5D^"L@W*W"CZY[H!NGE M$6O-00-;+6B?N.0D>D1PW+FEGFI\&(7NM9YF'G/V[1^?8O'&/O:[`LATB0.F M")FCCE)!!5?-8""12J#+4*&#!="'_67@4\PC5(<*Z-U;`+W>569G)5J+M([L M\_V?7M5K[M"0[@11H@Z?P(&WH"];[/>;5`GT`%E4R7&WW@D+U%'L%T.%U3:> M5''2J\G1FY!W0F*:\C1BF"5L)?+>_3$C?][IMT#:GB52`4M&>GJW56XRDY5] MMFQ]"KTT&J(7;WP#%`TFTA#"=`J?2Y$1W$:5#\4QQ_XGRKJ\<[GMYPF4%%"(Y=/]-EMWNTBS8T=2(07[ZBN]OV,L3&XPXA( M>71FCC14?#(NP2>NJGXC:O;'/8YR%D?-=E-6QS;T<18D#NF5WO7I\[+-\Q(; M:2C,XRM[!/;3*IJ)HM<"V.9<*,4G'WJH@T!IA&L^@6QF-DY]?<57[K;:I MF-5+[KRJQV!B0B$!,VN,BQ+7D7'PRD&^03B<=_T/X7@H MPH![>4N*,11L.!RB`4$G$I?/YO3HEI:X\S/*`3E\8.C#O[I9,,8GT@F!O&Z?UGT[S!:=E M$`8;6&CWZ/"T?GB*Q3!IYX"1P=]:%(2?A&.>3F]&F MABE5-J5\8,=^BV/AZ.S*AI/;\Z\:%'TRZ,?&K*K+@`#=Z0%/M*%"!^%E8*&) M(DUW<[U@?LLQM*'30&K$?)?JJ1PJ@23KZ#2L`[\GZE0V)^OH-*R#OS4E_9/C MV&X-H[B:^&$X"K0D*`%702J*Z7F3WMYH&/AHE>)')'ZA!(.9/H:D[8*8;!7R M/N+FTFB->[UK68.%2>Y'V&`YX+[-]PVVCXQI]4EWX!C6:5I.E@+JDQF-CUB% MERMSSMY[+E10#1=:[[W`,UB`'#H5!P(XHQ&R,='8X+$"Q30#F7-U[S7^^\TK6/D[SP[JC1?UP_KQ_B[+(?G"M&*[1Z]_GE_FN*YR MA%0_Q"F>7I2L<7_4I2WRL\`#`WMV!&QK#A;$D>:6>GN\?UJ?5P@XZO_,*[/W M,VPT.'[2[]8UGN";+DO%\V[CY.V.5"GHNY<[@\I_??\_Q@#^O[Z*_2]Z^]R< ML/]%_^]WL_.M['\-"23-?Q_-+&:JTRT_/#^L9Z87WCD6,#3"F;J\;O MC,2,="1[M$(+HT?O49S>2B_2#T9G40N](DPO@V"T5$[R_F015W"?`:7;Z8^O MYI6Y[E\UM%>(>>6<-E-';>/!:F'CP88S:AL/*I#RP(Q:AKQ0P!B02PI.B0U* MP98RGBOXC!YS9H&E,/@B>:M!B?2D@R9\'-.3K:^[>._6"IHHG?;\"PPB-\9+ M]@@O;M2E?\V6*LWPHM_Y@QS2X,F:C4G>=^0:T\#CP()RM7.W3K\B_S<.7#K] MK\+_UU;1YY_A_YOH_Z=:N?/_]L_@_Z?33S+RA]:%VVSW/VE5-V9[?ZNN%RI5 M=P^@E#6[![`G%?*:Q:Y4;-)&,FF6!Q93YM%FHE9O\^'[1,I#G9**=+7RJ%"M M;ABO=<0HU:X.4<>LD0Z3='L?#?#]"]^^PF6\,0=1&@/-HG,>,8!O*G'(0[=8 M\+=VPM.TKHGXB@[^?8=^OS*.`R%E^PXU@9ENKLL/Z'M31>,^^F4%-MT+*8<[ MJNQH0!ETHH.A7M^W@RM$QX^NL4XG"`*!M6IKLB>=IK(^=`0'&DGY/79^^P., MG9=HVJ\^,@6&T>;JZJK^BC#$IWR@JY^F$L=!!`")I%I=A1G8-$3RSS0#EN[^ M$V8C74:I@D0"T^/(*-4JI#PR$Z:]2-7TH&+B5`=92KG+NQ8;[J7<_N'NWOYQ MONRXAYA(-:XAM*FC\0GAOL/3L\*E/V`/Y2X#J<6F]3/:5(NTJ33!T`"XM',5 M@P\D2A/=1I#DA\JT80MA>EF`M)/IZ-&J<=$?I^>4\$;ZW9T,]A\A_W$`QUL. M"/@9_I\?;-[%__J6\W^K/J#GW?^LKR7E_^K:G?S_K>3_-!)(1.]:79UQ#;1( M_0>UM1OX@JNN&E=PCO/A^Y-.::-RC\._C?N>J M2"H*V2AH9;6W+'W1S2%,C!-=HP)'#GFRNHGQ*[&'GG(YD\ED;=04J[>R^W#^LGVRC9%-L=4`BFP<]*O]& M_1CVRNC(<@8VXI,9:[S+ELM9^7B77;(?!(J^G7'4P*H:6LP[,Z5:1\@==.8< MFY[):;`I`O(_DO_#CW^.^`_H__EN__\F\\^KH/P-Y[^RNK9^%__Y&\__*!`? M\W^U_*#C> MT;5PKZ5ZK61..!Z9]YKQ55'[?12;5LJ#9;>>;A4T/^05@J9NUSVNWQ^1L&F6S`% M.W\4GA?U$Q#^QN:Y((T@&P-]QHREOW&N801VO2YCQ'OV#\27''U:<&[/J>S=F576UL&G?!+\1SH*5GHWOE0E6]1F72E+3[W:I[S4%K*`? M7#YYXA;!_Q:Y=W)0P8?U?NA1^"8N>\V&S[_8N@G&'2*T]< MX7S_F?=6IMYO_)RZ75;-]'LH75+*X5*;66[!FS!;O/9NJ5Q3\-?%'+@P0FKE M7>D==(BVC/+,TK_3#W=,R]S"]"KJ3[K"6HX*[WY[]PY;*A26?^=JL]!JMIQV M:!:VI@RZ._#WX,_4VS]=['2O_IQN_HI[KW8.?VZ]O<*%9JJ9%?ZO&6`>N_WCY28XP<07J MC()&KPCKNC>P;"Q^%-I]_49E<=O,ZMAY['^T!1 MZ55HM/HX61+7;[L\R,8&[$]G;DP9W MFYW&8U@D0@-_&1X3IZU*87/M=B,$IXV@;+PB2')DY13,;W8"GC)*IJW9XW3+ M)[R;'=]2A!XU0^KYK1S]9D2;;1)074$'\Y(B[63,8QVNK0EEY7>5+QX^[^@I M,-Z5]*\J_)QS5BKNZ?Z2**_*Y?F2_Q<><6?K2^AB^M29R'3'P[\812\*S7G#J@4+86H`\P_^:I@6H7,4FYW-T_A;TT$75)J M/7BS5Z??+^54B[]/S6\#74V_Y5C*/=L_.3K,S[VNR)QU,,R,E-=Q?$.U]-2T MJ/&I ML_`I,[M=G*6#^D\+S-$Y-*2H<./H]2DP$]-Z=R;50XEWI6N8(_QU?5V:?X$0 ME9_8NB@5XMA,`CZ MK:CA.-385I4MP,2FZ.WF3GJ_]?-?MW7[ZE^?H?^U^:!ZI__SC>8_Z(V[L$?Y MY6\W_Y75C;7*W?Q_X_FGLT[TY>I?<_7_*Q5'_V-S%5,V\?[O;G:^Q?U/"@G$ M0KFO8BCWM:GJ__.KKU?F^(*H%""?/[]7)[O'^Z_9]=DVVJ1AVM&;T]=OM.+5 M=I:;Z]>55:K=*9_O?.BWCC9_]\ZI?$Y7QZU M=/(Z>9/'C,.C0RR_UYB$1_GH[X=TXK40D\2V23<@$]B2&CWF9?'V(`U9_R'F M3"*KDLAR,M^_:!V+.`[:AT,*'JZZVJW@<;>8_FWX_RCH#;[M_K]Q)_]]Z_F/ M1G@_VCG'@]I?N?^KM8WUQ/Z_5EFMW.W_WW3_GR"!V"X.6_AF;;TZ1PB8!P,D M@9O8`:X;-?"H_$OVW;M?R^_>_5"^X(0E^.B_>T=JU16%E]U9^KU$>?WLG1>A MFZY_<0U9"GI_K?R_7MVL)M9_=6/][OWWGV#]6Q*87/T;"ZW^J1"JL/QGG@(V M'A0V'Y@GX'OJI#GL#,C%?F_0Z08MU>F7K+L7O(F4!UMR-/]_8W3BZO=5MZ4B MJLEN6G<5\Z,2W68VMY<3K.3[&"OY7E4T)_E>+1E&\KU:UBTW_9%Z\B18^EA_ M]>9@!Z^12?#^5&JJQX_K1\^Q#%[,2P@3=M'F/I;^51W+%L^5GH6N8<+7R(6S MGXE\ZC1M/BP\7#?3I-1*)Z(WSVURGLWML$-R]%+2Z/3/PY*$T`XH,,GV-D6B M4>03GNZ*S\:=;JM!,>"'X^8H'$:Z4!X[IZQ_[M]Q=+)+43,+P\&C`9,TT9VK M\>];7-/X?Y^-S.>V,YQHYWOITRBX&C6&@=]JA/WN]>?"/^M/;8`\[C5:`1)* M8^!?!*W/;236QF?"8!"?M:_/5Q3%DD,WR_%M?^%XYH0>ZIPXXG)P<>LZ=B'XZ$-ME.'P?H>KNR8_' M:Z4J11F+1S8L,2@./"B1"B,L4Q!'U!2(#>,;4N@2$]B0J^W#L>O4O^Y"TX\[ M?O]I\_JB/XY*<#Q[0B>V41"-5/$/$)#KAZ?'/V=1[*1?VXUHY`]15Q:@G)J` M9]'X+!IU1N,1'?KP'/?!'W90Y(OPFZ/IP)D/?8(OP[:+9534#KI=AH2Q%'6D MMN!JX/=),Q/S]@_W3[>72YU^9Z1JZJ-:R='O/&S>F/T<\B'['-)T-O[F;#X7 MF@-@[-DHEUWZ&$OXE,UCH:6/!_O/&B=U?!1K[.T?GWS2EW8/S+O4M!G4VKWW MU-Y_JSV0>X>=0.5:_WC:'`U1T33LY?EY;9$!OBWDTPERP[6#/:GODMH8G9+Y M)$+",,"C@!T@ZAR^N*_PC>SH>>-E?6>O#J!QO'$*R#]GK*">HT\,2V$"PLM/ M+4YS9HK'LP-"!4Y*JO1IBXM\X@,.$7^BM'[XQ&!R)?4#!6EM4OCAO&#\O4:) M:O,"RD]IFHHDFZ;Q.8NBU.%AL'EH'E\?Y0M:YFH?%6G$"4E5"E5K4/XEDY`< MY2\?QIV#_1>'N:6/%(*4/O"9]%-\#">F$4^A^4]3LUNQ;)F!Q8;^_F21$F1J M-,W3[J?\UJ=;G:AT,_)'A77WJH@Z`PWE[>?NT:M71X?3.D>Q[JAC14:UF"A3 MA"]D?9^FY"'?TWEHH7P&_Z@-1;:WZ5]A\%;^*S5=QCLU7M_676GNQ?I&V8_I^:OM_M9W7@VJZ MG=>\\:!\B0DL9E&7G6X7X^CAE2R+@R\.W^R?O*026.8>MHZ9: M,ZFHO`7$]FZ)+0EG%BSNL8(E'!2)G%?9@ M5T:CJ_G%6K.I:[J-56PAT&R75I;*]&-;9GWV3`)GE2>)4M1VOV#?F;+P8FUV M6_BF7>QVT+57N1^.BO&4?VT+J"@8J:(/;;H#\P\7__)OO_C%/W:*_[M:?-3X M%5EH`?K.*MBTX`X3S1(^ZK1 M'WAGU3A22\N^$TM7\=F-=51"WG5;#6S"QRNLQM5YP)'),1GYE,U#\Z_8/%<7 MAZ0Y70S:5'#:'XSEG`?[)Z?JW9,G4RHH]<,$NH5YQ2=QFE%E-2W'&?1X9OQ3 M2W!FLS^]A8XLG8<*3R_F^N M_<_F6E+_%Q\`[\[_W^S\[\;PF]#8G:GW-Z-FU?J-3;\=7']4J&YL.!I_\E`" MAT2ZW(?SXJBM`A6%:AG;475=/OP]$08[JU24&`=0I>U`]9*L-CF19- ME9';XY*(6OK(Z9_@5[=S)K_LN0R_W!,8?N,>\4EEEW*'L%/\B*&UG]'K09ZL MD*#]QE[]=?UPCQ%(;=S_8*#Q\$`NC>K#70,\AVV/\B#^I M;2??V!IC>B';/3H\.3U^LXL//MM8#8Y"AL/$%MW21\=.\A,LO[SUE;1<_DW! M2;"U#$*O#M?6OZ_&`S#\]MV`?(9\9_6U^_\/WR[^;_E)^!Y^S_*GHG]_\&#._V_;[3_ M3Y)`8B>O.+X[)R.`S*T][QR8B/WS<,'8C]3POVSDQYA[0>O;.A:,\=7/.A8C MN9V8593?&C.I)9S>W85DO./_:?R_'0Q'?Y2:M]7&//Z_NN[>_Y'^_X/-]3O^ M_RWYOY#`)/.NSF']4RMN;,Z\_7M46-MT.#_J"JXYEG^*X[HI_4*3>?F_C;?' M1XT4FCX89J>UD_/OU?57E(:4$?J)[9G5*$;RXO M^J,&"E7`[XQ8/E+"%M<7*M7$S@F].CT^>$-*] MR%566<^WK*9`RF^Y8T0:BW>KY#^,_]/?7XW_5RMK#R;X_\:=_NPP.\G\S\Y;F14?_C9-7B6V@MXNB'MC/QS/]%OC! M:N'!`W<3?/!@O?#`N:8TDH`U_H^N>X,AS/<5V@/9C^^WU0I^%9\0'MH<0K;" MYSL')_4M?>I1&*SU1;.I>D"S?JNE(M05ABT=`)R%77*]T0ZZ`W71.E-\]E/A M>&3,DP7XBNKZ_8NQ?Q&4E'H;J$N_/\*JG8L^NC*F:+`%%0$IXVM:+T#)(<+D M:P.@YT?O">PP@.;/QWTR02M9BRC=$0XA*R,P&O:;O4'.=A>(J-%H7/3'#>U7 M)%M0E0V:K54]%$K]^:>:4C=9=9VK&MN,Q##J^9#DT^,WF'K'8/\5]W\.?/E? M7VG_5^NQ]S^._UZYV_^_Z?[/)#"YBZ^OSM[^I]7;F'GGM[966'-Y/GX_M/H( MLI=LV`X*G_K^7^P6=F\F_]O-_\]QQSPKY?_8+4G_/]400*\D_^^QA^. MS;1=/*I^YWWG'3W[;]29?/>=E_&'%Q]*(?T\\R,ZRO M:.`W`YT%YU>Z<;"?$1RW_:Y\7_DCM%_57^[OGM_MADWY6JKC")3@LX;(-)NJ MN%\JE?6MDPUCA3&M'F-9O5RN2[Y"]5`_*8C=5A MO;[7B*ZC!BQ7-%=2%4,`+.UE0#*%H,?O%/K*;;JFMO[$^1_\3I=\SQ:5?Q8.1[`VWO6S6]]YE(_OY739?SGLC()< MI8`@"OJ2!7[G\:;_$RX.6+)1,,)+;5.IO*+ZH>*U'*EH/"#KU4Z?W7'DKH-1 MGBZWJ?ZEWQD-.BU36>Z7BQ5NX&X&;W']H].(?X[S_P;&_[H[_WV#^;]]]T_S MSW_K2?FOLOK@[O[_7T#^`X)Q)#^1PZ:XVI'<69)A5'[Z]NAX#SW-/2VO5*;Z79H_(UY$K)];_[5[]+++^*VO5C8GUOWEG M__<-[G_P]D/IZP_GQF._%+\,,5<@:")^D M?E#?/6W\6-\]V?Y!>PUN?`B:A1^,OPSXHK97$"2T/FRVQ\.`&S,?-VD-7;[N MG\*O-\?UDVWH!/GF:"`LMR'G7DSZ*K=2`P"H[Z%L,E;O?-#76'9$Z,+,;[8# MIYS@SQ=K0YTCCH?U-9I[@Q9=]W0%"A(AO]%UK(8S,I=A.(87@883#0-=O.U' M^I*N2UYYY2,@7\W.;\S5WUV=@Y-!CJ3XPLT_*P)6&A'C6DHN",<4FM-!J"A> MJ.RMFR:@M<H2SG#HV+VH)#OP^I3MF[9?TE\A]/T.VI?\[A_VO5M?5*@O^O MKCVXT___*G_@+/[L^9XZ\YOOB^A?%^67_?XHZ!KGZAQ]0^7H<$[^R?NC/#E[ M`.%G<#WL7+1'J-NQ6L"_*_1WE?Y>H[_7U?-A$*B3\'QTB4[/GX?C?HN='D%+ M38;T=M@9C8(^&E=9)^`E9`UDP44ZB/#O`)U1A.>(SA\ASD,5#K!6'A"]5EV0 M(TW%U%[;SI&K>03;#@>HD>BC`8/QQ3F.@O-QM_"=!T75V_W3ET=O3M7.X<_J M[<[Q\<[AZ<];Y`P$51^##P$#ZO0&W0[`A0X!*QY=`][?>:_JL+5"A9UG^P?[ MIS\#[NKY_NEA_>1$/3\Z5COJ]<[QZ?[NFX.=8_7ZS?'KHY-Z2:F3@)0DO_-F MC.HY30N,72L8^9UN1/W]&:8Q`K2Z+=7V/Z#R9#.`+;BE?'9P.G>R4)8)08@G M5R+9E9* M.AJ`X'/9!'@2!3`53D\CZ%L33S@-$CH:[+N0O:R1H$8NT"@/9W;GU8G*Y?!` M1.K50$_L4I!9/HQ8-^B/U`K#@I_#ZV01UKLE!5[X-Y'[^O28`C1,5&*Q2:UT M^@,0%^4S48JP`@+&$I.XT87HR@J]*#9Z013Y%P'=9G[G`:]\#K2'>KNHG!M! M0Y=M6`/C"$]_'<,PD3P^^-TQL!E@1G;!D9]Y8G<:3R1E'V"=!\,`58*!MGSR M00QY,@"=R('7&44@A"E\Q"+.@8CU`!2_4#@`^XM4+J/#?=^L5S3/0&`1#%&L;TB:-AM%U9KM=_8UCT(23!AO? M`ML97A,8IC8B0<"`'!/A@`R#_QO3B#@HFI[/(F1\YXE3X&?9'G?XX<(#022M"_7*-*6GQ0P>+ M3R0A+^!,H`8@VK=,L9IF@&03RX5(!SC2>#C$`955TV?*R\0H%(CJZ'C_A;HO M>J48`0:6(2?&5AWO'5@_OC1A>X\"%EJ2Y$]\`;=5W\;U1`"Y$7O`OL:]]H]@ M&.)H8&4!B>51SL`WSU:>`M@P=H`1UJ=V:*%#KV39Q9'*\?MG]YK`%Q3NX]P> MUN^'_2(U2P@2XZ&K*V(\YYV@RX%H#$PR&8$C*@I\F=C0](,+F($/-#H.V1:? M^*T6")(ZGDXG(J^F*/PP]KL[![N-G;V]^N$>X-4$5,Z@]F7<7&(8#+I^,W`Y M7]]TWQUFW*P/ZV\G)A'3$G.HZ\>'B[$43G@1RE@`@6NF#3/A=Q.T`\A*`YIF MJ9&2MDS!/[AJU':\@+J?-E1NB!1M6AHG^^2N,X5_^MU+_SI2P?DYKJ`/09<& MG4U/>"RX0=EV>*^BRPDF![,18+64O4#S92#Z'C']LT"W>3E$V4DB^F!U!%Y` MAW$PM!QFR46`YJC3CP!\*VW49HX22"FB%+!WM'^:N\JS\YTKJ)?+7:D?U/]K MAY>CL/BD%8T:^/"(+GMRG"4YT;`I.?>IR;S-,I7REEL15M];XQ'V(%$(9XQ?!\'#"D)7>L]U%L=@D9IAXKA^"H88/U- M=#=V2E_%*GRBO\^`2-\3:MQT)=XT".EPAG/;KFS>J'%;?)'6J_'62<1W&\<' MYQLT;HO/:1PHU!]W1]PZO:`KLG[+?'+HF!;W87BINL@BIPA%G3Z<'UGJ@5?]OR/JY\*]&]%_JW*OVOR[[K\N\'_OCQZ M>WJD""45`ZQW[@/C3JTZ:.+4 M\%8YJP/31P`:'X31_%$4`05VSDZ_$0*]G,.^VH#:M*\7$)3-MB6(E#+)0US! M&3^VA&P8<7P*)@@EV^H,UZK9%$I`!=)%*0&#':#>;5 MN?PI)`E"N/\\=&9#T1O%(E"(//*%5/*`X6Z(2,>+^N,#662KE57SJV)^5B&3N?FZI#HW68FZSDW6WD.IL^ABH\(W7%ZZ M@6^PH#(W74H/LX+OS9<.#\V-%@O[!0$RYWF[T1*)U_V,A2%3.;$47.)%S8"O M0[R5SR#>RN8=]<:HM[+YU1+P:)^CKD6_T,\EVKWI%OC'Q1 MB/F*Y&N$C,\@WWC=OX)\7^\>_YN(#NX$?77BY9/]7TZZ>_LGKTEVN!,=A'C_ M742'_Q3J9=GA3G00\OUW$1W^4\B798?_!-$ADTZ^G_1S^2G>3OI\V\@/5KZ\ MVJK^N-\["X9:^T%N]$4MDQSTYZX*5#&O/JJKDD1TV];W]/BUA=>HNNJSG;U7 M.R_P.6!_[>&F^;(%,%E5&.7=<30*>TBM../-L!64V@E4CD]_?EVOTCK,D=)F M8S`:%G"0Z,&![]%UNMSN:_3X9E7=5SDL7GS"R.M1.>JKD]TC]:;?N5)KI6JI MR@]JO!K\*`IZ4'EH7$Y':G09)^EUJ']M%<#XC4@NG?7PG+X]:E!L MA9/Z[HFC'6%J^>H$1K#!`=+5G_SU[.3$*#\X^EP^.?Y8.[`)G0/TO MYZF*L&-%6X5*$^R9#4FX$Z7H:]"=V\0[)5[+`\.9?%2>>+U^9K4DT!*>9\3H M/[#2&ROLZE=DUC[QZ1TKH%=O!D8PSH=A+Y8W\7KJ9NI7S%-\GP,R"%#[@^"T M_>9[U!%K=:^QT_PTR-V$_06?2/6#*K4X,DI[4611H65Y*02@'$TAC88C'2FVY3XC:1B!^NLH(*K9C`8B?Y+'XMWL``Z![X, M_/?40A"T`GJ%)3"O=Y79"XFR(M:)?+[_TZMZS1T0>J\GJM->";&OI/JQQ;X% MZ1E;#XQ&LHL$HG>O`G40^\,P83V-XRHR>KTX+_7RYD4,4)X'#.N#38#>7S]* MU-B,A$*AK93QE%=1/97;*C>9R2HD6[HV/KL"<'3HB*];H@5#6B>8GL?G6$0J M;QM4RFD`Z+RA!RFG"V8TWZ8_P)T=_@V%\0?^IXIZ?//Y+0,>G^8U6OE83]V& MW8[1/-BA0UAN]W2E[V>,A^`,HR"ET4$C4DKQR;@$G[AF^HVHV1_WV#NCBY3M MG-#^-O1L%AQ:&UMI'9X^#]L\#\[80E$>4>'SV#^KGB2J0G/QS+DPBD\^]/`5 MG-((RWP,S4QR/E)`KFZY99Q^N6^AS.AYN_ZUY$BILQ&^O\VKD/#<,LU\BBMV M6E$CJ5,I6A@K:&DFAB_,J!N#G!]7&]N*VT$GRR8>?J<`%P.5N=!7-3@+!SM$ M7O-.=XY?U$\;)S^_P@KV2VU#$:W'XMKQ<`8[T?N8!(,ADAPX^%EPX&2-W4CB M6LZ"5$YG&]3F>=?_$(Z'M"6[UY:D4H$'&]@Y4*6[@U8EHU$WD+.76[8=^%AD M:FD*'O5RYX1%5A!SZC_5=QNOU9]46^^V7?\BTEHN6/A@_[!^>`2E\6.O_NS- M"_6GR80Q/)$L#%-U@!]O7S=.ZS^=Y@O2(@A=#2RP>W1X6C\\Q2*8M'/`2.!O M+7;!3\(M3V(L)=Z"[I&*"N>X0&2;I,V93Q@4GZK08KJ%!F M90ZZA!>!EH.**4T=U<+YC?")S?<--E5S-+JD&Q0"T_*=%$"?9`P^8@5>@LS=>N^Y2$$U7%B] M]P+-8`"2WI3V"=S4!DBO7^.!HCJ*0P8JY^ID%W+#9NN.V=JQ9J7*L^=[C?]^ M\PK6\LZS@WKC1?VP?KR_R[M_OI!>:/?H]<_S2AS758Z0Z8[DCQ`M]#W)EXW[SF6=2GV?VC]A[9_GVGYES!6N;/^N[/^N[/^ MFV_]A[+?=Q[(^1AK%B_G3YF%8\Y>G#?+SY M00NJ84=L!IHH+4+/T-T!WH7*<1(MAA40Q",D@D2KK.RLT?6%##5&05LU@B!54EY2G/P1=6!!X M68Z%%6E-=X.HA$VA`P:@RZC+-^EX$3@`@F7MZF@YHLX&$5JQM8?A^`)O1`4' M>K$@1?)NUW3&]!(*CV"PH!52^'Z+%A2^X548+047!=+3X\K@NAD&-T`[5+IT&`'6R`[\V%X:TML4V5'<6 M*CQ^S-)7<(G_8G]&V'.L)1T][_3U.?S)$[VB`MM/9$4`'W<78AR`>VR$Z%*3 M38PN"2F9#AGH$"]K?=4?(]G%(*+QE-">`S6&#EKE=%/=[I,1+&67@#]^+#A]M.K87#^T5["?`+NQFG/"4KTJ23# M=(0[W64'-[5.'Y]7F6:#;L#VI%/Z)U:D=,V.CH*[0`;D;1A7O!2F:R%ZQ!HC M;Z)52;]QYK%WG9&9+8.&ONXB)-`64L:`[2([_0]^M^.0-(U5C&1UQQ)T3#'$ MV3X6T\S"Y#>;&)`&IN.'(9^U!>#.)RN-LSU&=H>"I_12T93%`QE M,&1)`\85M*"PB"N@RNH/F5LWPHM_Y0]@Y M/<^?=VS;T]#6HPI(#<P#R'))I`4P3X$:Q_#/BG.S6`.V M^139/^?Q[LT[\'?>_N'17IT]`9D+$U50LA^;'[`M'^WNP;/_Q MXRM8Y4^>H-/O`-4"9(V>ZF>JB*U$>8^,Q!J]$PUH];N2@F%0O.4P(9B5RZR$ M]L5K"XLL7OMC4D<`^40:/!\/D3^@+1?LR%CH*2ZDCR1V?>(10A!^-PH9SJ7> M"'$^9'3;ISVD@M!2>LNQM-?#?&V?95MA2+3Y"&BD^,SP93 M#2IA&_S>0+?M#=T0II.]M7)3;H1-CIO'ER0'C\2G14O]W?1B`=15S9;F][O7"[.++*6.A6- MYZ].%YV.7&IW?LD!"\CK+&XK_^MG3@^B\UE8?O8T?5ZG[,1]UKSI'9DV.,LO M:?JXZR+KX3:I#W-;3J/@!`/"@B+PX M;(VU;I'A4K"JFTT8A.3A4;@[WY/@%0U;P1*JR!VX^8B].B%IHGI#0=06<-.) M]!$>N!L3+(A=D3Y$L8H4EB)3?A;>1[#+".8\-DWA?3W@\6$(A[46OH4T_?[R MB&\&0CK$L.H#G:.(C+"&.@M'[>^)(98"?$^GPP,_(:+]<"GVP"@'->>-,9Y/ M[@JG929>)^.9P>S<[O2\3A`$4S/[W=[4O-!'-_S3J\S\:8>NO M('74Y'U+>U!!PMSBB[=`9:5/6=8=,Q<&=.=Q(==/T$Y'NVTXTX%$]>O1=Q[5 MI#.\M#-!D?*O:94?IZ$>RG(1K1DY1M$3)D@+OIJ`>A:&L!'WJ0X!:)QU+AJ# M!8#*NSC>Z433X7*I1AKX'0YTBE5%7.$G:5['4#>X"IICUJ/$(PNM7CS)%K_S MC.87GVP/CQKDZ!./3X\?F\=X_"R52H\?[S5>[[RH[\DQ#=##EBX!(7D;;5#+ M6T:[=2YRYA4]CA@I7O$U+R.&;^]QY,PCO4$.PQ0>UG^L'].#?0J.TI8@J6<& MZX[+P?G)[]_#5L.2`1M?Q"IWQO+,4(6 M[1[1`J`G?M/BP&\YK>(U+!UEF2<+9:#"&S\KRM3'H#N*`UMQ?6)NH>=?D7*` M%<5->W0G,!6Z<9K!SB7B2@BF`Y.Z!\,`KUX<5US]:SW<$Z!AD^&:#=)8:``T M@ESOC^BJ%.O3,2JZ]`>#CGA#P;5'QPU1S;/;I=5>Y%.&NYGI",$8%Q@/YA.[Y.!@%Q`&(5\7&Y M8:DY2M!\U4.RB*!+_W,5?O-%R MKA&!X/3"KA3)L]4Q7RS[RKV(4BMXB3HD!VU\`P,E)R14M0)CTTC>8_Y"!4"J M;4#??\TG?&W*`)WH1Z!TW"[YR;VD5$),`I"`%D`KKI2U$&HH`FCI.S;QO"%2BQ^M-H1+-/K\ MX=XZ3.IQY5!I-8^G_MV=4_HH<)<:L!?#+^C*>)`OQ`N02#^$TP?)_,IX.6Y.LAR>O^[/*-G[GKEM=7G@-"3[OV1.FG'^#1'I4J!%_= M]>1LP#Q,]BUMX!F+G>B]\]3$6A@H6D]2RF2#,N43HS2]-;?//CTC.C9'3=9^ MG-&QB?%.M%1`<&3Z8)L\AO4>.\.)[!TTTSL5H^;4"9S6:`%]?Q;4Y$WHS#^X M\+@V<_$_`EHPW`/=B;I[H8+\#G4G!L/.!WP@9E%VYD)`7<6T54"+&V`U!!;K ME0*\M-40*ZA'A0HGIE MF)BI]'29/@EZ,5)9_IH3:6?&U*.\R>-^DVOC1[Q#3@GJJZFLDT`1B^B MC7._TZ6C:-CK`:M)$LQD00XK-[T+S0&>>')Z="@07M^W,2&W>DDF[6 MH=,+[`JQ^PR\'KD8M>=S!!%.PV%7K4#;A9LU`]6`KL?]T0+X87F\E&E=.:<. M6I4TFE/I(74TZ.=@&'R86*5V:F,$,\DSN>-8RDQ(ZFY)#\!X9!#+P3D+3A3K MTQ8<"0/7/:"OQG@PP#M3O-=+E?FH5#('WW$;J'=R+0:%R0*P6_1'4_($+%X" MIDFBXK8;S7^[C:Y_%J0"`)87]"?JDAY6/_#QTHV*I`$GY%O!V?A"(TBC3;J9 M,6EIQ&[=V;)HG"!MER(5[.J.+BP-)XN3(GWJ1)(ODS@J#0E2`U6V?XL4* MR"U64*9@?OIX)$G[L^?]5D;#P43/HSL*"62I?VG#D"@G(Z''(2G0)I;N!%&8 M6`..0.%S9`(92&=Y3^65*>,RL96969GD"NGA0TJS9B)HJA43@F'6>A3F/`V> MOAYC5R;Q77F%G0O$DV!7GP8KM@.N4,]X$&#G>(;1EEHA7IB&8JC'Y]^B3V8! MKH8RG2-819?XHMY@I-G+MM$GU*H#Q*;5GI3\RX5IF]QG,`]IIQ+7$PKX3C<42C"P7`>MZ(9IB MUD[16SAH?E>'*VI-HRNKQH>2-OE5Z2<"/\RB-K)R3#U$!2)DHH7%Q#%JZO7= M)+N,`YH@`:,E0,+Q*.#K['D*LWO)_Z*ZZGXM,D3$RB5\Z>&+0M M39T7"EC?D">KM+5MUB[>&4X.0CHW\*]TR;0"I*."\3?Y#-E@[CZUI-]J:4\F MJ9?'Z/F&2N:G'7'BG9R\0N`I=U]Y^+G%E9QFC,&"@E2JTHX5&TPZZYRLS-JC M&3T.P*0)UHU7,D]>F,[>IBR[^)Q.E7Q0#KEI]W5C*_Z%W^DG[M2T:0Y2BV)= M&/W,:NA^SZ@4H*91T&]%''9,XV%5#N+O,:PO2$`MOTYB:%[%.;"N"$_$7U8AP;- M@V"$IAS\4H%QP$DYD@=77^B*;B4::TQ]O[`+]<;XNLP/`[*SSS>Q?X\Y@UI( M*A)#^FEBDT=8/CE8O+YXU+G&QF MC,M<.7;.L,QL:-ZT3PZ*(^HNQ-V_\_;HZ068*!J#@0QA(M]J)0(;N0SUKB[, M=>GQVCCLP6-9TF36*&R=J1R M8E<=1J)WS>I?$D-.490O]+47C8)>)&%X=[J#-ASH1V@)(FH+T;6-*LF%C,D+ MJJ>39;1XAR0W@V1=(VIG5-QH39/I9:]SI?#Z>]A?9C:#T<8[-$]#[3B.\UT% M!K_ZZ#TI,Z/6)_1N*[50`S6E_59X%DPO@T5ZG4$T&Y(IQ?Z99A9J!%`_:$QMWBU-G9Y?LCT8^`L4 MPT"FBQ1[N+FZ0#'I]N+]X0H+=JFW^?#](L4>+E2,-#L'BR`9#>"$-:_Y-A0!"YG@VFMWK_E5C[G!0J;FMX5W%VO02!'9\UH!AU<1F$T?-B#,\5YYP*/ M0YU^B0O^**K8<\\SY!@%[=J71Q+W-""_'1PVUGAW0N,P.M=1&&%"'<9+K4)5 M,H'JC`KD,8(:QW2#W(->PKC(XLC\D#RR%"@Q?D0IT/2H M57%I>AB2$I\)BLS^6CJ1A9D\O;BS]D/:J85:G3Q@))*=`P61E*8`=DW@3B8D MH:4:6>([/@_Z<#(N]49FRGPQ?,+1>C8>Z?D*V"=Z#^^R1L9Q0M^H"K/[=#/O M0AW%(DY,4?S#;,,L%_#"KS7N#7"6+UIGCKDO73#BU=J5+TZ-A+Y8H1"/Q##B MEX%0C_$`HOV8D]5*B3RTP M!05]NDDF/TQ--GM](MTYU10,9WGV?&]S?4$"GGJ<*<1S4SOK\J>W>@*U&[/X MOE+"JPST+G>!7D'(3PPZ^+GH-,4DL&`)PTV6JQJQ?#P++CI]4((P<`"[UF!R"R`F7[H!LS;3QMH>$T.H04 M.^,Y.+OL=+?K`]MGB]*XL*:Q"2T\YT08'P+W)"@=YJOPELJ]/#HY;;Q\_7KG MY>LW/^75GW^F9#T[V9N22Y"%1SG3TX9[A8@E\9C-)DTA- MG,DXU9[!9%+,F8N_8VL(7KW0&_;RL<'X%)) M]G>0MSX$3YOD<;741+-U3'T+LD+@6!\/`XZ($F>W9"K-VK=1@8MQ=?2DBKMY MOQ]>DT\J.>UVHJ)HLQO",L?*&%'%CY,TYO;XR)\3Q\5$RT1Q#^B)&A+CM=E*>C&9WZ-/L_*>)B'+9@\/B,U@Q$[[Q4TT%:+",.^Z\"Q1F+-%'%+94^^8@CN>!HEBMW9_PDI&PTP:%CB MA\`XW6)YY)6F=.RLEU:6&*A3/'[PFZRQ?[QOH<>.@)-E@0&;HNY9<*)DYO1X MQR(1._0Y94WIUU!\MV[*)XZ`L1H9=-F#,RX!HNC(U?.'[R62@8E_1D9#[/I. M'Q17?W7N?<+DGR@2@FI&X&L`PST\D#:P(1 M.;%^QDD3>^]T\JV8%C)FZ*2A!^MK3$Y+<=47)L(#:-L6-1B3WU5^?42^ M&S7;EH=8_P]#_UI'B3(..\51DOB/8&#&AT0@#AKH-,-NT0"&^$40QX/7%)-) M1DYTUD@'B;5L8T?]A@:XK5BS)C=1)%^6G,F+@OR6=A?X_,VAZ_K/<5-*)KP_ M'QZ]/MD_B3D&Y'ET2N9<=53MZ(?\]QE].6XP[D[06"5K1[>B>T&..<$9MHL8LZI]%/?!"<2,;IL:Y/F^V0WS8#\>@I#\3S/;%N,:'[=+M! M[E]#]'XR,GZF6MH7K6E"O&3P;4''C>^!^)J]@^+/EHN3G;EM-WEFN_KIEHE3-@$M13*2OR!%D^"#GAU28>CHQ\!?%=),1 MOG_?]`%'(*6W.:F9Q^AD/;)BX&-66G]<&I`N:%U5]N&;F^;"EXE#8!*&$N4J ME3%+_W"E)AASS!8@432'^NTS>>\Y[/=MNGE`50,8:<2DR$YY4=$2V0L3D6R) M9G_4/JFH3VQ2+UZ84:F-.2)'+K#U2E;K)(:VNWX)<5@[LN!0DY3N&5:``FR$ES1LH$`0F1]+<`C-`7T<](ASCI@-.S@WK\O<'4S`-0TCQPK-F=YVXL_F'I4 M+F>!J?NJDE6YM0UU`\;K$F6CS,964!F$=[*T*SD M]$@@U]A.<@;IB6!@.L/K^"ZHRY?$_\%G(EI3G?[7BO^SL;GAQ/_9Q/@_#]8? MW,7_^1I_[N$4O)(Y5^BO'@-ET"+>U2\Z4P(`454;`BBWFY^H+PP/=4S<+$,0]OX4@0??4%X4)NJ<^.U`0Q70=-EL=%`WH:S`,T,_Z MMBJ/HV&9['HQ&=V%-$S>4HY_PK9ZABYGAY3FE,F7(?T[#U9):B:D(U#48];Y ML2QTB9)(AR1*K^@,+D,9%-I>0\0C7P\S`Y!)B&.:SD,Y%)R=]Y8;?E%H%1#F5^X0<= M-5[6X6`($PQ35([:'&'BY'2'$CO]:(0'@6+3I#9>'Q^].-YY1^?_C\ M"%)06N#>`@U)'?S38]GX)_C.EZ#=7SN.QZC4B\+X5#&BPWCR#]!,[>M]Y?%!GK"1> MED\7OHIB.*@+5&W`>TN^A^^'E]#5YWN-EWQ:+K6Y\$G8L][+YZ[UNT5`"J&T_>9[NK.Y#(?O:?.[7M:!*#1%L6Z,=`M98.:B=59CG=Y2R/\B M'OB["RE80M0S:B8%&]L!J`7UWYV>^A\X<[5@$P(V%T0US'LK1K+F02,V+H)( MAU5\R05?L%1D2A.!)LGU'@-DM9V^ M$;<0BD8"+3V0-(&8D<3?4400>H&#"<1?:*4&/Y%L0_:JA__"R%X$??HUI`1T M=QA2=0F6$Y(I!_PC"P0C%<',(2R.AA.#PP*F<@"7^WL MOMP',4.&L#D8%U'C2["F3T3#^29EBMCW1OQ[,'"+XW.Q^_EHTRV,#]'NY\/X M9V<0.9^BMN.D\.NHDT`#;S[P"=3Y_N!?.5_TCNE\_X%-ZVD(5"D4QH9DRZIQ MOM4G7:L"ZQ\9EZH9 M!+DI,=+@A(UX@DL-.GY]+-\A#_QVZ8.^'R:^'0K![SA!8(JE"/IR20(3QHD& M8E2!"7^8?-(=*S+WL-\.N7."TT5)>&CZQ`E.IR3A83+!=HL3!H;L^=OM!Z7( M;Z/FH[E4V)-?6@7'^3R+6LX7*;6XWW;ZC7:.DTTF#,XW:K/HSR#0-)D@+>R7 M;57T2_17MV=_Q<>1$]P^4XK\)L4)^4T;Z M5UOT=+`"]BTYF^M%:!FE'>8&F^MIW&!S/;8\';Z-JGDFEU03XW1L\GBDW:J0 M@KDX1D=T8[]S,-$VJ4H494=E,AQ?N=^HP.!^XYRXWV%T[GZB9H+[34J1DF`F M2\R_[_U[;4J?J*XX*"^E(OS59+$8>PIZM,]^,,* MBZ0FJYNTZG#?-H# M"6783U-$@]J-`>+3#23S#YVL3T*0H7_J+#ED;=OC5CR#CF,VESZ31>0\YY22 M%%V0#F:03?_F*18PEDIV`B;_Y5[].4H^^/O4^2V'+?[Y=O]T]V4=20,DIA`H M(T.C!V=,R+:`H?!C)LQ=D(W'PZ8^%1&/`,(%D6M`IL4A\)AEO('9Q;!7)_8< MUM1B9E/QIY9FFP[O8#&V25UU9#EE]U;Y3?MJ4PE7X!^4PBROJ80C""B[]S99 M'FV*S0^B1>RU2>9D`FE5UV.IMNE(M=(^;7'R>^S\%IG!;9;$"LF6[5N^F.$W MC=#>U/$LI;H6P9LLS#=9$F\JR^;%NAZQ1YF^R>*^VSIMO1IIW'5UVVT<`\.' MFLKA04UMC:8AF;VU:6T)J93>-IO6ZD]^TW8IU<^XJB/0"1(LC#B-X-[9M&:5 M6,Y(Y/Q;)M&*O_Q;YH/[K05MSD*I6`I)__490"`*63D"N`,H/F,:$Q0[!#<4 MC_BG[HW>HP6*E@D$Z;:AK2Y1%@DW\J_IDB-IF8^'U'%'PK)PM)AFLKGWCJRE M/YC,K,QE8=!BL5NG9*#0TF2K0?VO1LL56O07;ZRV+@%U=FL9?+>4UNB&;RO< M.21!X@W4-$8LHV_UTM_*FLMNX;M#LXTUE]_"F,OMWDP^_ M37WXI7NGEYK5$85+]-4V?9U7Y,<5_(L#@:[(X*=9H!A,!;X#][>=4/UA8/($ MF4\]>0*5#%BBT?@L@@_@N[1FVYH#2W'X(JY&Z8'SLRL_I&7X12R1?B$=V/K, M,MLXPQ87^!`T<'6TT8\&<4RZ4X.][$7]Y/3-\^_5@_/M[?JY]L4^[KET>'/]^;J6/[SSZ!_?'IT&S':(%#6I> M1^,.1DD+KO!*(^W-#`I*L%XWEH@+^O9@GH>J]:&C:E@)?7I,&:^EIPL/%T5Y M*"+DVE1PMLR"8#.F_PQY#KINV841QR;(Q]S&D(!G(P M)A4[?6ET[TCW5M?0556;' M<>%7E"#7MM&YL$#@>TU+*=X\"?E8"-`>!A?^D'1K;,A#JGN:7M<8IZ?41KA0 M]T@S/SINT'CEY;,BW[JA(I]R@B*>O+1,(>5(L(\!S;T\5SQ7GX%7F=C:[ MI2\U50=GSO`1M86A38A5L;$JD,C2.?P-A3A5J15,ZZCL"I3>LJEY!8"Q,&1F M;4X0^4W%'Q0O?4MN/&'-8N$G!J_O/)=EU1R<#.;<$;>86?_2[VWU>Y-"^.#7 M[R21P\E'.4>=.&.<*"T'ED0C=%Z,:U,Y`K8]!,)7@>P6NMF=V9QVMF"SB>H>FX.&O:"N^:B^5FP##MQ6(U#-LQ2\H9J M,IUS]8LJME2IC#3RJ]IB'6/*P\Q<4_*V)"VC&5>2%1'T?%Y#0'5-I2N1-3@P M^9&J0-IY1V=0NI0TJ2T*8HL#?`$[`_Y=4["CGO";UXL3VS/*5.;1K+P".[%] M=$M^D?C2"AOX.M.])E9>,T2Z`OQQY?^Q0X&54AW^&\!_G0&+.2!4^;V(]WEZ MQB%`#$+%01J(FKL2[O(D%XUZ@R+_U(L$:B,#M[#B4(Q\P.170F-T8.L@DK2" M@7G"XV>I2WST[Z$1N^VV%8!B:8R#34+-TTZ_6FK_'>'AXT0Q&K6BT@@F347D MTT'?F*!U!JHJ:MN.:VT7!1R3]`I0U8(\-K/^1R=21NE*J;.SV%1T3&OD1S8CYI3LP,X7B[]#,Y^:G[NE-DP6U]DAZF"R0+ M@K1D-@V:*;&H=*.AQ(>HV0W/T#K%CN&T!DV)SVC0U.4U\,H?OG==@P,9,+V2 MJ70_OGX<&T!R$`>I:+??1T!Z:8D1M0\2"L6?)6I!SW<8OCD2@WU\%46XVCDE M/GUWB+P2X<-1@(C*[>+5%1Z.7*U>>NHEC@85$!Z[CO#[UR!UR;OHRP8(#2?; M#JOS^U$''P9I%>O$\`PZTJ13R'%]]^CP^?X+V&%C/<==VX@N-:4<7D`-(1O7 M=;4HPZWG=54CV7Q>=2,HW;SZQ)WUC6&02XK:P`8H%K9: M+U5*%;[.__'USNE+H&GS^EFS]RB<3(]*-:5_2JJ\EM64_9`<>96JN?64:6P_&AS5;$$?J*>U0^.WJK3E_LGZO71_N&IJ-HL_U@_ M/H'UN\Q*KKUQ1)9#V$GDD,A!Q704O7>RH9KV<1&"-)2]*EUG;[\OWWE`-731 M6D/MS-VZD;UTNC[_9,G48.DC]O-3`W)_^75;O*7;',OOO&%( MCV29IS]NQSJ0R;`T_FKGO[=_1YVD)()5^!_D.AG`)JJ`=A\[F\98Z&=VT'#I_5$],CI/QHR@-0P$>TSU2/]E1>GN+$VK[YZ2,;C0&5K#F752RPQ-ZNK#R_E&-U4B-(^XF3Z&3V/;4O M^HP4GU328)3)*R70%@>:F4@EE5-("@W+(45[L[BX;+VL@9`SI9?JZ M($I";.E)/J?<0G272))0Z"46N,19].1"'8)X;$V7$=$&51 M+DPIGBJ]N%5MQLSZ1M!)5'<$H$P1S6G1843Q#Y5-=C/KG%*W*(P,OU53^=;D MJ/SY)ZIB=H83.4R0,P8F7IS'9EJEU.%)`+!Y\Z"X@Y0`8K(TC.EWD0M)YG(] MU<$EI$^L]DJKE/";!M7)58X^RS7PW1TQ%T6+>#KA1[K"^:0H2Q>!J.L.JYW< M-7;(7T$)EGF%-42CD!=5=NGO6;$8D'&(M#*(V2K1%3W4K"&7*"$[,SEXA2>_ M-&TSQZ*6G`$$*1/&"?[.FRP$5#PW,!\SQ%LZF*KUYE!=%*S=WF'8RJFD4N`U,\4H='IX#80?VTSGOR`0CO MN,P9OA@EEI9AE]*5I0L:7/+6Z>]4Q-%MQJ,1++%9PU*EW\KE:8,8;FPM-1:5H_M%/,R3VD3^X&KO\CZ:[58 M!UEQZQS5"BY19-&&/'+#-)9HWN;"!V0;-,'1MV,28_B>L;BE6@"N)=I<>,/4 M+O[TTT\L-I&G'Y*MR,N@..5"U9^@1:K?L-)B]W\UYP(P4RKK#WYV>!*_*_S. MT]DU9R1T6NK];FC`*U>YY<#\FH2"HP:+8/^P\7([[3Z/[^EYF=3<^\4G.I7(GH1&!SX<@,+!M06<)7=;=9XQ':D;!CT<%4UC3 MS\K?\,TZ(4X:SF69G!+U_2ZO9)7,CJY[+O&XFBN)DCJ9H!BM%EL(OLL8V#WL M3R1/QP%SV>F,3\+-8CM2,DK-S%2(Z?%:=[SM/ M#%MJ6A?:EK::@/R+27_54/[JOP!=:1/%FE'KGKTQ64!I+6A6O@#9I>UHSHRG M[G63B7">BT93H`5)\OLSVYXS?XNU;:P):PE+@01@2;^M5MFFL18S14BVB*FW-,+&/K&6 M,'BX&55)M45[J2WG:G&[BB154O+M#"Q;E]4^OX1S^!UV2MTVRP4[(9YTE9RF0E/<(Y`2R MF[ZEI09,PBY@KFW:Y/;E?W\S(\F6C8&D^>J]EYPVL25Y-!I)HQE),P/EN&&? M(`L>)O5X\[F]"K22VZ<;PG)% M,H:#$&,XB)V6)%?=7*V0A9:KTZN50+:R-D./;:!)-VWD;(A.V'&%_"Y-Q0 M#>H>I%72-P"L)0>JL,2+`^*;ZZBYT^7U>Y!$A7PY&V!(P2AM*?HI*0_X. MC+#%882E\>3'L[O`ZX"AV#.^]A#GMI02)VE9&2E.R=MSQN4+S`MY57!;BI&! M`:BX%Q1\>U*> M$0C:OG6I>D-2HJOK4K2BAVJ&-8*?52[U'LLZ[SHXXRR/W.P)F%H1C-SF9.]T4[F0A\<1B*#>YKSD7?@8_A MFP*#Q)D#OQ<.];2AXJA&AR+7IU79PSHV-V+V#J561DV<7Z>6B/VLA() M?Q*&#*M?%H4#P;9"YMPOBH+/!4-&Y"^*@L\B0E;K4X0:CE9,_?.GPU2TN(*D M6E@'%L_3>$#(K%H!,$'?@S!]#UZ>OO[Z%++]OP=+?1[&$\D02FRLECQ%?YZB M*L]1O*<<#HKZK0F%.9:6#D$Q!&,XAKB^=<+WV^3 M$7)%\7R-5IPI@)+:YR(-=WKA>ST(OH?WN!F!R=,').:JS92NO0S5K49`VIEU MQH".;6ALG<$J&/+C$0&'[C'@4X4O/`,5$`,Q`54?$A+10&8(.QD)@Z-4R'UM M;*4W,2/B!"4,CE)?%UK=) M)GS/-IBCN+EY315$]9]HA!SN1(H'6JZ4K_BD-U6O2CT"8$&YA-T[/?R:KNLXT0AZC?M#; M"Q&OM4;4L]5+G'R&'6$:$6]:CQO!R)L"IYJ&ZIL+YK?B7]-0O70E$ZJK34-U MVI5,*%XW#<6%%]1DBFT8[LP+;S8*5]:&[]AKMM+$KUV6CMF'ZD7X)N7[XGDQ M>GORAXI0%(K_8X^PFUW]B>M@.YO[N[O3XO_PER#^3P;>]W=V]_[&=A?A>5ZG M_Z4MFM8RO6>/_X36[-'X3QGX8A'_Z25^I+.I+EX,@R<9](GLH?EP("L@O-N+ M>_0#;H[70MM^;L5BNNX8`Q.:;#P$3NS=CM#,`P.6"N,DBDJ#L)<#2[#0E?94 M8/L(<%-'(8NG7E8VEI*DS5#4B6M.A.S]7L M67!=_1/A[@STI33^BBTKS&VP=".EZRGQTDBM!"\$AMX5FDE`&0Y)6%TJ:2%K MU".U$Z+D#MX%L,4T^O?@__"@/T,=#U__]W;W=Q;K_ZOT/Y_8^JOV_];FYL[6 MHO]?L_\]BYOS7#^__,>V,YL1^6]K&^?_HG>>_P<#7K/U<&A-O^\QBT)&+_.X M$ZQ>;)Y4MS-L2TTL5_.YU?PN!(R\(6$(AM-<'85` M84*6XH&X1;PU49@V";IF&P1-1&E9NFU)V:T_T^+V]'5J(8H\T?Q_,MWO'O-_ M9W-[+SK_M[8SB_G_POH?:%JI_]I*843PU/6!OKVYF0*US[,971+S%1550X0! MHVB'XQ%Z]!*J@7YM"R["?4-?1_.]MMSLQFW-='LTQKVW^#+709E).));\3+6 M\,MD&6028C-3Y1=3B[758A-8F9[=3!K1T??NX\`RO52PW5"KJ'/JT#]C_,>XB;Z/QJ='`6C8VWGSF'TU'J-U1ZB"J M'\82.;1[LSQG]T8&2,JF"Z>YRH=FK7AR6JS4:RQ=*`$[RE>/CUECVL="XJGF M"N72.X"A:7ADX/NZFXD;#&$YX7RN4JV48*S$?4"4&6*7"*\X67V4"A&'SQ9.:[^, MK.(D5VN*1`8])/MD1<>7H#NQIM#2!BG^$])H(1_]1\G_K=YP[/7Z3[T)^!WG M?WN[VXO]G]?K_Z=5`N?H?]O[NSO1\[_,UOY"__OQ]3\Y8":50"'U<*_^0J$) M8G+<5U$*P9?:DE]#`VIH4`V-Z_1$'4^B6-Q7;XA9K]F,!?N3[G[R5^4L25'J M&HUY89DK)"D1#E^X=V=0IX[D!QIJ">+L@VDFS)='W. ML>9C=*G['+9*%6=I:;:.LPKX+GULK*&JLS6[C?\6FH[IC$S'M1I:>PX!14$> M7HD_*,:+,^;#9-<9:1;.?HP$NMGHN.S7EI@4': M9BN_^G7<3M6S;QN:9[9@D'/M9B;]^N@Y26??9N`B*3N5M`B#"$O`OA_2]U.= M*IY"\[NE675BCY2+EW/[HPM5,"K:Y"%(_'K[,\8TY#>T6^@/?+J]U69KIZ[^ M!O`!3CE[CR+U9D:AH%B[\7/C9V#-GMZ^N:&_5_]"%RY$.WI##R,:4-"IYGB( M7D8I/E>6;1U"_4$*7QCFRG_]SG,<_W_/^?].9G'^^_+R/_2_-1CWT4&S_IK] MO[69R>PO^O]5^Y_D:?#_M_;I//_[=V%_O<2/[7\>>FLWJSD M3HMTIM`F5;!Z43^[D$?SV=#1?+UX66_6ZKGS>C-7*)QG-V^V-LV#9.(L=U)L MHL=O2D$]3>R:AQ,KU0J6+#0GX4!N[CS_GJY++C8?7W'^HP/[U^;_NXOU_W7[ MG\?$ZG51X'QF_L_V-B/\/[.+_;_HG>?_`>4EU6A\!)WI)_T*M!36__>V=J/R7R>PLYO^+_(CP6NZU MU>\SM^WT1AZS!CV*KY4787C3ZVEXAM]DY>CQR-(4!<@=MUROYU'X0`P5B`%= MCJR5;\73BW(.]X%(L+S3VNR77XK58[K6&;IJ.AG=0L5$8S(\1;%0JO]=7$8% M&#A*13QK9CN]J][0[+.K?H?."3#QJO?%&K()1-#ZE.7MT2T%Y&&K^36V]?;M MU@;^WF;'CF6QFMWUOIJ.Q8XQ`*Z)+=M@I6%;HV]_=WJ>!Y`!U9IG?;%8_MH< MM"RGCX$D74SYM7U[-1R[6MLFPZ=0:T&Q\C"BVDFY0"&^V:PPDZ%$P2QW:/;`[O>YM,H%Q"7'GAP=O MMIR!*R-;GE0NV`F1N\_.QJU^KPVUMZTAQJZ!BC$%R(\=D4Q@^6D$.616CZ*; MBR,#EI$U"'`;T"O)Q"J,!L#98?8(OUK#D,TBQIP\O8AK==`X/U;CM3VR_."/ M%`^:![OJCOL;R02&2/^]5']?Y9:W[/?<^7FN4O]P2/&J,%B4A:,!`6$PK![` MA08YYM"[!;R3B=,BJ!WP0>Y=J5RJ?P#,OF9A!U2YUBX.WF#VSUW>IO1^@&T5(TVN,S>=8;0N&*P9; MIAMSX/M[>^R4]-U M6>X+=%T>1K33ZUS!XVF.;6:VMM]NL(M:#MHT:8[A"DU M11[3I2+%N#UU*OQY/_JUO**2"I<:P"2<2$16,9%(?&WB\Y[;%G7C;3V@]Q>[ MUT&V,M&\)@]`VZ2S!AP>N=,:6UW%\FMKA_[W%`YW/18`AG$4[-;_'+=SUWLN M(D=00G@D$W,165U+)KYAF[I#]"4@NF=I:0DX9DFSH*/Y\&!R;><=RA@G2!-F MRFCL-2F&C6>UO3%M)6-T9DR"3D;U_`X06\:H\5T&8!&:J(=@W2E8\]9/P3MH M_ZIH,?%7QA0B0$VT:-"1)H\\.F2IE7SU]*Q4+C9+E12Q*0I*7R-8+A/1X9%S MB&A(/)KB8`!H:S_] M)$\!*-!QDUS9.&/TC>[*0H)LC@6]-13THM"<;AL:R-L'POL$FC=C%O=S=,3B MVB3.&]XP)F+!SL=^3>#T9CK,>^'I/!K/OPLB>M:-UW0LL].TA_W;`+^Y,.^% M9VOX5'@.S*M>NPF,"T8L3.PKJQ/&]7%X#A]%SRC-9OT\#D_V/7@>LKO[X78O MF.B$SK54[H*CAX=[E$$<>11I[5$L8>L960(N;+.X0.J0NSR\WYQ^`&0G`GG* M+'P`Q-9P"LB8"?,`L`K4!WR%']WYZQ,/[#Q_`.#:B+T%0[_)=1B0PIHW79Q_$I-N]FD4 M()9JI@NKMR(MA/*XR"63FMQ>@7($>E-@SA$3J$QJHD1*IH>.+.Y@C;Z3XL-" MR7_`_@\GMF>]^O[_PO_/Z_:_/`S4W/8S[_]!I^]/[O\M[+]?:/^/[S])50AW M++8/]L1EWF56^&]6`$G`Z5ELM?/GKVW/P3NG]H`"UG*=[)_`?HN5^OF'%(HG M])2%Y)&?6?[?Q'D*7PHHE[;J!]*(0F[$HRK*5XZ3RD6I]IY*/,)97)R! M1XQYQZ.,QG::X8*DQ,HJE5S#F(W6C?5RM^KU3^(,QC:8>&KK&WJWQRTHIE@] M,%<_A*'46.%V1#.*I0O\MB)(AC10U]64+."G(8XS`$SZ8IA:6/>;HK/13+QT M-,N85Z@S:_1,L\%0!C?UJ+:^HM-#5O3LK!X#;BBVKS3W6GWKV&[L1%)JXULX MZ7X/'9#H0]M+AU/^U>PD7`O4%!-J4LGP9X"S_ND/,_W/7/I_-]-OFQ]QAN'- M)^MF9#L>\[%?U5AC55MOK.',0@;),_2&9@U@3J98B.2(::0Z6NW\0Z5&<,,F MIJQ8'T*I+-R+?O-XD(68/46J$)*1SP1Y:!H2ZL_,?>%(/A6"-068/"0.N%ZY M5*NSQM%1;''&?II`=&-VX4ELIGZP.9GNDSB<$7X-+<'^?G`#B$^J+YFQ^LG) MQ.`O6'K4!'P]FOPPF3"40C^4_#\(YMK?7D;^W]_.;$;]?VWN;2[N_[_0_H\O M/\N[4WCQA/N]1PU@U;_CLX;[0='+4P=O-]C;3?B_!?\S\'^;+E/MS+U,A<#B M+T=A]1VUQ*-O1"VSI[D3MX%;4,KO7O:AE%M?^!]^-6F:/O1T%(^1Q]Z.6 MV<-N2/&6/\$MJ67VJ'M2R^R[;TKAX`7Q@E01W/]*)NS6G_YS,C%R8,K=P!MZ M:-+Q.*S/DPF]I@?4=]&/6G-H#BR6A57LQFHW_:]65ODCS,A6;\CAKJPJ9=;0 ME0<&LFC%9D(Z2".VW8_-75E5M5>H`_AC*V*"<3 MDY.AG.V8G&W*V8G)V:&\6\!V/AJ00$N1:RH04S#J9'"^ON@BQH M#?E.S]#$`LAH6=NQ84+P%<.EVU,",6J<&&9BQ"037(N%D0\C%.1H3"I5:O4< M)7X&'=Y7X0_9Z&OGLZYI0#10V?I]E*K3;;]\\^R\>G*>.Z5J1-I:D(L[\U.R M+O',(93'TE[V#?92W`1<>Q/Y=$O]EB,JO*+(Q<=,O7A9RA1^*T&B!S)GIO.EETP`LRZ7WD$2 MX$0TS.?QS*3Y[J)4+F3)*4`R08X0D(#`V/Y`_0DWEM!)`O_-/K)#[.@A(W$X MDIF^9>ER)$W<]Z'B?JE#6*P_)Q/EXF6D*K3_IU^3%059ATR!*5(('MVPLX7(*>Y=WRJ];VT/*GD3CK6H46P-*+K@I`#;"Z'JT7%@%:K2LU`Z2Q.X81 M>,MP&!O$M.%OP+WQ=0-$C+X%4X&NYO2&5[0"\>F1YM-C`S'X>MV#9K1--]P\ MB:Y8.D/*I$:R5Q6EBZ\]%"3@Z9;0=JQ1WVSCFLT7.=%0?O\=*I/4(%&`USPP M;_F22G>88)`;?JEL3+.@OR5%L[ROJO.`9@[>ZY M8GN8,PQH'(HT))*YI)>W;KDI`6Z!!EO+7<>\&@"OP5ZM@/KX6[&)6."9(,?B M7:Y6A#>:B()?`*>`].."3!9%*&(33F`,W[04RO"9L?2B@9.SI,%_'RB^TQXM M)7+H:_0LXD$E$X7B&<[BOSK6B-/G=Q3&I!`HY!18+F``$2O%T0%?5?._%1'1 M*VLH/P/VBB5`;^X0`\![6/"7TLBK*H,58LB[NFY=AELYNZC7"+*H9%7Z==#L`$>"`_,L;M=?,9%""I&C*X8 M]"@-%AN-)4`<=P3/JY[5L5NYU`=X(5HHKQ$LOJL/@RE-<#20W5=A^FN#`:,_ M%DV.``Y+TVTL2CBO'A]GB9D,OS;/2 MB$(:%SCBPPP8:CNHLWAZ@:0<0/_C%@YU#OURP9(`Z4$R+0Q0G[]F=J^&8\%%>3<>ERZ;IT4#.@YIK=;2F M7;N#^RT:D[A?_?RS7&^\\4AH@[RW@.4,K*^V\Q==DT?-DI@DL--DHGAY5LS7 MU;:OK'QS;-L;6'"?=3,"H4G\"9$CN.9$S9SSY6'D$Y\\?KY8,\\O*O5B M+8H4GY(2=,?ZTP2ZZ,W^^##ZE8]:4((C)U`3?>>_-^DLY=[# MY[&CQZ]5CB'?;Y*2]\(C^L'#-HPHM.#R,HR^TCCQ(OCQE2T$>9!::)L2?6(3 M`^*2![!76I]14VB;([KGR_5]G&6(G)#Q077%@65E]AXJV!`G MJ!ND8;BHI+LP_'M=T.]/)X0$M.]`CLUPJ=,(RC)"*Y`")P<=FR0^?I+\&842UKZVVG^](>5=JUT<0R\6:P;34!&3 MKVL(0'"7\0@4/A`%W0'N:B$$E)!PFP%HRZ6WOX;V5R#F5^P<<^S95,T'$W"@ M>^50SZW6-I1M,&?,-\H(,;E91WBE^7@1-`,D`1'-AF^7^(!!IV&J3*.,%=69 MV"^DO8!&DX\G6KQ_,0"@/LLAJ`482*]E`6A9V?+$HDD2'-=W(HZS20XMO2N> MUS_P3,CHM2SG_]O[]J\VCJ31[U?EG/P/'8&-A/4`;"=9,"0$RS9G,?@"WDT^ MVY&'T8#&2#/:&0E#;/[W6Z]^S&CT<'#8W'/1;O#,='=U=?6KJKJJ>GAEGS`7 M-\$<.V`S@EYT_H_O5_"H-1U%#[-'KLH/YVF(=]8'_7"0]L*ASL"X MZ4S2"GP,.Y3_PKMD_!^OK-A6PP<"#[G2@]J@U M3(O>:5NNG0_T-=E4RKD5.7`N`@[<.V[IHNVVO@R>B@&\AVN#@:\;JCL204CG MOJ4A>'#\HG7HC(FJ,ZW@_S@311:Q9B/D0+:0/[3'2?$I.\#(2'%'I_8ZJ*#! M2Y79]9`>+@?T+QVLX$//B\[@`9'3!^5*'!#QX2)@`*2=Q*?@,AT-I$`_"=DY M!7@U7:EVB,25MJM1Z&H4NH)"5Z/0E9H)#?R*D?JZ^LR^JU'I"BHZ.Z,#`B1@ M0(J;YZW]UN'V<>MIVVD^,M3<2`P[Z&9ZD>P2[\F:6&YX1P5H@N[9$)!##/^[FQ,7[;)U9_"X_;KO6.[ M!FPN&9R7E&N4@M^MHA82W>U6<&+GH,'$H5L:[)A4Y@GF$8^J27,L9O MXS$3RAM4"VRTI]AC[\4FI5PTU%6YS.0QT8J7TJ8*FM!IS;,E_0XORKZ^:;R+ MF_#Z?@/$8\L%4RTS30I`ZCAU')PVRDR3#HA=A#:#*3O/DPP+WOXWV\D6";G& MU`BIHO8HM5*N*FV3,.R3M1_.0O?+^.HH:^JZ+(H]6@$P/BMP=ZJ^$_0STUYG MJ>L6-G\'X;^QC&>HE>I&L[-D11M.1H_MQG*?'+2*RK]G.L,37)\; M5U<4CEK09)X?[[(UB;J1)ETUFF:C$#8<#UXQ`@@Z$+!*"D]\U1*SX;W`BY9( M\F`M65><+V$5YEG'RS-;P#GDR-KF&%$7GOB0#)^L62>^N8=@US*&KG%MRNDC MJV6J'82)5ZW]IT<975RN5O-]@FHR"9K MIQ[,0'Q1"JO>)P?I:QQ)GRP-KQ56Q,@\G(;,P]M"YB$@0_SY)&0H\3:0P8H` M&>(U)R$CP3/_>F3$-IM$DTG(4.)M((,583=YEY-["=)NI9.\2\#$2&J3T#$9 M;@,G71DC1F+C%+PH_9;0PKH(*Y;=)F/%Z=.PTGDF8F6`S($8Y03$C+`^"3.3 MX38(IBL3Q*8N!";#C1"S4.9"3A8%HS:8AAQEN"VJ866`F%&)3$+,9+@18A;* M3.1T5MSQ1.\R<=.3]!NA9H#,WOHX)R#F3:.8=V-J>?-1RF,J:?78)'QT^C24 M=)Z)*!D@,[&2G+B&\>V8DU8P2KT1G03$[-5+KK013>!4C+I?`:7NO#AU":G' M4ZGT^.94>CPGE1X+E4C%.!6CDZ^`TLF\.)UHI/SI2/E?`2E_7J1\C51_.E+] MKX!4?UZD^AJI=#I2Z5=`*IT7*5P*TLFS+KWAC$OGF6UHW*85^A,1X>2;(2,P M9B-$&0$I.2F8A)0DWP@I#6,F4IR1Q`8^U9@L.G#Z-+1TGHEH&2!S2!"4$V-` M\>'1)+PD>1I:DF4R?T<`9J+$8%#VY/.CB=(G)T_M/\YR4XP8C,&([\Z>BA6' M%)F)F?^54./K#.P1VT1^16>XT:"W4&9S+)(5D.L$O:'W_8\3<=/I-T+-`)F) MF>04JM'AVS2J488;4XVAS$4US"K2S=0N-1EN+'K-V:4ZJR`WE7(FPXV1FY-R M.BMVJYP.`VX3NE4RW*Q7`<@\/;>/50%:(M(B:J0G2& MFZE"YE*XZ;H8KX=K@.?)-,0DQ^U@QI6A'H0,1R8J0BCU9FL$@YBM"L%\Z&!L M[5(F8>5DN1FKCR#FW(YLG2B&&$.:B9*(R7%S#.?/>#0E&?J>,,,MS7< MH"[A@::JGDV&V]B7=&5X4&BM*!&S`V./PO9S^&3LY:K&#L^].G3OJ7-SJ@$V M$Y:VGD2C]*HUGK31=VRT4C)D5/TX11M4XW*2HA%)AVZM#"*?/7?8>L(]HH=6 MB0$@18_7+SHXCC(.&$T3-I[I+R90QI3)F$")Z9-CW*2-HL0.REA1"1QK197) MYYY4\R%Q2GXOVB13[*;)L#P=A?!/@RA$AAMHRMH`>.3C"A4.`;LC\O'H-K"W4&Q/Z]HY1]E([)LP--090_2L@UKQ.(<6[@(`0+BF.X`GZ'\8DZA4F8*O+#(FM2\;XU`9[(?9#]6*MT,,_^ M3:,H_,^(38,::L=+86N[$EC4BH^!AN0G`2%GW1B)"-!,#`BM03>'_0$Z#R+F M'7;,1:M\?$B"!MO`?/38JXO==,F"3PWB(5`@]#@$2"_TM?4`!F]`(8-O%2*]>(8S<80B]->_+$1DRFRU"I58F0EGT#$I]B]/:P& M\:^).]1';C?Y6;+GS2")H8/[0/(]#Z=%C8VJV5D9ZL'HP]@,ZSF$?4$FVV1\ MU??(-!OZ>71V1BXU7AK2]2$+'(]1^UUFJ4GNR#+T8&)E(^&XQD8_LQ$6]H=` MJZIW8H2%(:#%F80C7=@\Z)6`I=F\Y24CZ>&)L.OOTF@TRI@KZ9.Q/>+V$[X/ MXQ$02^.'7_H7=J;0PXEW;N$O+#A3!:?>!%LH-.@DLY&%!;Q0G2I<<<"HIS'= M8!!TPB';CJ,#(=J7?0S3,4?$-"ACM)-Q*!=>;Q3`N/(Z;)"B_WH!?S#2V>%Q M1N8+6+_C1.?GM\E%Q)J&L#?/,[/K%F0%$]C:.3XX_&WZ\)`0`^_1:WHR$KRXLJ.UG;T3 MRS@?2RY.>T\5(ZMV$AYWV>8N2CYY;##_,4)`<^MR`Q3Q,*3B#Y@OJ76?,R*YPU6FZ%__8;Y"M'VE/%Q2I-[H&0$EE_\Q(#%KV,+:_%4 MXZ%I+>_I7;F)S/`?CG#TLT,P,Y0P]Y)`.\NA+]T0/9D:;*E;QWA&P(VRQ;O8 MPJ*U*\V`[-*#$IA;0M43*X8AL-7U3/HL2*LJMT1EH4^4ZS*K$S=CM7XZ0I^] M^9K`N<=JGT.D+*AZ#6M=E2I7"^M;^TI5/<2JUJ2JM<*J'GZ5JDY@:4B'B3?` M"A]"A7Y_0.V@-SL(33Z)N,`2F797QT&X\^"!RMS^0O)28-[Y2AKR"UP7?]*Z M.,C(V^DH\IVW.&[$W( M[;NR12V@^BC!R?<7M)T@J_KK)`<\0X*"*C*XK;O`YJQUC.@N/MJM90)=*9,E M+;PZU$786PZT'(WED\I`,OMZ/3O,,"V;T]EF)`MO_AA2J#`MTY\SLSGX9!;Q MNAY$Y,8$0M;!,[7SHK7S3Y&VCCCEZ<'.:PS>3]HGFX21\2AFA^:OK$YK@Z1& M'1+&&PX]O\N1-"*,I)$KPE'8)-J2UT-U&*EV.!/Y\ZHR<%5E-V8(QPLA-0_& M*E`2+L0[B2](E<-!G?'*58+2B7V,%!*NEQ8_<=;KNOZ&WFV1JJ?6ZZ$YGLGH M!,R'SY_9,2[Z<^7\P9>5$ZU:\*LHI;[]IG,1TKY#49#XW_6,@TM#XIRH'`:9 M,"6H'DQ'_;XFA0EMLIF+9K)H@YYPR!.,Q%0MK)`W#72F&<,)/YIZ!7Z'YBQ4=>:KJ1K3!K+S/444S6CV.2[[9 M3B4(5!>:1@0]=:F[,:A*@!KVH=6Q(F7*_;1<@[]!F2,#E/O],H6OH7B.%--% M@J@=)U!F;<(`D&J`/\X$7_6-61I$@1Y$48 M3I+#P=1`-@HL%*R*L!K`E(:]V0]2"NI`RCQ`#O5!]9"T0:9(&%W(Y5K9OL"#)I7 M0;TR(CZL_[*WO?_/*BW'T,?Q613^P4*Q`5I3>)L;T0V#+_6\Z%P@T?E=$(WZ M$O`G54G8"?U1+QZE@!YLQ=FR/YN\/!,:_71]PD0I&9>[MV_#B.+P<9)VJ2/1 MNOFSKTR4HOH_=_?VFC7\AEM5[GNFV._2/Y#[]Y_QAA5YS67R,Q_2YJ?&NS^*?;UI;U6OOP2N46F%: M)AI3>3)SH4;2I]%.JF.O$>AC&VM;] M5;6ZU>P$%\T(11FNWO;G.@9'C6"6KR-U)94&&U>\Y53$"#EHJ$J]WZ_RV.G_ MOSYVFC]',;8T&N;R_LV'5'_VD*(!U9]W0/5Y0/4S`ZK/W[[J@.H7#JA`!E1P MMQC]Q2,GF'LQ"N8=.P&/G2`S=@+^]E7'3B`77HHD;/CG68%B=^C0F\(O$)L!Q%>N0(9J84C08VE%"S:F8A%5C4"PVIRL`B:OV3'XC4>O M<;^]T"IH*9`H;4[`+55.LUVH9FCG97RD88Y(B0WHEK5*.,889,;>Q\3.&3<, MT&OZ!%H3;S>,L4L;WN@2_^G%9TX'Z/+.#/^2?J#2.1EHJW5C=/LZA?7'ZGLQRO<^B*^>?Y4OI3='%DE) MD$_.1E0[B'/[!\?Y`II1P'HH0(W?\])N3<4#_(I*]^VCX]FU<)!7$R,9K;R" MRV$Y6PQC68<7P=N&7^9@7CC<<58$L)JEJNXJ39<;;_QN[^J=T@]<0LZHUA7U M:BX4QF'ROHY-19VG:O;@8 MC>?4)ZF?/SL-D'CR#NURI1RBUW-QNR1X56(T:-FC:CQX;HS'H*+S:!.648># MT@^:<2!CC44^H1;*4!W+[Y7IB-)X/T"!)G,4@?VLW+BS^517DEVWE*6O3XU$9CP\B74'(=*Z6;P]PX;2^F1&PKWO/$ MB`%Q,4K-*IJ]0)_!WZI)DCO+=*U/&/VMAHD(;N-WXF+=NR*U(MIM4M1P;F`R MBE)5IIBR+U^6I2FKZ]-CS66P7-/QI986=`RPIZV]UG%+';_8/5*PKK=4O2YU MCE+LCV%C"0WCI+`T2X/+A^S\B;(X<<:S-TQ*(2$*LH=$#NH-&"-$FGS(-R*7 MA>GDW)+B)2OB??!O, M1*0Y=5Z\&R3*%-29X5R@%FZ3G+&-^OTKT>1+Q'D_4'CMS$C;NNJ%0AO*I6S3 M2CG77=@B:WS[C:Y[?0(-Q*I(7RK0QGC!56M7E/U.%)"P83G[6">JOS<8!%XB MJGM4&6-93#$\#9$8W]&'CG//2R?R*;VZ"S/O/U?:SX]:A+5A3 MN\?JW[M[>^KY@=K^]_9O8GXB03'7;3S2C#6]M9Z'K3?L!'ZO8=P7=$I\`LWW MSZ?:WI\":Q35T:)_O+RURQ>3_)RYO3'$%W-[(V^QW;T.B2BMD&"JM]2*?$!5 MXT1@?`>L-X'K:&""]>FPH^LF_.M_G_[CT5VY1_+TUVX.)B;JNHU=>TNMT!A/ M\-0H(K^@+\4IHBU%3.1@L>LVZNZM=X0-3]V=HWORO3'6=#,63=3>S#0R7BM, M(AMY53FA5_]V-,C[WDP8L#H$\63Z2/DQ(ID!8U<7"?^[;D,O_UU&=T;U-#XV M;,]R).-U$S/Z=AO`P:'=U9'01,1T^.5U)XSUWW`'TN-)6F5ZQ'2`:9$./[UN MHW'?>GN`:XD'PUDSB-JJ&S1AR9\\UC)#3/?QM]]PL.UU"KH]3\N+&DV@YVQY MIL/TFI[C&R@.N1.MVL0,7[=JW+_/F-.3);^.YPEN>DKZ3K?2[F@4#UT'`9[8 MQ!O1/;N9SK$-9QK]O[G[U?H_N>UE;O[GV_E_N?OS$6<"[D+[.N.OW"7[E\SGMUU MD>3-G3QR9F<@DV>!B;^)W$CKN"=F//W>TO6C'-#?QE$GG:%]E6J. MO/Z@A[<-8FWCV#<['_HPH.N=X")NTI]>1V5O-N0`!/5T%.%_3?D0KZ;8ZF;:\&WEQ-)B_=V#Q\=C]B)N+WW_[C?6FW]]^V=I<_$%69-:< MFEL;N#--+U)(@V`8)"GZPSCVNTZ\`S>8/L*^;J1=-&F;5FITJV59&@+?<[AD.]:U(C?%;,MWK M-;U,VADZ*BA?+G[2N:[+:A,^V/LNZ)XUD\V)2\\9<\'I M<^7@MZ#V^;I-_:'H@D^\VM/U78M4>?%3;C`A;`VZ9(`XF*^/%]%0TSV!1-I_+Z/V5F[#Y=DX`G;_`-(,/'K]8.NV@G]@XF=;I"Y;`__"SO2+Y M:).OEG!J5)_5,%%+ZTL*_^?>*?&V\N9W]0[_6WY;;5H@E;>KU0V\3(+GSG.] MTC[6E]-R[`PZ[?14WTOQX$.2*&0(WU&)9>TT=2.*+'[BJ"%FDC:4W'P91X&. M+9"M36(I>/Z0'1OHHC%6R]*5G6*12];$]OFF6+YBCBW.=:LG"&F?=V$4Q M;6(>!X@/%A?H-AR)U[6,2HRGE45]/3)0HFFH(`S"7.K2C^\1%N[(?MF M>4./+C[%,`X#V+0LM)/IX/;G!O?M-T>MY^C+TC[:_5]8]C^YK_7%3Z^VG[?H M^?I:U-&XVO>Q/_'4L+V]M_M\'PN88":/.=)"A'$S1JE<:LP!#_3NSW8UV?YM M/C';RQ;NQM2K`%)ZE%#-UMC>A*F?^U3/?ZG34R7;KNOJ]75Y#%Q4`"\:`]@N M*KI?4'1_')=&4=FDH&PR7K:HZ*B@Z&@#"WF>0!;184L;Q#+F^Y MF*)00Z4QY\KB5YT5K_F[6EY$:\0M+3QJHX%QQN$R<=LQFMV.$;1CYV#_Z/CP M]0ZZN&U>X:)U"XB.7$1GXPEH'K;V#G:V;Q5)%\=H-I+1-=V1##U^O'UXW-Y^ M^O00,NT?[.,B\;2=2X)QF/N"2\@MM"IRF[4_NUG[MX/6">%%IF#EQ3&^G-BT MQ6RALKI_7^TE_5A\]^OY._W,;/XXNPU&+\6E'.I\L%W`X M$"?(-\HD09\MF6!@^,+3>6DZZJ,I%L:!NZR3U6095M2R#E9`=YHAY`5K3I,Q MFBC;^#4`M[R5L8L!F9#BMQG#(9)(>LZK@5_&.#4+BTT5OBW!K[RUY6:2P&2_ MM5]N[[S8W6]M8J#3R1EW=C;/?+]4D&Y:L[65PT*;*J;-W]^6F\VRO+PM+]J7 M-ZKT;IG>G09I0&L,2:S)G&\J8]GC4BA/"_LNP/[$_.\&R?"/AO_UQMB,^?]P M[8?'>?WOHQ_N]+^W\FLN`ZNS#--^<)6$9]VAJ@!/M/J/'Q^JP^",[E875<'K M*"03[.$5?MGQ>B$L#%'H-:C\=J^GJ'P*TG<:)!>DC%,,_#!P72Y(>D6_7QC+ M:3PB_1E\.0DC5!JR+S>Z)`]0,`6^K4,P8&1>A.C"@;:2ZZJR6M6%7=A8.T;4 M9"M3C*.(OLVZ;00HBH>A5(GZ#,C#GN25M6H.%)N94J`?Q`WUEI!AT/.N"-"0 MM(<8LY%B'?IXGWLOZ)P%"'-=J??O::UD/?'0&JVF\>GPHX>1)P%()[@(>O%` M?):GD+FF?@F2\Z`77!&V(5UZ'S&V<9(N+1$XD<,[L4]F[JP#P8`"%'NRC]:S MH==++35)P4!%G*83**HE(A-;#\\NAR%9LUD8?0Y3B1]/`V\(ZW>*55&HRU/J M`(*CF]M0^T%(:+@7">>:',4VF48>M).@N&W5?@>DGAKBQ>P=^$KJ!6A7/P9& M6HB.:N0$@/,0(ET:#0R-D]$860UX$@(8M`H8!A$/P13=#GB4D]7=T<&SXW]O MXRGFD7IU>/"OW:>MI]#9VT?P86F)@CG^>_?XQ0&?>F*PL,/6T9$Z."00N\"P M[T(!@'"XO7^\VSJJ*;Y^&$3%FBFYM_MREP.2U*#6EBY&(&Q1#&CRLG6X\P)> MMW_9W=L]_HWJ?[9[O(]U/CLX5-OJ%4ALNSL@5!RJ5Z\/7QT>E%:$,$J;=?GGT]."HW3;Y\`C[^'_5 MZH^ZR9B;@%:JWW[SR92D;&B?S7C0*Y&)],\E5B_"``=Z)!=>#UKB*2YJDD9.6!D/&I+)[O`M#JGW8 MVMZKJ?OPK:96JE.RK'`NR@+=49F$WQ.UAC:V0HZ*)C:5$Q)55E?HIYIJ`I3J MAB7Z]9W9P%\C_]'?V^/_'OT`0K_#_ZTA__=X9?6._[OC_^[XOSO^[X[_^ROY M/^%I_M4Z/,+H=^7'C>]59>?J+!JEU?(XATBLH9E0R!U^^PVQAS=90=Y&J&\O M6D+>1C,XRWFY5]G32M2\/\>]EAE&-T.59P>O6OOMPU\L)?4754[*+H=X1<.RJJERN]TGA\W1`%]7U/4&.[0.1 MH41Z''$8A8^!S@7+0DCW+#BY?R(4$-1)VFFGPZM>T!:'>>0P$R86JC^6C%2\[\&OIJ7U2Y?2&[;OL;_$H]O+R,&3:(X]8?2\O+ MZ4`R13W41<(7Y%G3.!E&O8&A-!,>4$,8;U;>29EZW:D%DQX\D!>Z;T&897P_ MH1/Y375\^+JUH6&B:K.B""^.7'S_OJ"I-C?54GU)515@6ZK0MRH!+Z6P!D$? M5W1.SD(7/BQY2^L2\-G+UD??3I+`.]\PF4],9HWF"^YU8%6H\6O5E"6G:IRZ8\7OI>MXGP4'%N"RW/U.89K[NF0!`5J&``\> MR+#C;NETT%BLHEID,U;+M[550"Y3)B@N$\SNC\".BS%@C.`7@7LVJW7/BC%] M-JUUI\5E3F>CNM-)K9L#W/DXN'-D!2:!M+F&\:0\Y[.K34VUZ>S,QTOK MN$26CQ-/AXTHZX51+!1Q?>2BXPOL:AZL/EECZ!<&%9X3JL)[F8DW>R^E:2%, M@!TZE^&PLE*=@/,?!NH?TQHH&Y+.>ZI12(>P>22P*\'>+Q;#]U+UINZ]@S\G M^,?'/YTWT:C_#I]:"B,JD\$JLH?X*^,,:7%/\< MXY\_LL#"/F!8QS,72$3:P5-=KK1YEUM3#.U02L%WO,:IYZP?1U1PCEJSV-+%32F]R"3Q/K`#'#;#N6VYE!4T[8?>&O^G@P0/!,;]^CJ^W M4()H'$S*&>1RYI'&2[+Z7G1%&L<467Z\LB>..C]Q.A`/6!_?BY;0\++7JP%W M2K6:[@M[/X!B(A&<,-V`7X&\G/+*`_-6YD1=D(PX-3`KM&^QDCA M1"UJQ1D96?)203+V"8HU'L4GDD`;%C_('.%'PFX&".AX`Z225C-P.G&)!D

A>>A9) MIBQ%`4#01Y4S"=A7T&*2,&,)%&$`.!PJ4*03>XDOD"SZ^56?VT%#A];R2@9* M=0.0X-6^J'+>3"B9RE8W4/AP\@.IAIG,N?7@2XK>",E\G]C<%-?0I2(ET5=` MJJ1':,2C_'IH0/!\8VV_K`XB??S@@B0?!&@\BW"LAW<$.#LM1:B!]I1*D,WO#Z@1 M^`TE2!@D\+>-;GNPE)H=H*;V7^_MZ8PX:#CS)G]7(BC!"I?$;CD]]@VQB.0: MQG=8%873;PLG0F!KC`)=J502,`+P M^.!!]9-F,8RPHT?!.[7RZ[V5'R_?#H4[BWIO/KQKT*C1+R[AKH5D"WEY1L@H MFEB/M'KNJ!1=4(Z8685%OHT8?ZT4;ACIO%2"Q>X(TUUE" M&=U^#64LHS,+5]\>#6"$MD\P&+J2CH5!P-<^XNV7)APZ>AZH$=XOBLI4LM6A MR3?L>A'NV5$0=-BR7^*%Q^<-)Y^S-X30*2M5W16?[*9<,)"E-\8&<`U!4UL@ M?S\]@R5;VB7SK5IE1L4RAER=;'Q(%"!&1>BTO%R][..-D#Z@IS,S085DYEHL M&,=".STU,9?+>4BY_VXCI0FR[VM%"LV-D.<&=H.,&17"Y%"?'->@RG?(3+JJYE&^;WDKQNM1T3=4QJIG>/5,SLZ(! M=G34V_AK>A[S%.F-IBW4);/0*EII>=J\`_QQ'Z,HCBN7]RYY_"L>[5)A?4N6 M7O.N5U]D78OT2&/CTGBZH5:5FP/24JKO#_9Z'[VK5%\86D^"'OOP&8(2204/ M##N<00Q&E_F@06Q=]+V-3%GI@TP;C%:4$-LE>0?ON2BCWJULSDCH$@Q6_"ZU ME\C$@HT_D:Q\8(.M6`9A!;FZ@&^K`$8'%+B>SP6CJK0,1>#987&(CJ)'-I(>,PS(!+LL)9=U=WV&VCZY MHNB?>@LK-RAF*E.,[$JD8(Z;+:R!&X1+[*C-AP55U9J=AT5+KNV"=:7L<#$[21$V>I04U,=JB$ZL MZCZ./ITS2P0U1EN*0(LG<4)=J#<1A M]!6E-\M/M MR@JEXX8=OZQZP#^T'KLG1/JC96`Q:"9PH%1F(_,)A:F!48H00\8&6HGW$6HL MP7_9[Q=!,U=D$?ZGOCT2$5 MHT'#1U$N`&<;H3?OJ7J"1*_AW9,U.NS;4L,1PLXH:[1:Y10KKZC[C+1A-91Y M7X7_N`FTMJXJ9S>&'`W(V,8*!^XL?KBFQQ9QA#C^<=(Q4*>(70'U=T3["T%Q MD7%0U'CU1:"H"!\$9;F(L>WA:/OEJ[V6NT%D=X@!"VU"&>(BI>S+C1V17S M%:4<+6MYBM1R[3*JY?&]HZ0U&R6MIJ";R-&7._'-5]3%8.C>*^A][.H`[_N/.03,K-:M;J>B91!&* M3,TU<\9>K6;V@Q*K-C+3K53$EV/'"I^;0:F*RD:9(3A!8#(85CR;4:9(M4B> MRC+CU(1A'.-U!`G%/CT)9(&D-)(L)F.,:C>C2`!*-GKQ1Q@]WM\]AN$\ M8[!C.[@0\%H:*@+JAF==FGA?`H@+Y2!%/DX[@*1_\T#"0@+'5=*V!2U]?EYQ M&@W?NO+X^3,.:Z<9E";/GS];M.@[/575%)$IC.B:B2%9")-1U&F8P!(\;S?) MP.H"$9SAWF9DD0^)4)<,_#!J1JJZ&2:?[8NQC)QD]"J%\#15FGJP8H]JU";! M-N0J+(7;$W,QAH#UXJF@Q3NM)]]TRFK0RL!>F"ZOC:^RCG(,%EJS#KW#I46: M30LLODJ#S#NAS?8"N.1J,M7L4*F9T;$QK2[;EP3;Z3)\-VNZSE2SZ;/@ZCX5 MN*:[,G`-VO/`M-0'1M3TBK/SV`PUFVX$V;P8:_G+W-8@6PF,@H$6&K(LTS(F MV1U!#')@G??PJL&F)N MV5-=/0H?XB,E89G!&S?SE@$:`RW,5?-YC7V`5&XRRM!UV'*S0CA94>FC'FQF M\*2M?O8TP3C_OTV>)=0U[W#S9W[\'IU>X=_$PS-_6`)@;-!9C-5S.#2WXFNN M9;5Q9*>/'&!$`(N*@6P@3H+D:JO-.1]RP9F3/F'_S3$>_&&.U65*Y&.!^EHK MWM@D+),$V'(:/`R*)`%E)0%FCM(-#N>B+(*PW7PLTP`1QD5E.!?; MD$D[C'-^1>1!TG2!7PF2#3*]I0!<7CJ4CTKT`%)@#SI+&LDN@+`U?(I`5$'L^H6R2`OBZ2+[2=-%KG9SO#D#2&*Q5W3U1 M+>/'Y<&:7<&(!H-5JU%\`H4<_:*S[:B]UM'1\8OM_0);(!?"UF0(SP];V\>M MPW$@DM[Z/Z^W]XX/=$O&M1I%TAVUQ!Z6FH53J]\,&^F>T5C>LD*6V?K$1%6B MW,*!Z55WFR^$-U&9ESLZX<)JX"_Q"9#1]AH%GEF+IAP$T9^QXPXIF#WPP%6O M9`5C;*R>HPQ=QA*)J"2AZO427JHDKQHN#3-J/;&6R%:_GZ01<6EVBH3,";BN M::&@_B9\A_R+1?!:=V(XMDP7G+,),8GNHRBX'`0^FD:T#IXI[W0H>Q]U MFJ8O4F'F,YU0KX=Y7G;_`+V][#]RNZ[2,Z,PY-I6.Z MF0A/.X;=)`C(S#)5GA3#M('?(XN2`8#PO0@@4$&2+/%J;FBJKC4!#@<=!V`= M3ZZ088)T!)<275?8,(6>5UD/FJ(JX6.DM?S6!ZD3>A2W62ETH^UY`[H[<82< M/F2DPNCFXT5^``@-/P9!)!I5O&B>PV6>)IZO;V2Q&S>5I5N*PE14&'X2=,(A M&_.[S6"R02T)'FL-=3,L\6@`2=OF_;GMET^?U9?]/KN%+[ZP\$4&>S24KG_9 M[T$&=6V#X.(%[:EO4:,^/ZF72O*L\A_@.5/&@ISV*ODMU@]*4U^=YOYNH/Q> MFOKZYW#"B2(6,'ZW-./=H/5,_,0NO$LYAPR2H=SZ*7.:;$6B`/W)3_G>,E&F M)^F0A_/'V)[3H`&HC&!<4G&&F.'>U7.S[Z7G-9D*HQ0K)A,4DN/H8D/,%J(5 M($X*K_-AE`Z=XG0'8JK0'4BT_!8LX4BG)!B=\V3DGP=#,5U!W7\G,`$9!4N> MS7&0XH$0S3980X=AC[E:/'5B(+`8[-)UA!_$%M>X_/%B8NYCQ",`F<)F#:J) MNQQ[`.&.^Q$-;J!Q79`C"0`(PU>$LVR5B"82'3TY1TG101B'[\4\!``A$?GU MFE6AH\N/Y-?'*VL-;5$O*,`E\>(9@\MQZ0[MD3ZXMDF^3[PK;PEX564)?>'U MGIK1BI5@O-5PJ&T4``T+2PC>A6FRSM7T`N:X>HG-A(Q6I(G8FP)U4=8F*2!O M4I'"6,/M7!1!=951(U)BTVZ\D*X-3K+#<\P"HZ8^L+]7,6="%!3%'N_[VKZ7 M$^0$WK5X0$+B=;JDN7H@N"T3OU?"37$\"3!YH-A@GBR@-Y7TV\V.9IS!\HY6 M$^+^$046`_R<%(!9:`2@KL*?<>XRC`E58()D0)6,K=\'HG[>WL](=7H'W!13 MOC0CBLEPD=0'JVXZGQ.*:3H.!)HH.,4P9$:H[R;+L!-\G(M&WA2RFA<(S-_@ M[TV'K-CT)QJ_JI:LC#]'IGJNR*D]PM&+P/5B6E"O)!56W5-;F[KUIFYW6.&[ M7BDV53^,$%\SOZI`]+YW6:%9K)O@BJVZZ)8(`PNEW.`R.0L&EXPMZYB6&5L5 M'$_U+?J+?ZJH<*/;,.^=BG,!<+&"@%9)ETJ.66?3U<,;_$WC,@7X((R_Z$8M MLT]"DZ=43=?%,JH9P;DA+/#T."Z&Y4P!1ZHM5E).)%S&S#5#.IE&]TY)R.*W MB6K%:[[\-K/0?OL-C@2OIDZJ!W)2-7)NQKP2& MUA=4LC5?)3G77Z"W/Z+PWD3ZCLL]..)!!69:2C>GBA^*0]%J+6.P+J%O`,8H M96__<BD?7&6!LQ\W`8&&VR@0R,`87K@&=X#3$- MR3$MCN(MNW.-[_:BG(UZ)4>=F]V%&6@[/FT3MC/R(+)FGZ;E7&O\'(6?Z/MX M8(N&+]7"MKSSZ]CI6AX=M@0=U+>DO&SJ57?N9;'+EWA`:H.C]O%!>^?@::L0 M`OF0Y"I^HK)P)YI43I_7N8GM]-<[&G$HF@JFM.7"P)73+:MWP3FSZE$31))\<#( M.:DIJE4`O?^,,(##%;:`G=-3/6\98<>#!-$R1JG5C`I1NZ@;CQ4"A>?^7`A? MT_N_'#UK8SCM/;'Z#4_U_2`5'H>3O4\J]SK5=476W.1&YQE"TU[3;J-VLMW& M)[Q.%9^X9GW.KR,X%"`M)H=":Z9\UI\!Z=]C+18;(CJ>*KEL=)^VM=\?U-1] MZ32Q@62S7?S00.WP1A$=D'(K&272N&:C+>?]$`@4??\.>A4 M4Z%+*G>(J6T0[7CL8XPS.XZT5`FC+S[WKD!.K1R@+(GN';V@KSY*JH"A6PC( M+2MCW,ICJE$U`\\V?I,:GQUNXAV:01"H0HY9=J1OJ+H'>^L52;H<-P!OY%7J M*%:T$2ZE.):DO%!>0XL6 MFAF3)X^9TFPB:J3J]S#-Y9JJA&S M_1*9=TO^$BX,I?>+2WA"CON+ZGD@FO6,K5H`V[Z_&*%WR;RA>XQ3; M/QL%,GN4:A>.I081QKXO+KFVBF.3U6KCF6#HI9=>`1/13T5KB[VT0TI3:'2" MS!;VGA/GA/0ZJ%=">@@!=?>S";RVEG=MT-,`QC-=+80N@Z0]99+I@]EEZ"\8 M)#KLD/8;3?18EQN5\`:70)9?O$`>TU(]C*AZR$&.4O!_/T@P$A;4&`4^L(P8 M7`N]>M417FV%M\U3Z*:C471PI!XU5@5,A=@Y\L`DKT@=QIDY/E0XT6U'I"_J MA!G`89G0CTS99)^ MD#&D7@5)UQO@/=C.,M'W.H'2P:)Q+1B?,'891IT0ACXKGO4WPI MM*"DJ%`POO7&AWJO`'B[L\Z)XHC5QCI!C!(0=[P;<>2=!=Q;W$]F&:$>TQI& M"EV)1AATRB#%21O()L!0M=ZL&L!_??C9'R9Z`[7S#-B."$\0W>6XW&ZWSZ)1 M6X9R!U;PUU]OVC'_+Q'U<>WL7_OXO_>!?_\2[^XUW\Q[\H_B.=OF%L MQ*'7C8-&M[1:%-G;1(K4$01HD8"A+F>#Q!'2>5\/:&8L,\>TFO&`-%?2Y>_Q MS/04I0U6WXW;VKE%R4<6+7_X.+&JH?"Y*/=JSGZ"SG2=DP8!54&_5D=12O(' MCE@<[<$ES.W(G!Q M)WSDB1,_\FZCNOO=_>Y^=[^[W]WO[G?WN_O=_>Y^=[^[W]WO[G?WN_O=_>Y^ 7=[^[W]WO[G?WN_O-]?N_HU"3U@"@!0#W ` end From ericy@cais.com Sun May 15 11:50:00 1994 From: ericy@cais.com (Eric Youngdale) Date: Sun, 15 May 1994 11:50:00 -0000 Subject: PE format executable information Message-ID: <9405151847.AA12885@cais.com> Does anyone have a good reference for the format of Win32 executables (also known as PE format binaries)? The reason I ask is that I would like to start in on Win32 support to Wine by accumulating the information required to pick apart Win32 binaries. -Eric From artk@congruent.com Sun May 15 13:06:00 1994 From: artk@congruent.com (Arthur Kreitman) Date: Sun, 15 May 1994 13:06:00 -0000 Subject: PE format executable information References: <9405151847.AA12885@cais.com> Message-ID: <9405151957.AA09801@Congruent.COM> > Does anyone have a good reference for the format of Win32 executables > (also known as PE format binaries)? Look in the file ntimage.h (its part of the windows nt sdk) From raeburn@cygnus.com Wed May 18 10:50:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 18 May 1994 10:50:00 -0000 Subject: problem with diffs Message-ID: <199405181748.NAA01960@cujo.cygnus.com> Due to a disk filling last night, the diffs generated are bogus; don't try to use them. The snapshot itself should be okay. From raeburn@cygnus.com Wed May 18 12:51:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 18 May 1994 12:51:00 -0000 Subject: ready to release? Message-ID: <199405181950.PAA06019@cujo.cygnus.com> I'll be checking in a couple of last-minute VMS related fixes shortly, and a fix to the gas install rule; they'll be in tonight's snapshot. I don't think there's anything else urgent that needs fixing for this release. If no one finds any new serious problems, I'll release gas-2.3 and binutils-2.4 on Friday. Please try it out if you haven't done so recently. From mellon@ncd.com Wed May 18 14:33:00 1994 From: mellon@ncd.com (Ted Lemon) Date: Wed, 18 May 1994 14:33:00 -0000 Subject: ready to release? References: <199405181950.PAA06019@cujo.cygnus.com> Message-ID: <199405182132.OAA03654@pepper.ncd.com> Okay, so I'm a ditz. I can't remember the name of the private/whatever directory where I can get the snapshot. Sigh. This is the one bug with automatic, unannounced snapshots, I guess... Could you re-clue me? _MelloN_ From raeburn@cygnus.com Wed May 18 15:11:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 18 May 1994 15:11:00 -0000 Subject: ready to release? References: <199405182132.OAA03654@pepper.ncd.com> Message-ID: <199405182210.SAA10510@cujo.cygnus.com> The snapshots are in private/jelly on ftp.cygnus.com. From raeburn@cygnus.com Wed May 18 16:32:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 18 May 1994 16:32:00 -0000 Subject: pushing up gas/binutils release Message-ID: <199405182330.TAA12168@cujo.cygnus.com> Okay. Since CD-ROM deadline is Thursday, I'll try to do the release that night instead of Friday. It's still dependent on no one finding serious problems. ------- Start of forwarded message ------- Date: Wed, 18 May 94 18:50:03 -0400 From: rms@gnu.ai.mit.edu (Richard Stallman) To: raeburn@cygnus.com Subject: Re: ready to release? If no one finds any new serious problems, I'll release gas-2.3 and binutils-2.4 on Friday. The tape has to start spinning around noon on Friday. I think that means you should make the release Thursday night. ------- End of forwarded message ------- From ericy@cais.com Wed May 18 21:08:00 1994 From: ericy@cais.com (Eric Youngdale) Date: Wed, 18 May 1994 21:08:00 -0000 Subject: pushing up gas/binutils release References: <199405182330.TAA12168@cujo.cygnus.com> Message-ID: <9405190405.AA18351@cais.com> >Okay. Since CD-ROM deadline is Thursday, I'll try to do the release >that night instead of Friday. It's still dependent on no one finding >serious problems. My own feeling is that the release schedules and the cdrom pressing deadlines should be completely decoupled. This way each maintainer can release something when it is believed to be ready and not push something out the door without adequate testing just to meet a deadline. I realize that you want to always have the latest and greatest on each disc, but the end user only cares if it works. I wonder whether you end up shooting yourself in the foot by advancing release dates. -Eric From law@snake.cs.utah.edu Wed May 18 21:24:00 1994 From: law@snake.cs.utah.edu (Jeffrey A Law) Date: Wed, 18 May 1994 21:24:00 -0000 Subject: Interesting Message-ID: <7492.769321376@snake.cs.utah.edu> Is gas-2.3 only supposed to build with gnu-make? Using 4.4 make on a PA I get: rm -f bfd.h-new 64 ../include/bfd.h grep BFD_HOST_64_BIT sysdep.h > 64 2>/dev/null || exit 0 *** Error code 1 cute. Jeff From law@snake.cs.utah.edu Wed May 18 22:13:00 1994 From: law@snake.cs.utah.edu (Jeffrey A Law) Date: Wed, 18 May 1994 22:13:00 -0000 Subject: More bad news Message-ID: <7716.769324339@snake.cs.utah.edu> hpux8.07: hppa1.1-hp-hpux: [law@easy /n/snake/u/law/tmp/gas-940518] /bin/make Make: line 819: syntax error. Stop. Line 819: $(INSTALL_LAST): install-dirs I note that INSTALL_LAST is never set to any value in the Makefile Jeff From raeburn@cygnus.com Wed May 18 23:07:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 18 May 1994 23:07:00 -0000 Subject: pushing up gas/binutils release References: <9405190405.AA18351@cais.com> Message-ID: <199405190605.CAA12231@cujo.cygnus.com> For the most part, I agree. If it weren't a matter of just one day, I'd ignore the CD-ROM deadline. (I wasn't particularly aiming for it in the first place.) And in any case, these packages will not be released before the deadline if I do not feel they are ready. Naturally, since saying I'd try to get it out Thursday, I've received about a half dozen messages, with patches or describing minor problems. I still need to go through the latest ones more carefully and see if any are serious enough to warrant pushing it off another couple days. Some of the patches to come in have been installed, and some are not necessary to have in before the release. From raeburn@cygnus.com Wed May 18 23:23:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 18 May 1994 23:23:00 -0000 Subject: Interesting References: <7492.769321376@snake.cs.utah.edu> Message-ID: <199405190621.CAA12235@cujo.cygnus.com> Date: Wed, 18 May 94 22:22:56 MDT From: Jeffrey A Law Is gas-2.3 only supposed to build with gnu-make? No, it should work with as many versions as possible without requiring unreasonable amounts of work. Using 4.4 make on a PA I get: rm -f bfd.h-new 64 ../include/bfd.h grep BFD_HOST_64_BIT sysdep.h > 64 2>/dev/null || exit 0 *** Error code 1 cute. Jeff This was the result of a few rounds of changes. The intent is that the results of grep are always used, regardless of the exit status, and that the "error code 1" message shouldn't be displayed, even with "(ignored)", because it may cause confusion. Some versions of make don't pass the whole line to one shell invocation if you use a semicolon instead of "||", so a nonzero exit status from grep aborts the build. Most versions of make will display the "ignored error" messages if you use a "-" prefix instead of the "exit 0". Keeping these in mind, how can I shut up BSD4.4 make too? Does this work for you? if grep BFD_HOST_64_BIT sysdep.h > 64 2>/dev/null ; then true; \ else true; fi If it does, I'll try it out on some of the other systems, and other versions of make. From law@snake.cs.utah.edu Wed May 18 23:36:00 1994 From: law@snake.cs.utah.edu (Jeffrey A Law) Date: Wed, 18 May 1994 23:36:00 -0000 Subject: Minor patch for hpux8 Message-ID: <8041.769329293@snake.cs.utah.edu> The HPUX 8 compilers have annoyingly small tablesizes compiled into the pre-processor. This patch should fix the too much defining problems in bfd/som.c and bfd/hpux-core.c * mh-hpux (CC): Add -Wp,-H256000 to avoid "too much defining" errors from the HPUX 8 compilers. *** /tmp/RCSA008037 Thu May 19 00:34:24 1994 --- config/mh-hpux Thu May 19 00:25:53 1994 *************** *** 1,4 **** --- 1,5 ---- # Define SYSV as -DSYSV if you are using a System V operating system. + CC = cc -Wp,-H256000 SYSV = -DSYSV RANLIB = true From law@snake.cs.utah.edu Thu May 19 00:00:00 1994 From: law@snake.cs.utah.edu (Jeffrey A Law) Date: Thu, 19 May 1994 00:00:00 -0000 Subject: Another patch Message-ID: <8179.769330750@snake.cs.utah.edu> These two bugfixes went into devo just after the gas-2.4 branch was made. They should probably be included in gas-2.4 [ The first avoids writing an incorrect object file, the second avoids an abort in the assembler. ] bfd/ChangeLog: * libhppa.h (hppa_field_adjust): Avoid adding constant_value into the final value twice for LR and RR field selectors. gas/ChangeLog: * config/tc-hppa.c (pa_parse_fp_cmp_cond): Report an error on a partial completer match. Index: bfd/libhppa.h =================================================================== RCS file: /rel/cvsfiles/devo/bfd/libhppa.h,v retrieving revision 1.19 retrieving revision 1.21 diff -c -r1.19 -r1.21 *** bfd/libhppa.h 1994/03/19 03:54:42 1.19 --- bfd/libhppa.h 1994/05/16 16:41:39 1.21 *************** *** 308,327 **** unsigned long constant_value; unsigned short r_field; { - value += constant_value; switch (r_field) { case e_fsel: /* F : no change */ break; case e_lssel: /* LS : if (bit 21) then add 0x800 arithmetic shift right 11 bits */ if (value & 0x00000400) value += 0x800; value = (value & 0xfffff800) >> 11; break; case e_rssel: /* RS : Sign extend from bit 21 */ if (value & 0x00000400) value |= 0xfffff800; else --- 308,329 ---- unsigned long constant_value; unsigned short r_field; { switch (r_field) { case e_fsel: /* F : no change */ + value += constant_value; break; case e_lssel: /* LS : if (bit 21) then add 0x800 arithmetic shift right 11 bits */ + value += constant_value; if (value & 0x00000400) value += 0x800; value = (value & 0xfffff800) >> 11; break; case e_rssel: /* RS : Sign extend from bit 21 */ + value += constant_value; if (value & 0x00000400) value |= 0xfffff800; else *************** *** 329,348 **** --- 331,354 ---- break; case e_lsel: /* L : Arithmetic shift right 11 bits */ + value += constant_value; value = (value & 0xfffff800) >> 11; break; case e_rsel: /* R : Set bits 0-20 to zero */ + value += constant_value; value = value & 0x7ff; break; case e_ldsel: /* LD : Add 0x800, arithmetic shift right 11 bits */ + value += constant_value; value += 0x800; value = (value & 0xfffff800) >> 11; break; case e_rdsel: /* RD : Set bits 0-20 to one */ + value += constant_value; value |= 0xfffff800; break; Index: gas/config/tc-hppa.c =================================================================== RCS file: /rel/cvsfiles/devo/gas/config/tc-hppa.c,v retrieving revision 1.86 retrieving revision 1.87 diff -c -r1.86 -r1.87 *** gas/config/tc-hppa.c 1994/05/16 19:29:56 1.86 --- gas/config/tc-hppa.c 1994/05/17 18:54:50 1.87 *************** *** 3293,3305 **** { cond = fp_cond_map[i].cond; *s += strlen (fp_cond_map[i].string); while (**s == ' ' || **s == '\t') *s = *s + 1; return cond; } } ! as_bad ("Invalid FP Compare Condition: %c", **s); return 0; } --- 3293,3317 ---- { cond = fp_cond_map[i].cond; *s += strlen (fp_cond_map[i].string); + /* If not a complete match, back up the input string and + report an error. */ + if (**s != ' ' && **s != '\t') + { + *s -= strlen (fp_cond_map[i].string); + break; + } while (**s == ' ' || **s == '\t') *s = *s + 1; return cond; } } ! as_bad ("Invalid FP Compare Condition: %s", *s); ! ! /* Advance over the bogus completer. */ ! while (**s != ',' && **s != ' ' && **s != '\t') ! *s += 1; ! return 0; } From law@snake.cs.utah.edu Thu May 19 00:25:00 1994 From: law@snake.cs.utah.edu (Jeffrey A Law) Date: Thu, 19 May 1994 00:25:00 -0000 Subject: Interesting References: <199405190621.CAA12235@cujo.cygnus.com> Message-ID: <8722.769332210@snake.cs.utah.edu> From: Ken Raeburn Subject: Re: Interesting The intent is that the results of grep are always used, regardless of the exit status, and that the "error code 1" message shouldn't be displayed, even with "(ignored)", because it may cause confusion. Reasonable. Does this work for you? if grep BFD_HOST_64_BIT sysdep.h > 64 2>/dev/null ; then true; \ else true; fi Yes. It works with 4.4, 4.4-lite, hpux8, hpux9 & gnumake 3.62 Jeff From ian@cygnus.com Thu May 19 07:57:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Thu, 19 May 1994 07:57:00 -0000 Subject: Interesting References: <7492.769321376@snake.cs.utah.edu> Message-ID: <9405191455.AA00467@tweedledumb.cygnus.com> Date: Wed, 18 May 94 22:22:56 MDT From: Jeffrey A Law Is gas-2.3 only supposed to build with gnu-make? Using 4.4 make on a PA I get: rm -f bfd.h-new 64 ../include/bfd.h grep BFD_HOST_64_BIT sysdep.h > 64 2>/dev/null || exit 0 *** Error code 1 While I agree with Ken's proposed change, this has to be a bug in the PA make program. How can the above expression yield an error status of anything but zero? Ian From law@snake.cs.utah.edu Thu May 19 08:09:00 1994 From: law@snake.cs.utah.edu (Jeffrey A Law) Date: Thu, 19 May 1994 08:09:00 -0000 Subject: Interesting References: <9405191455.AA00467@tweedledumb.cygnus.com> Message-ID: <13304.769360070@snake.cs.utah.edu> From: Ian Lance Taylor Subject: Interesting Date: Wed, 18 May 94 22:22:56 MDT From: Jeffrey A Law Is gas-2.3 only supposed to build with gnu-make? Using 4.4 make on a PA I get: rm -f bfd.h-new 64 ../include/bfd.h grep BFD_HOST_64_BIT sysdep.h > 64 2>/dev/null || exit 0 *** Error code 1 While I agree with Ken's proposed change, this has to be a bug in the PA make program. How can the above expression yield an error status of anything but zero? No doubt about it. It's certainly not the first bug we've found in 4.4 make (most of which appear to have been fixed in time for 4.4-lite). Jeff From raeburn@cygnus.com Thu May 19 13:27:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Thu, 19 May 1994 13:27:00 -0000 Subject: please try this patch Message-ID: <199405192025.QAA16711@cujo.cygnus.com> These changes (relative to last night's snapshot on ftp.cygnus.com in /private/jelly) will affect: - top-level make (nuked INSTALL_LAST stuff) - bfd.h generation (avoiding a bug in bsd4.4 make, hopefully not hitting any others) - vms hosted or targeted execution and debugging - hpux 8 native-cc builds - mips bsd (4.4) linking - hppa linking Please test them and let me know how they work for you, today if possible. (If you sent them to me, please make sure I got them right. If you didn't send me the patches, but use one of the configurations above, please confirm that it works.) If I get some positive feedback today, I'll go ahead with the release tonight. Otherwise, I'll push it off a bit longer. Index: Makefile.in =================================================================== RCS file: /rel/cvsfiles/devo/Makefile.in,v retrieving revision 1.341.2.1 diff -c -r1.341.2.1 Makefile.in *** Makefile.in 1994/05/11 06:04:57 1.341.2.1 --- Makefile.in 1994/05/19 06:26:40 *************** *** 117,124 **** $(INSTALL_MODULES) \ $(INSTALL_TARGET_MODULES) \ $(INSTALL_X11_MODULES) \ ! install-gcc \ ! $(INSTALL_LAST) CC_FOR_TARGET = ` \ --- 117,123 ---- $(INSTALL_MODULES) \ $(INSTALL_TARGET_MODULES) \ $(INSTALL_X11_MODULES) \ ! install-gcc CC_FOR_TARGET = ` \ *************** *** 793,813 **** srcroot=`cd $(srcdir); pwd`; export srcroot; \ (cd gcc; $(MAKE) $(GCC_FLAGS_TO_PASS) install); \ else \ - true; \ - fi - - - # EXPERIMENTAL STUFF - # This rule is used to install the modules which use FLAGS_TO_PASS. - # To build a target install-X means to cd to X and make install. - .PHONY: $(INSTALL_LAST) - $(INSTALL_LAST): install-dirs - @dir=`echo $@ | sed -e 's/install-//'`; \ - if [ -f ./$${dir}/Makefile ] ; then \ - r=`pwd`; export r; \ - srcroot=`cd $(srcdir); pwd`; export srcroot; \ - (cd $${dir}; $(MAKE) $(FLAGS_TO_PASS) install); \ - else \ true; \ fi --- 792,797 ---- Index: bfd/ChangeLog =================================================================== RCS file: /rel/cvsfiles/devo/bfd/ChangeLog,v retrieving revision 1.1155.2.5 diff -c -r1.1155.2.5 ChangeLog *** ChangeLog 1994/05/17 18:23:39 1.1155.2.5 --- ChangeLog 1994/05/19 19:40:50 *************** *** 1,3 **** --- 1,17 ---- + Thu May 19 13:56:47 1994 Ken Raeburn (raeburn@cujo.cygnus.com) + + From Ralph Campbell: + * mipsbsd.c (mips_fix_jmp_addr): If symbol is undefined, return an + error. + (mips_fix_hi16_s): Ditto. + + * Makefile.in (stmp-bfd.h): Wrap `if' block around grep + invocation, to avoid a bug in BSD 4.4 make. + + From Jeff Law: + * libhppa.h (hppa_field_adjust): Avoid adding constant_value into + the final value twice for LR and RR field selectors. + Mon May 16 12:02:07 1994 Ken Raeburn (raeburn@cujo.cygnus.com) * configure.bat: Do use CR-LF for line termination. Index: bfd/Makefile.in =================================================================== RCS file: /rel/cvsfiles/devo/bfd/Makefile.in,v retrieving revision 1.211.2.4 diff -c -r1.211.2.4 Makefile.in *** Makefile.in 1994/05/13 19:56:37 1.211.2.4 --- Makefile.in 1994/05/19 18:00:34 *************** *** 474,482 **** # The file ../include/bfd.h is from earlier attempts to get this right. # If the file is still there, kill it. stmp-bfd.h : $(srcdir)/bfd-in2.h Makefile rm -f bfd.h-new 64 ../include/bfd.h ! grep BFD_HOST_64_BIT sysdep.h > 64 2>/dev/null || exit 0 sed -e 's/@WORDSIZE@/$(WORDSIZE)/' \ -e "s/@VERSION@/`cat $(srcdir)/VERSION`/" \ -e '/64-bit.*sysdep.h/ r 64' \ --- 474,486 ---- # The file ../include/bfd.h is from earlier attempts to get this right. # If the file is still there, kill it. + # The weird sh*t with grep is to avoid printing "exit 1 (ignored)" type + # messages from make, and avoid various ways in which different versions + # of make will screw up exit status checks. stmp-bfd.h : $(srcdir)/bfd-in2.h Makefile rm -f bfd.h-new 64 ../include/bfd.h ! if grep BFD_HOST_64_BIT sysdep.h > 64 2>/dev/null ; then true; \ ! else true; fi sed -e 's/@WORDSIZE@/$(WORDSIZE)/' \ -e "s/@VERSION@/`cat $(srcdir)/VERSION`/" \ -e '/64-bit.*sysdep.h/ r 64' \ Index: bfd/libhppa.h =================================================================== RCS file: /rel/cvsfiles/devo/bfd/libhppa.h,v retrieving revision 1.19 diff -c -r1.19 libhppa.h *** libhppa.h 1994/03/19 03:54:42 1.19 --- libhppa.h 1994/05/19 17:56:05 *************** *** 308,327 **** unsigned long constant_value; unsigned short r_field; { - value += constant_value; switch (r_field) { case e_fsel: /* F : no change */ break; case e_lssel: /* LS : if (bit 21) then add 0x800 arithmetic shift right 11 bits */ if (value & 0x00000400) value += 0x800; value = (value & 0xfffff800) >> 11; break; case e_rssel: /* RS : Sign extend from bit 21 */ if (value & 0x00000400) value |= 0xfffff800; else --- 308,329 ---- unsigned long constant_value; unsigned short r_field; { switch (r_field) { case e_fsel: /* F : no change */ + value += constant_value; break; case e_lssel: /* LS : if (bit 21) then add 0x800 arithmetic shift right 11 bits */ + value += constant_value; if (value & 0x00000400) value += 0x800; value = (value & 0xfffff800) >> 11; break; case e_rssel: /* RS : Sign extend from bit 21 */ + value += constant_value; if (value & 0x00000400) value |= 0xfffff800; else *************** *** 329,348 **** --- 331,354 ---- break; case e_lsel: /* L : Arithmetic shift right 11 bits */ + value += constant_value; value = (value & 0xfffff800) >> 11; break; case e_rsel: /* R : Set bits 0-20 to zero */ + value += constant_value; value = value & 0x7ff; break; case e_ldsel: /* LD : Add 0x800, arithmetic shift right 11 bits */ + value += constant_value; value += 0x800; value = (value & 0xfffff800) >> 11; break; case e_rdsel: /* RD : Set bits 0-20 to one */ + value += constant_value; value |= 0xfffff800; break; Index: bfd/mipsbsd.c =================================================================== RCS file: /rel/cvsfiles/devo/bfd/mipsbsd.c,v retrieving revision 1.20 diff -c -r1.20 mipsbsd.c *** mipsbsd.c 1994/05/05 19:50:26 1.20 --- mipsbsd.c 1994/05/19 19:40:38 *************** *** 200,205 **** --- 200,210 ---- if (output_bfd != (bfd *)NULL) return bfd_reloc_continue; + /* If this is an undefined symbol, return error */ + if (symbol->section == &bfd_und_section + && (symbol->flags & BSF_WEAK) == 0) + return bfd_reloc_undefined; + /* * Work out which section the relocation is targetted at and the * initial relocation command value. *************** *** 249,254 **** --- 254,264 ---- if (output_bfd != (bfd *)NULL) return bfd_reloc_continue; + /* If this is an undefined symbol, return error */ + if (symbol->section == &bfd_und_section + && (symbol->flags & BSF_WEAK) == 0) + return bfd_reloc_undefined; + /* * Work out which section the relocation is targetted at and the * initial relocation command value. Index: config/mh-hpux =================================================================== RCS file: /rel/cvsfiles/devo/config/mh-hpux,v retrieving revision 1.3 diff -c -r1.3 mh-hpux *** mh-hpux 1993/06/16 00:08:20 1.3 --- mh-hpux 1994/05/19 17:49:18 *************** *** 1,4 **** --- 1,5 ---- # Define SYSV as -DSYSV if you are using a System V operating system. + CC = cc -Wp,-H256000 SYSV = -DSYSV RANLIB = true Index: gas/ChangeLog =================================================================== RCS file: /rel/cvsfiles/devo/gas/ChangeLog,v retrieving revision 1.660.2.6 diff -c -r1.660.2.6 ChangeLog *** ChangeLog 1994/05/18 23:47:10 1.660.2.6 --- ChangeLog 1994/05/19 19:52:54 *************** *** 1,3 **** --- 1,40 ---- + Thu May 19 13:45:59 1994 Ken Raeburn (raeburn@cujo.cygnus.com) + + From Ian Taylor: + * config/tc-sparc.c (md_section_align): Don't change the size if + OBJ_ELF. + + * config/obj-vms.c: Replaced unchecked uses of malloc with + xmalloc. + + From Jeff Law: + * config/tc-hppa.c (pa_parse_fp_cmp_cond): Report an error + on a partial completer match. + + Wed May 18 20:50:35 1994 Pat Rankin (rankin@eql.caltech.edu) + + * config/obj-vms.h (DBG_S_C_SQUAD, DBG_S_C_UQUAD): define these + new VMS symbol-type macros; signed and unsigned quadword integers, + for `long long' support. Their values come from the existing + DSC$K_DTYPE_QU and DSC$K_DTYPE_Q macros in . The + VMS debugger now recognizes `long long' variables correctly. + config/obj-vms.c (VMS_typedef_parse) [case 'r']: add entries + for gcc2's predefined types "long double" (same as double, as + per gcc's current state), "long long int", "long long unsigned + int", and final `otherwise' case (to avoid uninitialized type + and size fields). [caveat: predefined types "complex int", + "complex float", "complex double", and "complex long double" are + still missing.] + + * config/ho-vms.h (EXIT_FAILURE): define as 0x10000002 instead + of 0, because the latter indicates success rather than failure + when passed to `exit' or return from `main' compiled by gcc2. + + * config/obj-vms.c (array_suffix, generate_suffix): replace two + hardcoded `0xa3's with macro DBG_S_C_ADVANCED_TYPE from obj-vms.h. + (VMS_typedef_parse): eliminate redundant if-then-else when + allocating new symbol entry and linking it to VMS_Symbol_type_list. + Wed May 18 15:32:35 1994 Ken Raeburn (raeburn@cujo.cygnus.com) * listing.c (list_symbol_table): Only test BFD64, not Index: gas/NEWS =================================================================== RCS file: /rel/cvsfiles/devo/gas/NEWS,v retrieving revision 1.12 diff -c -r1.12 NEWS *** NEWS 1994/03/15 02:56:20 1.12 --- NEWS 1994/05/19 17:33:08 *************** *** 10,16 **** based on mail received from various people. The `-h#' option should work again too. ! HP-PA work, by Jeff Law. Vax support in gas fixed for BSD, so it builds and seems to run a couple simple tests okay. I haven't put it through extensive testing. (GNU make is --- 10,20 ---- based on mail received from various people. The `-h#' option should work again too. ! HP-PA work, by Jeff Law. Note, for the PA, gas-2.3 has been designed to work ! with gdb-4.12 and gcc-2.6. As gcc-2.6 has not been released yet, a special ! version of gcc-2.5.8 has been patched to work with gas-2.3. You can retrieve ! this special version of gcc-2.5.8 via anonymous ftp from jaguar.cs.utah.edu ! in the "dist" directory. Vax support in gas fixed for BSD, so it builds and seems to run a couple simple tests okay. I haven't put it through extensive testing. (GNU make is Index: gas/config/ho-vms.h =================================================================== RCS file: /rel/cvsfiles/devo/gas/config/ho-vms.h,v retrieving revision 1.4.2.1 diff -c -r1.4.2.1 ho-vms.h *** ho-vms.h 1994/05/18 19:58:54 1.4.2.1 --- ho-vms.h 1994/05/19 17:41:54 *************** *** 28,35 **** #include #ifndef EXIT_SUCCESS ! #define EXIT_SUCCESS 1 ! #define EXIT_FAILURE 0 #endif #define unlink delete --- 28,35 ---- #include #ifndef EXIT_SUCCESS ! #define EXIT_SUCCESS 1 /* SS$_NORMAL, STS$K_SUCCESS */ ! #define EXIT_FAILURE 0x10000002 /* (STS$K_ERROR | STS$M_INHIB_MSG) */ #endif #define unlink delete Index: gas/config/obj-vms.c =================================================================== RCS file: /rel/cvsfiles/devo/gas/config/obj-vms.c,v retrieving revision 1.15.2.2 diff -c -r1.15.2.2 obj-vms.c *** obj-vms.c 1994/05/18 23:50:29 1.15.2.2 --- obj-vms.c 1994/05/19 17:50:39 *************** *** 1428,1434 **** break; } } ! fpnt = (struct input_file *) malloc (sizeof (struct input_file)); if (file_root == (struct input_file *) NULL) file_root = fpnt; else --- 1428,1434 ---- break; } } ! fpnt = (struct input_file *) xmalloc (sizeof (struct input_file)); if (file_root == (struct input_file *) NULL) file_root = fpnt; else *************** *** 1639,1645 **** } total_size = total_size * spnt1->data_size; push (spnt1->data_size, 2); ! if (spnt1->VMS_type == 0xa3) push (0, 1); else push (spnt1->VMS_type, 1); --- 1639,1645 ---- } total_size = total_size * spnt1->data_size; push (spnt1->data_size, 2); ! if (spnt1->VMS_type == DBG_S_C_ADVANCED_TYPE) push (0, 1); else push (spnt1->VMS_type, 1); *************** *** 1675,1681 **** int dbx_type; { struct forward_ref *fpnt; ! fpnt = (struct forward_ref *) malloc (sizeof (struct forward_ref)); fpnt->next = f_ref_root; f_ref_root = fpnt; fpnt->dbx_type = dbx_type; --- 1675,1681 ---- int dbx_type; { struct forward_ref *fpnt; ! fpnt = (struct forward_ref *) xmalloc (sizeof (struct forward_ref)); fpnt->next = f_ref_root; f_ref_root = fpnt; fpnt->dbx_type = dbx_type; *************** *** 1809,1815 **** new_forward_ref (dbx_type); else { ! if (spnt->VMS_type != 0xa3) return 0; /* no suffix needed */ gen1 (spnt, 0); } --- 1809,1815 ---- new_forward_ref (dbx_type); else { ! if (spnt->VMS_type != DBG_S_C_ADVANCED_TYPE) return 0; /* no suffix needed */ gen1 (spnt, 0); } *************** *** 2344,2361 **** /* first we see if this has been defined already, due to a forward reference*/ if (spnt == (struct VMS_DBG_Symbol *) NULL) { ! if (VMS_Symbol_type_list == (struct VMS_DBG_Symbol *) NULL) ! { ! spnt = (struct VMS_DBG_Symbol *) malloc (sizeof (struct VMS_DBG_Symbol)); ! spnt->next = (struct VMS_DBG_Symbol *) NULL; ! VMS_Symbol_type_list = spnt; ! } ! else ! { ! spnt = (struct VMS_DBG_Symbol *) malloc (sizeof (struct VMS_DBG_Symbol)); ! spnt->next = VMS_Symbol_type_list; ! VMS_Symbol_type_list = spnt; ! } spnt->dbx_type = i1; /* and save the type */ } /* for structs and unions, do a partial parse, otherwise we sometimes get --- 2344,2352 ---- /* first we see if this has been defined already, due to a forward reference*/ if (spnt == (struct VMS_DBG_Symbol *) NULL) { ! spnt = (struct VMS_DBG_Symbol *) xmalloc (sizeof (struct VMS_DBG_Symbol)); ! spnt->next = VMS_Symbol_type_list; ! VMS_Symbol_type_list = spnt; spnt->dbx_type = i1; /* and save the type */ } /* for structs and unions, do a partial parse, otherwise we sometimes get *************** *** 2450,2458 **** --- 2441,2472 ---- } else if (type_check ("double")) { + /* caveat: this assumes D_float, and is not correct for G_float */ + spnt->VMS_type = DBG_S_C_REAL8; + spnt->data_size = 8; + } + else if (type_check ("long double")) + { + /* same as double, at least for now */ spnt->VMS_type = DBG_S_C_REAL8; spnt->data_size = 8; } + else if (type_check ("long long int")) + { + spnt->VMS_type = DBG_S_C_SQUAD; /* signed quadword */ + spnt->data_size = 8; + } + else if (type_check ("long long unsigned int")) + { + spnt->VMS_type = DBG_S_C_UQUAD; /* unsigned quadword */ + spnt->data_size = 8; + } + else + { + /* something more substantial ought to be done here */ + spnt->VMS_type = 0; + spnt->data_size = 0; + } pnt1 = (char *) strchr (str, ';') + 1; break; case 's': *************** *** 2729,2735 **** pnt = str + strlen(str) - 1; } while (*pnt == '?'); tlen += strlen(str); ! parse_buffer = (char *) malloc (tlen + 1); strcpy(parse_buffer, S_GET_NAME (sp)); pnt2 = parse_buffer + strlen(S_GET_NAME (sp)) - 1; *pnt2 = '\0'; --- 2743,2749 ---- pnt = str + strlen(str) - 1; } while (*pnt == '?'); tlen += strlen(str); ! parse_buffer = (char *) xmalloc (tlen + 1); strcpy(parse_buffer, S_GET_NAME (sp)); pnt2 = parse_buffer + strlen(S_GET_NAME (sp)) - 1; *pnt2 = '\0'; *************** *** 3770,3776 **** if (!HAS_PSECT_ATTRIBUTES (Name)) continue; ! stripped_name = (char *) malloc (strlen (Name) + 1); strcpy (stripped_name, Name); Psect_Attributes = 0; VMS_Modify_Psect_Attributes (stripped_name, &Psect_Attributes); --- 3784,3790 ---- if (!HAS_PSECT_ATTRIBUTES (Name)) continue; ! stripped_name = (char *) xmalloc (strlen (Name) + 1); strcpy (stripped_name, Name); Psect_Attributes = 0; VMS_Modify_Psect_Attributes (stripped_name, &Psect_Attributes); Index: gas/config/obj-vms.h =================================================================== RCS file: /rel/cvsfiles/devo/gas/config/obj-vms.h,v retrieving revision 1.8 diff -c -r1.8 obj-vms.h *** obj-vms.h 1994/03/11 23:07:26 1.8 --- obj-vms.h 1994/05/19 17:46:55 *************** *** 421,431 **** #define DBG_S_C_UCHAR 0x02 #define DBG_S_C_USINT 0x03 #define DBG_S_C_ULINT 0x04 #define DBG_S_C_SCHAR 0x06 #define DBG_S_C_SSINT 0x07 #define DBG_S_C_SLINT 0x08 #define DBG_S_C_REAL4 0x0a ! #define DBG_S_C_REAL8 0x0b #define DBG_S_C_FUNCTION_ADDR 0x17 #define DBG_S_C_ADVANCED_TYPE 0xa3 /* These are the codes that are used to generate the definitions of struct --- 421,433 ---- #define DBG_S_C_UCHAR 0x02 #define DBG_S_C_USINT 0x03 #define DBG_S_C_ULINT 0x04 + #define DBG_S_C_UQUAD 0x05 #define DBG_S_C_SCHAR 0x06 #define DBG_S_C_SSINT 0x07 #define DBG_S_C_SLINT 0x08 + #define DBG_S_C_SQUAD 0x09 #define DBG_S_C_REAL4 0x0a ! #define DBG_S_C_REAL8 0x0b /* D_float (G_float is 0x1b) */ #define DBG_S_C_FUNCTION_ADDR 0x17 #define DBG_S_C_ADVANCED_TYPE 0xa3 /* These are the codes that are used to generate the definitions of struct Index: gas/config/tc-hppa.c =================================================================== RCS file: /rel/cvsfiles/devo/gas/config/tc-hppa.c,v retrieving revision 1.85 diff -c -r1.85 tc-hppa.c *** tc-hppa.c 1994/04/24 07:14:02 1.85 --- tc-hppa.c 1994/05/19 17:56:12 *************** *** 3435,3447 **** { cond = fp_cond_map[i].cond; *s += strlen (fp_cond_map[i].string); while (**s == ' ' || **s == '\t') *s = *s + 1; return cond; } } ! as_bad ("Invalid FP Compare Condition: %c", **s); return 0; } --- 3435,3459 ---- { cond = fp_cond_map[i].cond; *s += strlen (fp_cond_map[i].string); + /* If not a complete match, back up the input string and + report an error. */ + if (**s != ' ' && **s != '\t') + { + *s -= strlen (fp_cond_map[i].string); + break; + } while (**s == ' ' || **s == '\t') *s = *s + 1; return cond; } } ! as_bad ("Invalid FP Compare Condition: %s", *s); ! ! /* Advance over the bogus completer. */ ! while (**s != ',' && **s != ' ' && **s != '\t') ! *s += 1; ! return 0; } Index: gas/config/tc-sparc.c =================================================================== RCS file: /rel/cvsfiles/devo/gas/config/tc-sparc.c,v retrieving revision 1.86.2.2 diff -c -r1.86.2.2 tc-sparc.c *** tc-sparc.c 1994/05/17 18:37:46 1.86.2.2 --- tc-sparc.c 1994/05/19 19:52:32 *************** *** 1737,1750 **** segT segment; valueT size; { ! /* This may or may not be right for ELF; a.out wants it, and COFF ! will force the alignment anyways. */ valueT align = (valueT) 1 << (valueT) (stdoutput->xvec->align_power_min); valueT newsize; /* turn alignment value into a mask */ align--; newsize = (size + align) & ~align; return newsize; } /* Exactly what point is a PC-relative offset relative TO? --- 1737,1754 ---- segT segment; valueT size; { ! #ifndef OBJ_ELF ! /* This is not right for ELF; a.out wants it, and COFF will force ! the alignment anyways. */ valueT align = (valueT) 1 << (valueT) (stdoutput->xvec->align_power_min); valueT newsize; /* turn alignment value into a mask */ align--; newsize = (size + align) & ~align; return newsize; + #else + return size; + #endif } /* Exactly what point is a PC-relative offset relative TO? From gnu@cygnus.com Thu May 19 15:53:00 1994 From: gnu@cygnus.com (John Gilmore) Date: Thu, 19 May 1994 15:53:00 -0000 Subject: PE format executable information: yes! References: <9405151847.AA12885@cais.com> Message-ID: <199405192253.PAA21851@cygnus.com> There is a group called the Tool Interface Standards committee that produced a solid spec for PE, publicly available (on paper, at least). I don't know where to get a copy of the spec online. Cygnus tried to join the group, but never heard back from them. Here's my notes. John Gilmore Open Systems Today, March 1, 1993. Committee is Borland, IBM, Intel, Lotus, MetaWare, Microsoft, SCO, Watcom. Contact: David Bernstein, director of technology at SCO. Volume 1: Portable executable format (from Windows NT) and STI (symbol and type information). Volume 2: ELF, DWARF, and OMF. Version 1.0 of the standard is free of charge on request. Available from Intel. +1 800 548 4725 Order # 241-597 Takes 7-10 working days. Ordered 3/15/93. John Arrived from: Tool Interface Standards c/o Intel Corporation RN6-30 2200 Mission College Blvd. Santa Clara, CA 95052 signature space left for "Secretary, TIS Committee", but not signed. "The TIS Committee is an open forum in which corporations can provide leadership for advancing the PC software market. The Committee welcomes participation by new company members. Interested companies can learn more about TIS by using Intel ACCESS on CompuServe." John From robertl@arnet.com Thu May 19 16:20:00 1994 From: robertl@arnet.com (Robert Lipe) Date: Thu, 19 May 1994 16:20:00 -0000 Subject: PE format executable information: yes! References: <199405192253.PAA21851@cygnus.com> Message-ID: <9405191817.aa00879@caddy.arnet.com> I hate people that listen to a conversation and then say, "Yeah, I knew that." This just didn't sound familiar then. Sorry. John Gilmore writes: > There is a group called the Tool Interface Standards committee that > produced a solid spec for PE, publicly available (on paper, at least). > I don't know where to get a copy of the spec online. If you're talking about that I think you're talking about, ftp.intel.com:/pub/IAL/TIS contains some of this stuff. >Volume 1: Portable executable format (from Windows NT) and STI (symbol > and type information). My guess is this is portable_formats/pf11p.gps > Volume 2: ELF, DWARF, and OMF. -rw-r--r-- 1 71 50 120951 Mar 25 00:58 dwf11.zip -rw-r--r-- 1 71 50 76670 Mar 25 00:58 elf11g.zip -rw-r--r-- 1 71 50 112573 Mar 25 00:58 omf11g.zip drwxr-xr-x 2 71 50 512 Mar 25 00:58 portable_formats -rw-r--r-- 1 71 50 187651 Mar 25 00:58 sym10g.zip drwxr-xr-x 2 71 50 512 Mar 25 00:58 windows_formats I don't remember how I stumbled across this, but it's in my mrolo under Intel. Hope this helps someone. -- Robert Lipe, Sr. Software Engr, Arnet Corp. robertl@arnet.com From artk@congruent.com Fri May 20 08:11:00 1994 From: artk@congruent.com (Arthur Kreitman) Date: Fri, 20 May 1994 08:11:00 -0000 Subject: PE format executable information: yes! References: <9405191817.aa00879@caddy.arnet.com> Message-ID: <9405201459.AA05418@Congruent.COM> > My guess is this is portable_formats/pf11p.gps That file contains only a cover page. The rest must be an exercize for the reader. Intel's intent for TIS was on binary/debugging format that would be used by all x86 tools vendors. They picked dwarf for that format, ignoring the dos market that used omf, and the emerging nt/win32 market which is coff'ish. There was a recent issue of "Microsoft Systems Journal" that went into the PE is some detail. I don't remember the issue date. From raeburn@cygnus.com Fri May 20 23:11:00 1994 From: raeburn@cygnus.com (raeburn@cygnus.com) Date: Fri, 20 May 1994 23:11:00 -0000 Subject: gas-2.3, binutils-2.4 released Message-ID: <199405210555.BAA24486@cujo.cygnus.com> I just sent off the announcements. Sometime this weekend or Monday I'll work on merging some of the later changes back into the Cygnus main sources, and get the snapshots going from the latest development sources again. Don't expect to see much new for a couple days or so. From raeburn@cygnus.com Thu Jun 2 09:27:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Thu, 02 Jun 1994 09:27:00 -0000 Subject: devo snapshots resuming Message-ID: <199406021627.JAA21517@rtl.cygnus.com> I think I've got all the important bits of the gas-2.3/binutils-2.4 release into the mainline sources now, so I've switched the snapshot mechanism back. Starting tonight, the snapshots will reflect the ongoing development. And I'll be trying to get more of the patches I've been sent incorporated. Please let me know if I missed anything... Ken From raeburn@cygnus.com Thu Jun 2 18:09:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Thu, 02 Jun 1994 18:09:00 -0000 Subject: [Ian Lance Taylor: SunOS shared library support] Message-ID: <199406030110.VAA25807@cujo.cygnus.com> This should be in tonight's snapshot. Check it out! ------- Start of forwarded message ------- From: Ian Lance Taylor Date: Thu, 2 Jun 94 20:13:50 EDT To: bfd@cygnus.com, hackers@cygnus.com Subject: SunOS shared library support I've added SunOS shared library support to the linker. It will now link programs against shared libraries by default. Linking PIC code is not supported. I don't even know what the linker is supposed to do with PIC code. As usual, this hasn't been tested too extensively, though the linker is able to bootstrap itself, and gdb seems to pretty much understand the results. I'd be interested in hearing about any problems. Ian ------- End of forwarded message ------- From hjl@nynexst.com Mon Jun 6 09:55:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Mon, 06 Jun 1994 09:55:00 -0000 Subject: Lynxos with gnu binutils/gas Message-ID: <9406061654.AA02658@titanic.nynexst.com> Hi, It looks the new gnu binutils/gas support lynxos. Any plan to configure gcc 2.6.0 to use them? At least a new config/lynx.h is needed for it. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From shebs@cygnus.com Mon Jun 6 10:40:00 1994 From: shebs@cygnus.com (Stan Shebs) Date: Mon, 06 Jun 1994 10:40:00 -0000 Subject: Lynxos with gnu binutils/gas References: <9406061654.AA02658@titanic.nynexst.com> Message-ID: <199406061739.KAA17656@andros.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Mon, 6 Jun 94 12:55:48 EDT It looks the new gnu binutils/gas support lynxos. Any plan to configure gcc 2.6.0 to use them? At least a new config/lynx.h is needed for it. We have all the support working well here (new lynx.h, etc), but I haven't submitted it to Kenner yet. It's a little messy because Lynx is now defaulting to coff format for all the latest gnu tools, but you should still be able to use gcc with the older versions of the tools, which do a.out normally, and so you have to specify --with-gnu-as to get the coff- compatible configuration for gcc. If you're in a hurry, I can mail you the relevant config files. Stan From raeburn@cygnus.com Thu Jun 16 17:48:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Thu, 16 Jun 1994 17:48:00 -0000 Subject: merging gas into binutils? Message-ID: <199406170048.UAA08348@cujo.cygnus.com> A suggestion has been made to merge gas into the binutils package, meaning there'd be only one distribution. It's an idea that's occurred to me before. And of course it's what I'm already doing for the nightly snapshots, though they're going under the name `gas' at the moment rather than `binutils'. That would make it about 2/3 the size of the current two packages, with bfd &c duplicated. On the other hand, it means someone wanting to pick up gas alone would have to download a bit more. The linker has got SunOS shared library support added (linking against them, not creating them), and other nifty new features. So that at least is no longer an argument for using gas but not the rest of binutils (specifically the linker). Offhand I don't know of a situation where you'd want binutils but not gas, though there may be one or two targets supported by binutils but not gas. And of course people would still have the option of only installing some of the programs distributed as `binutils'. Does anyone see a good reason why I shouldn't just combine them, and release `binutils 2.5, including assembler and linker' sometime? Ken From meissner@osf.org Fri Jun 17 07:36:00 1994 From: meissner@osf.org (Michael Meissner) Date: Fri, 17 Jun 1994 07:36:00 -0000 Subject: merging gas into binutils? References: <199406170048.UAA08348@cujo.cygnus.com> <199406170048.UAA08348@cujo.cygnus.com> Message-ID: <9406171436.AA07931@pasta.osf.org> | | A suggestion has been made to merge gas into the binutils package, | meaning there'd be only one distribution. It's an idea that's | occurred to me before. And of course it's what I'm already doing for | the nightly snapshots, though they're going under the name `gas' at | the moment rather than `binutils'. | | That would make it about 2/3 the size of the current two packages, | with bfd &c duplicated. On the other hand, it means someone wanting | to pick up gas alone would have to download a bit more. | | The linker has got SunOS shared library support added (linking against | them, not creating them), and other nifty new features. So that at | least is no longer an argument for using gas but not the rest of | binutils (specifically the linker). Offhand I don't know of a | situation where you'd want binutils but not gas, though there may be | one or two targets supported by binutils but not gas. And of course | people would still have the option of only installing some of the | programs distributed as `binutils'. | | Does anyone see a good reason why I shouldn't just combine them, and | release `binutils 2.5, including assembler and linker' sometime? I would say that ok, provided either the old gas tar files get removed from prep, or a symlink is created from binutils-2.5.tar.gz to gas-2.5.tar.gz is made. From bgb@psp.att.com Fri Jun 17 10:13:00 1994 From: bgb@psp.att.com (bgb@psp.att.com) Date: Fri, 17 Jun 1994 10:13:00 -0000 Subject: merging gas into binutils? Message-ID: <9406171713.AA21287@ig1.att.att.com> > A suggestion has been made to merge gas into the binutils package, > meaning there'd be only one distribution. It's an idea that's > occurred to me before. I doesn't really bother me to pick up two packages instead of one. What has been bothering me are the (configuration) inconsistencies between the gas, binutils, and gdb packages. At least the last time I tried, the three packages seemed to not be very harmonious in how they were configured. BTW, This is not complaining. You guys do a great job. Brian Beuning From tower@gnu.ai.mit.edu Fri Jun 17 14:44:00 1994 From: tower@gnu.ai.mit.edu (tower@gnu.ai.mit.edu) Date: Fri, 17 Jun 1994 14:44:00 -0000 Subject: merging gas into binutils? References: <9406171436.AA07931@pasta.osf.org> Message-ID: <9406172144.AA08963@nutrimat.gnu.ai.mit.edu> From: Michael Meissner Date: Fri, 17 Jun 94 10:36:06 -0400 | | A suggestion has been made to merge gas into the binutils package, | meaning there'd be only one distribution. It's an idea that's | occurred to me before. And of course it's what I'm already doing for | the nightly snapshots, though they're going under the name `gas' at | the moment rather than `binutils'. | | That would make it about 2/3 the size of the current two packages, | with bfd &c duplicated. On the other hand, it means someone wanting | to pick up gas alone would have to download a bit more. | | The linker has got SunOS shared library support added (linking against | them, not creating them), and other nifty new features. So that at | least is no longer an argument for using gas but not the rest of | binutils (specifically the linker). Offhand I don't know of a | situation where you'd want binutils but not gas, though there may be | one or two targets supported by binutils but not gas. And of course | people would still have the option of only installing some of the | programs distributed as `binutils'. | | Does anyone see a good reason why I shouldn't just combine them, and | release `binutils 2.5, including assembler and linker' sometime? I would say that ok, provided either the old gas tar files get removed from prep, or a symlink is created from binutils-2.5.tar.gz to gas-2.5.tar.gz is made. We'll remove the old files when they are no longer useful to people or we need the space. And add a gas.README that explains the merge. best -len From ralphc@pyramid.com Tue Jun 21 22:23:00 1994 From: ralphc@pyramid.com (Ralph Campbell) Date: Tue, 21 Jun 1994 22:23:00 -0000 Subject: bug fixes for gas-2.3/binutils-2.4 Message-ID: <9406220524.AA29248@pyrps5.eng.pyramid.com> I have made a few bug fixes for the gas-2.3/binutils-2.4 release for the "configure mips-dec-bsd" case. Some of these changes are common to all architectures and some just to mips. bfd/aoutx.h 1) minor optimization to ignore debug symbols 2) fix test for subsections for a.out format opcodes/mips-dis.c This is a major performance boost. Helps when disassembling whole programs. ld/scripttempl/mipsbsd.sc minor cleanup. ld/ldlang.c The following command will fail to produce the correct relocation table entries. "ld -x -r -Ttext 1000 -o t.o t1.o" This is because .text has an expression to set the section vma but at the end, the test for updating dot is wrong so if the next section doesn't have an explicit address expression (or the expression is '.') it gets its vma set to the vma of .text. *** bfd/aoutx.h.old Thu Apr 21 10:00:44 1994 --- bfd/aoutx.h Sun Jun 19 23:42:10 1994 *************** *** 3050,3056 **** struct bfd_link_hash_entry *h; /* Ignore symbols that are not externally visible. */ ! if ((type & N_EXT) == 0) { if (type == N_WARNING || type == N_INDR) --- 3050,3056 ---- struct bfd_link_hash_entry *h; /* Ignore symbols that are not externally visible. */ ! if ((type & N_STAB) || (type & N_EXT) == 0 || type == N_FN) { if (type == N_WARNING || type == N_INDR) *************** *** 3383,3389 **** drsize = 0; for (sub = info->input_bfds; sub != (bfd *) NULL; sub = sub->link_next) { ! if (bfd_get_flavour (abfd) == bfd_target_aout_flavour) { trsize += exec_hdr (sub)->a_trsize; drsize += exec_hdr (sub)->a_drsize; --- 3383,3389 ---- drsize = 0; for (sub = info->input_bfds; sub != (bfd *) NULL; sub = sub->link_next) { ! if (bfd_get_flavour (sub) == bfd_target_aout_flavour) { trsize += exec_hdr (sub)->a_trsize; drsize += exec_hdr (sub)->a_drsize; *** opcodes/mips-dis.c.old Mon Nov 8 09:40:03 1993 --- opcodes/mips-dis.c Sun Jun 19 17:02:40 1994 *************** *** 186,215 **** struct disassemble_info *info; unsigned long int word; { - register int i; register const char *d; ! for (i = 0; i < NUMOPCODES; i++) { ! if (mips_opcodes[i].pinfo != INSN_MACRO) { ! register unsigned int match = mips_opcodes[i].match; ! register unsigned int mask = mips_opcodes[i].mask; ! if ((word & mask) == match) ! break; ! } } ! ! /* Handle undefined instructions. */ ! if (i == NUMOPCODES) { ! (*info->fprintf_func) (info->stream, "0x%x", word); ! return 4; } ! (*info->fprintf_func) (info->stream, "%s", mips_opcodes[i].name); ! if (!(d = mips_opcodes[i].args)) return 4; (*info->fprintf_func) (info->stream, " "); --- 186,234 ---- struct disassemble_info *info; unsigned long int word; { register const char *d; + register const struct mips_opcode *op; + static int init; + static const struct mips_opcode *mips_hash[OP_MASK_OP + 1]; ! (*info->fprintf_func) (info->stream, "0x%08x ", word); ! ! /* Build a hash table to shorten the search time */ ! if (!init) { ! do { ! for (op = mips_opcodes; op < &mips_opcodes[NUMOPCODES]; op++) ! { ! if (op->pinfo == INSN_MACRO) ! continue; ! if ((init << OP_SH_OP) == (op->match & (OP_MASK_OP << OP_SH_OP))) ! { ! mips_hash[init] = op; ! break; ! } ! } ! } ! while (++init <= OP_MASK_OP); } ! op = mips_hash[(word >> OP_SH_OP) & OP_MASK_OP]; ! if (op) { ! do ! { ! if (op->pinfo != INSN_MACRO && (word & op->mask) == op->match) ! goto fnd; ! } ! while (++op < &mips_opcodes[NUMOPCODES]); } + /* Handle undefined instructions. */ + (*info->fprintf_func) (info->stream, "0x%x", word); + return 4; ! fnd: ! (*info->fprintf_func) (info->stream, "%s", op->name); ! if (!(d = op->args)) return 4; (*info->fprintf_func) (info->stream, " "); *** ld/scripttempl/mipsbsd.sc.old Thu May 5 17:40:45 1994 --- ld/scripttempl/mipsbsd.sc Tue Jun 21 22:39:27 1994 *************** *** 11,23 **** *(.text) ${RELOCATING+etext = ${DATA_ALIGNMENT};} } ! .data ${RELOCATING+${DATA_ALIGNMENT}} : { *(.data) ${CONSTRUCTING+CONSTRUCTORS} ${RELOCATING+edata = .;} } ! .bss ${RELOCATING+SIZEOF(.data) + ADDR(.data)} : { *(.bss) *(COMMON) --- 11,23 ---- *(.text) ${RELOCATING+etext = ${DATA_ALIGNMENT};} } ! .data ${RELOCATING+${DATA_ALIGNMENT}} : { *(.data) ${CONSTRUCTING+CONSTRUCTORS} ${RELOCATING+edata = .;} } ! .bss : { *(.bss) *(COMMON) *** ld/ldlang.c.old Wed May 4 09:13:46 1994 --- ld/ldlang.c Tue Jun 21 22:37:55 1994 *************** *** 1722,1729 **** os->processed = true; /* Replace into region ? */ ! if (os->addr_tree == (etree_type *) NULL ! && os->region != (lang_memory_region_type *) NULL) { os->region->current = dot; /* Make sure this isn't silly */ --- 1722,1728 ---- os->processed = true; /* Replace into region ? */ ! if (os->region != (lang_memory_region_type *) NULL) { os->region->current = dot; /* Make sure this isn't silly */ From stuck@cs.man.ac.uk Wed Jun 22 08:08:00 1994 From: stuck@cs.man.ac.uk (Stuart Quick) Date: Wed, 22 Jun 1994 08:08:00 -0000 Subject: gas2-request Message-ID: <9406221508.AA06100@enki.cs.man.ac.uk.cs.man.ac.uk> gas2-request Please add me to the gas mailing list --- ***************************************************************** * Stuart V. Quick Operating Systems Group, * * Centre for Novel Computing, * * NeXTMail Accepted :-) Manchester University, * * United Kingdom. * ***************************************************************** From davidj@ICSI.Berkeley.EDU Fri Jul 8 17:50:00 1994 From: davidj@ICSI.Berkeley.EDU (David Johnson) Date: Fri, 08 Jul 1994 17:50:00 -0000 Subject: Bug in gas line no. info, --target=iris Message-ID: <199407090050.RAA15483@icsib68.ICSI.Berkeley.EDU> Problem ------- Gas appears to get the line number debugging information wrong for the last ".loc" pseudo-op in a source file. Also, if there's only one ".loc" pseudo-op in a file, it does not appear in the line number information. Version ------- GNU assembler version 940706 (iris), using BFD version cygnus-2.3 (also apparent in gas-2.3) Test program ------------ .file 1 "test.s" .text .ent test test: .loc 1 1 li $2, 1 .loc 1 2 li $2, 2 .end test Output (Using IRIX 4.0.5H) -------------------------- % as -g test.s -o test.o % mips-tdump -l test.o . . There are 2 bytes holding line numbers, starting at 220. Line 1, delta 0, count 1 Line 2, delta 1, count 1 . . % gas -g test.s -o test.o % mips-tdump -l test.o . . There are 2 bytes holding line numbers, starting at 320. Line 1, delta 0, count 1 Line 1, delta 0, count 16 . . ---------------------------------------------------------------- David Johnson International Computer Science Institute From ian@cygnus.com Fri Jul 8 21:06:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Fri, 08 Jul 1994 21:06:00 -0000 Subject: Bug in gas line no. info, --target=iris References: <199407090050.RAA15483@icsib68.ICSI.Berkeley.EDU> Message-ID: <9407090406.AA22879@tweedledumb.cygnus.com> From: davidj@ICSI.Berkeley.EDU (David Johnson) Date: Fri, 8 Jul 1994 17:50:37 -0700 Gas appears to get the line number debugging information wrong for the last ".loc" pseudo-op in a source file. Thanks for the bug report. I believe this this patch will fix the problem. Ian Index: ecoff.c =================================================================== RCS file: /rel/cvsfiles/devo/gas/ecoff.c,v retrieving revision 1.16 diff -p -r1.16 ecoff.c *** ecoff.c 1994/07/08 19:37:57 1.16 --- ecoff.c 1994/07/09 04:04:51 *************** ecoff_build_lineno (backend, buf, bufend *** 3600,3606 **** (in words). Do this first, so that we can skip ahead to the next useful line number entry. */ if (l->next == (lineno_list_t *) NULL) ! count = 0; else { count = ((l->next->frag->fr_address + l->next->paddr --- 3600,3610 ---- (in words). Do this first, so that we can skip ahead to the next useful line number entry. */ if (l->next == (lineno_list_t *) NULL) ! { ! /* We want a count of zero, but it will be decremented ! before it is used. */ ! count = 1; ! } else { count = ((l->next->frag->fr_address + l->next->paddr From raeburn@cygnus.com Mon Jul 11 11:57:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Mon, 11 Jul 1994 11:57:00 -0000 Subject: Snapshots broken again?? References: <9407111625.AA24736@tantalus.nrl.navy.mil> Message-ID: <199407111857.OAA20617@cujo.cygnus.com> Date: Mon, 11 Jul 94 12:25:31 EDT From: eric@tantalus.nrl.navy.mil (Eric Youngdale) The two latest sets of daily diffs between the snapshots were only 20 bytes - large enough for a compressed zero length file. It would appear that some changes did indeed occur if you look at the sizes of the full distributions. -Eric Yup. The usual deal, you "fix" a bug then disappear for the weekend... The snapshot script is a bit of a pain to debug; I'd planned on checking its progress on Saturday after letting it run automatically one night. I'm not sure what caused the zero-length *daily* diffs, but I fixed a bug in some revised handling the weekly diffs, and my test run seems to have generated both daily and weekly diffs okay. I re-did today's snapshot as part of the test, and I've manually build diffs from the 940709 snapshot. The original changes to the weekly diffs were intended to avoid the multi-week gap between them if the script failed to run to completion on Tuesday, the one night they were getting made. Now it ought to decide based on the age, with a preference for Tuesday night. From ericy@cais.cais.com Sat Jul 16 06:15:00 1994 From: ericy@cais.cais.com (Eric Youngdale) Date: Sat, 16 Jul 1994 06:15:00 -0000 Subject: ELF shared library status. Message-ID: <199407161307.JAA24794@cais.cais.com> OK, last night I finally got it working. I was able to use the GNU linker to generate an ELF shared library (the iBCS2 ELF libc for linux), and it actually works for everything I have thrown at it so far, including emacs and a couple of simpleminded X applications. I have already sent Ian the diffs, and when he gets some time (hopefully fairly soon) they will be integrated into the source tree at cygnus. One very interesting thing is that the library generated by GNU ld is about 33Kb smaller than the one generated by the SVr4 linker. I think the main reason for this is that the SVr4 linker has been generating a unified symbol table, and when you strip this binary it cannot remove the local symbols. The GNU linker has been generating two sets of symbol tables, and the .dynsym section only contains that which is needed for dynamic linking. Thus when you strip it, you end up with something that is much closer to the minimum size. There is one problem area - the debugging information needs some work in the relocations department - if you try and load the shared library into the debugger you get some nonsense messages from gdb. In principle this should not be that difficult to fix, and will only be an issue when you try and directly debug a shared library. There are a few new rough edges with some of the binutils - these should also be relatively easy to iron out. I have uploaded diffs (against the 940707 snapshot at cygnus) to tsx-11 in pub/linux/packages/GCC/private/dll/elflib??.diff or something close to that (I cannot remember the exact name). The only thing that is missing from this file are the patches to gas to accept PIC assembly operands (Ken has the patches, and will hopefully be integrated soon). So far, every test that I have run with the linker has used .o files generated by the SVr4 assembler - I only want to test/debug one tool at a time, thank you. I will be away from my computer most of the weekend :-). -Eric From rms@gnu.ai.mit.edu Sat Jul 16 09:50:00 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) Date: Sat, 16 Jul 1994 09:50:00 -0000 Subject: ELF shared library status. References: <199407161307.JAA24794@cais.cais.com> Message-ID: <9407161650.AA09979@mole.gnu.ai.mit.edu> This is important progress, because ELF is the format we want to use in the GNU system, and shared libraries are a vital feature for the system. From dj@ctron.com Wed Jul 20 07:10:00 1994 From: dj@ctron.com (DJ Delorie) Date: Wed, 20 Jul 1994 07:10:00 -0000 Subject: binutils/gas diffs for djgpp Message-ID: <9407201412.AA08617@delorie> Tue Jul 19 21:00:00 1994 DJ Delorie (dj@ctron.com) * configure.bat: the disassember needs to be enabled for "objdump -d" to work in djgpp. Note that all *.bat files should be stored and distributed with carriage returns at the end of each line (not shown here) for DOS to be able to run them. DJ - *** orig/binut-2.4/opcodes/configur.bat Tue Jul 19 23:05:22 1994 --- src/binut-2.4/opcodes/configur.bat Tue Jul 19 23:23:24 1994 *************** *** 10,16 **** echo "s/CC = cc/CC = gcc/ ">> config.sed echo "/^###$/ i\ ">> config.sed ! echo "BFD_MACHINES=i386-dis.o ">> config.sed echo "s/^[ ]*rm/ -rm/ ">> config.sed --- 10,17 ---- echo "s/CC = cc/CC = gcc/ ">> config.sed echo "/^###$/ i\ ">> config.sed ! echo "BFD_MACHINES=i386-dis.o\ ">> config.sed ! echo "ARCHDEFS=-DARCH_i386 ">> config.sed echo "s/^[ ]*rm/ -rm/ ">> config.sed From raeburn@cygnus.com Wed Aug 3 11:15:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 03 Aug 1994 11:15:00 -0000 Subject: snapshot problems Message-ID: <199408031815.OAA20155@cujo.cygnus.com> As some of you have noticed, the diffs produced in the last few days were pretty broken. My snapshot script wasn't correctly detecting when disk space ran out, so the diffs were against an incomplete source tree. This seems to be fixed (witness that there was no snapshot put up on Aug 2). I've deleted the bogus diffs. If you pick up a fresh set of sources, or if you apply the current weekly diffs to the 7/26 sources, you should be okay. From TRANLE@intellicorp.com Wed Aug 3 20:19:00 1994 From: TRANLE@intellicorp.com (Minh Tran-Le) Date: Wed, 03 Aug 1994 20:19:00 -0000 Subject: problem with ld and gnu emacs dump on i386-svr3 ... Message-ID: <199408040242.AA18142@bridge2.NSD.3Com.COM> Hi, I am using the latest gas-940803 snapshot under i386-aix (equivalent of svr3) and I am having problem with ld and emacs dumped image. The non dumped temacs works fine but the dumped emacs image get me the following error from the system: uprf(cmd: bash): 901-542 emacs: exec failed (errno = 91) bash: ./emacs: .lib section in executable is corrupted Has anybody succeed to use the latest ld under sco or interactive unix (another type of i386-svr3 than mine) to build emacs-19.25.9x ? The previous working ld I got was from around 31-may. Thanks, Minh Tran-Le. ------- From TRANLE@intellicorp.com Sun Aug 7 10:59:00 1994 From: TRANLE@intellicorp.com (Minh Tran-Le) Date: Sun, 07 Aug 1994 10:59:00 -0000 Subject: problem with ld (i386-coff) leaving holes in the executable ... Message-ID: <199408071759.KAA13172@cygnus.com> The latest GNU ld does not produce an executable with a consistent image header. If you take each section and add up its scnptr+scnsize it does not always match the scnptr of the next section with content. And this seems to confuse Emacs unexec which end up dumping the wrong content for the .lib section. Does anybody knows why the new ld leave holes in the executable ? Here is a testcase and output of dump using the old ld and the new ld. ===================== 1 mtranle@paris> cat foo.c #include main() { printf("hi\n"); } /* foo.good has been linked using GNU ld of may-31 */ 2 mtranle@paris> dump -h foo.good ***SECTION HEADER*** Name Paddr Vaddr Scnptr Relptr Lnnoptr Flags Size Nreloc Nlnno foo.good: .text 0x00000120 0x00000120 0x00000120 0x00000000 0x0000f80c 0x00000020 0x00009628 0 2 /* 0x120 + 0x9628 => 0x9748 */ .data 0x00400748 0x00400748 0x00009748 0x00000000 0x00000000 0x00000040 0x0000609c 0 0 /* 0x9748 + 0x609c => 0xf7e4 */ .bss 0x004067e4 0x004067e4 0x00000000 0x00000000 0x00000000 0x00000080 0x000027a4 0 0 .stab 0x00408f88 0x00408f88 0x00000000 0x00000000 0x00000000 0x00000200 0x00000000 0 0 .stabstr 0x00408f88 0x00408f88 0x00000000 0x00000000 0x00000000 0x00000200 0x00000000 0 0 /* .comment section scnptr 0xf7e4 */ .comment 0x00000000 0x00000000 0x0000f7e4 0x00000000 0x00000000 0x00000200 0x00000028 0 0 /* foo.bad has been linked using the latest GNU ld and scnptr + scnsize does not match the scnptr of the next section */ 3 mtranle@paris> dump -h foo.bad ***SECTION HEADER*** Name Paddr Vaddr Scnptr Relptr Lnnoptr Flags Size Nreloc Nlnno foo.bad: .text 0x000000d0 0x000000d0 0x000000d0 0x00000000 0x0000ff60 0x00000020 0x00009628 0 2 /* 0xd0 + 0x9628 => 0x96f8 */ .data 0x004006f8 0x004006f8 0x000096f8 0x00000000 0x00000000 0x00000040 0x0000609c 0 0 /* 0x96f8 + 0x609c => 0xf794 */ .bss 0x00406794 0x00406794 0x00000000 0x00000000 0x00000000 0x00000080 0x000027a4 0 0 /* 0xf794 does not match .comment scnptr. There is a gap between end of .data and beginning of .comment */ .comment 0x00408f38 0x00408f38 0x0000ff38 0x00000000 0x00000000 0x00000200 0x00000028 0 0 4 mtranle@paris> exit ================= Thanks, Minh Tran-Le. ------- From ian@cygnus.com Mon Aug 8 07:59:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Mon, 08 Aug 1994 07:59:00 -0000 Subject: problem with ld (i386-coff) leaving holes in the executable ... References: <199408071759.KAA13172@cygnus.com> Message-ID: <199408081459.KAA01744@sanguine.cygnus.com> Date: Sun, 7 Aug 94 10:57:26 PDT From: Minh Tran-Le The latest GNU ld does not produce an executable with a consistent image header. If you take each section and add up its scnptr+scnsize it does not always match the scnptr of the next section with content. And this seems to confuse Emacs unexec which end up dumping the wrong content for the .lib section. Does anybody knows why the new ld leave holes in the executable ? This was done because on a demand paged system, the file position of a section must match the page position within the executable file, modulo the page size. Forcing this alignment permits sections to be removed from the middle of the file, which is desirable when the debugging information is stored in a separate COFF section, as it is for stabs debugging information. However, this alignment is only required for sections which are allocated in memory. Could you please try this patch, and see if it fixes the problem? Ian *** coffcode.h.~15~ Wed Aug 3 10:22:07 1994 --- coffcode.h Mon Aug 8 10:48:52 1994 *************** coff_compute_section_file_positions (abf *** 1378,1384 **** #ifdef COFF_PAGE_SIZE /* In demand paged files the low order bits of the file offset must match the low order bits of the virtual address. */ ! if ((abfd->flags & D_PAGED) != 0) sofar += (current->vma - sofar) % COFF_PAGE_SIZE; #endif --- 1378,1385 ---- #ifdef COFF_PAGE_SIZE /* In demand paged files the low order bits of the file offset must match the low order bits of the virtual address. */ ! if ((abfd->flags & D_PAGED) != 0 ! && (current->flags & SEC_ALLOC) != 0) sofar += (current->vma - sofar) % COFF_PAGE_SIZE; #endif From TRANLE@intellicorp.com Mon Aug 8 20:11:00 1994 From: TRANLE@intellicorp.com (Minh Tran-Le) Date: Mon, 08 Aug 1994 20:11:00 -0000 Subject: problem with ld (i386-coff) leaving holes in the References: <199408081459.KAA01744@sanguine.cygnus.com> Message-ID: <199408090249.AA13574@bridge2.NSD.3Com.COM> Ian Lance Taylor wrote: | |This was done because on a demand paged system, the file position of a |section must match the page position within the executable file, |modulo the page size. Forcing this alignment permits sections to be |removed from the middle of the file, which is desirable when the |debugging information is stored in a separate COFF section, as it is |for stabs debugging information. | |However, this alignment is only required for sections which are |allocated in memory. Could you please try this patch, and see if it |fixes the problem? | |Ian | |*** coffcode.h.~15~ Wed Aug 3 10:22:07 1994 |--- coffcode.h Mon Aug 8 10:48:52 1994 |*************** coff_compute_section_file_positions (abf |*** 1378,1384 **** | #ifdef COFF_PAGE_SIZE | /* In demand paged files the low order bits of the file offset | must match the low order bits of the virtual address. */ |! if ((abfd->flags & D_PAGED) != 0) | sofar += (current->vma - sofar) % COFF_PAGE_SIZE; | #endif | |--- 1378,1385 ---- | #ifdef COFF_PAGE_SIZE | /* In demand paged files the low order bits of the file offset | must match the low order bits of the virtual address. */ |! if ((abfd->flags & D_PAGED) != 0 |! && (current->flags & SEC_ALLOC) != 0) | sofar += (current->vma - sofar) % COFF_PAGE_SIZE; | #endif | This patch seems to work fine for me on small executable but on emacs it still fail and still try to page align the `.comment' section. I made ld printout the section name and flags in the case it wants to page align it. section .text: flags 0x237 section .data: flags 0x247 section .comment: flags 0x10203 section .lib: flags 0x203 == output of: dump -h temacs == ***SECTION HEADER*** Name Paddr Vaddr Scnptr Relptr Lnnoptr Flags Size Nreloc Nlnno temacs: .text 0x00000148 0x00000148 0x00000148 0x00000000 0x0014e2a8 0x00000020 0x000e731c 0 2 .data 0x00400464 0x00400464 0x000e7464 0x00000000 0x00000000 0x00000040 0x00047bc4 0 0 .bss 0x00448028 0x00448028 0x00000000 0x00000000 0x00000000 0x00000080 0x00025ff8 0 0 /* page aligned here */ .comment 0x0046e020 0x0046e020 0x00130020 0x00000000 0x00000000 0x00000200 0x0001e270 0 0 .fkd800 0xd8000000 0xd8000000 0x00000000 0x00000000 0x00000000 0x00000022 0x0003a858 0 0 .lib 0x00000001 0x00000000 0x0014e290 0x00000000 0x00000000 0x00000800 0x00000018 0 0 .fkdc00 0xdc000000 0xdc000000 0x00000000 0x00000000 0x00000000 0x00000042 0x0000f28c 0 0 I have tried to comment out the code that was doing the page align and it cure the problem with emacs unexec without any adverse effect. Does all standard COFF linker do this page align thing ? Does emacs unexec work fine with them ? Thanks, Minh Tran-Le. ------- From ian@cygnus.com Tue Aug 9 06:58:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Tue, 09 Aug 1994 06:58:00 -0000 Subject: problem with ld (i386-coff) leaving holes in the References: <199408090249.AA13574@bridge2.NSD.3Com.COM> Message-ID: <199408091358.JAA03258@sanguine.cygnus.com> Date: Mon, 8 Aug 94 19:47:36 PDT From: Minh Tran-Le I made ld printout the section name and flags in the case it wants to page align it. section .text: flags 0x237 section .data: flags 0x247 section .comment: flags 0x10203 section .lib: flags 0x203 Can you find out what SEC_LOAD and SEC_ALLOC are set for all the sections? I don't see why they should be set for .comment or .lib. I have tried to comment out the code that was doing the page align and it cure the problem with emacs unexec without any adverse effect. Unfortunately, removing the code will break other cases. Does all standard COFF linker do this page align thing ? Does emacs unexec work fine with them ? Standard COFF linkers certainly do the page alignment in some form. In previous versions of the GNU linker, the page alignment was forced by the linker script. I added the code in coffcode.h to make the page alignment work when strip was used and it removed some sections. Ian From TRANLE@intellicorp.com Tue Aug 9 14:11:00 1994 From: TRANLE@intellicorp.com (Minh Tran-Le) Date: Tue, 09 Aug 1994 14:11:00 -0000 Subject: problem with ld (i386-coff) leaving holes in the References: <199408091358.JAA03258@sanguine.cygnus.com> Message-ID: <199408092045.AA17786@bridge2.NSD.3Com.COM> |Ian Lance Taylor wrote: | | Date: Mon, 8 Aug 94 19:47:36 PDT | From: Minh Tran-Le | | I made ld printout the section name and flags in the case it wants to | page align it. | | section .text: flags 0x237 | section .data: flags 0x247 | section .comment: flags 0x10203 | section .lib: flags 0x203 | |Can you find out what SEC_LOAD and SEC_ALLOC are set for all the |sections? I don't see why they should be set for .comment or .lib. Well looking at the function styp_to_sec_flags in coffcode.h it seems that it is setting the section flags to SEC_LOAD|SEC_ALLOC (line 462) for all styp_flags that it does not know about. For i386-aix, the .comment sections have either an styp of either 0x0 or 0x200 and the .lib sections have an styp of 0x800. So the function stype_to_sec_load will return for some of the .comment sections and all the .lib the value 0x3 which is SEC_LOAD|SEC_ALLOC. Maybe the function styp_to_sec_flags should not set the default section flags to SEC_LOAD|SEC_ALLOC. Minh Tran-Le. ------- From ian@cygnus.com Wed Aug 10 10:03:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Wed, 10 Aug 1994 10:03:00 -0000 Subject: problem with ld (i386-coff) leaving holes in the References: <199408092045.AA17786@bridge2.NSD.3Com.COM> Message-ID: <199408101703.NAA05133@sanguine.cygnus.com> Date: Tue, 9 Aug 94 13:43:16 PDT From: Minh Tran-Le Maybe the function styp_to_sec_flags should not set the default section flags to SEC_LOAD|SEC_ALLOC. I'm scared to make that change. I'm sure it would break on some system in a way that would be difficult to fix. How about the following (untested) patch instead? After installing this, do ``make headers'' in the bfd object directory to rebuild libcoff.h. Ian *** coffcode.h.~16~ Mon Aug 8 10:48:52 1994 --- coffcode.h Wed Aug 10 12:07:20 1994 *************** sec_to_styp_flags (sec_name, sec_flags) *** 405,413 **** * in sec_to_styp_flags(). */ static flagword ! styp_to_sec_flags (abfd, hdr) ! bfd * abfd; PTR hdr; { struct internal_scnhdr *internal_s = (struct internal_scnhdr *) hdr; long styp_flags = internal_s->s_flags; --- 405,414 ---- * in sec_to_styp_flags(). */ static flagword ! styp_to_sec_flags (abfd, hdr, name) ! bfd *abfd; PTR hdr; + const char *name; { struct internal_scnhdr *internal_s = (struct internal_scnhdr *) hdr; long styp_flags = internal_s->s_flags; *************** styp_to_sec_flags (abfd, hdr) *** 457,462 **** --- 458,511 ---- sec_flags |= SEC_DEBUGGING; #endif } + else if (strcmp (name, _TEXT) == 0) + { + if (sec_flags & SEC_NEVER_LOAD) + sec_flags |= SEC_CODE | SEC_COFF_SHARED_LIBRARY; + else + sec_flags |= SEC_CODE | SEC_LOAD | SEC_ALLOC; + } + else if (strcmp (name, _DATA) == 0 + #ifdef TWO_DATA_SECS + || strcmp (name, ".data2") == 0 + #endif + ) + { + if (sec_flags & SEC_NEVER_LOAD) + sec_flags |= SEC_DATA | SEC_COFF_SHARED_LIBRARY; + else + sec_flags |= SEC_DATA | SEC_LOAD | SEC_ALLOC; + } + else if (strcmp (name, _BSS) == 0) + { + #ifdef BSS_NOLOAD_IS_SHARED_LIBRARY + if (sec_flags & SEC_NEVER_LOAD) + sec_flags |= SEC_ALLOC | SEC_COFF_SHARED_LIBRARY; + else + #endif + sec_flags |= SEC_ALLOC; + } + else if (strcmp (name, ".debug") == 0 + #ifdef _COMMENT + || strcmp (name, _COMMENT) == 0 + #endif + || strcmp (name, ".stab") == 0 + || strcmp (name, ".stabstr") == 0) + { + #ifdef COFF_PAGE_SIZE + sec_flags |= SEC_DEBUGGING; + #endif + } + #ifdef _LIB + else if (strcmp (name, _LIB) == 0) + ; + #endif + #ifdef _LIT + else if (strcmp (name, _LIT) == 0) + { + sec_flags = SEC_LOAD | SEC_ALLOC | SEC_READONLY; + } + #endif else { sec_flags |= SEC_ALLOC | SEC_LOAD; *************** dependent COFF routines: *** 585,591 **** . PTR internal_aouthdr)); . flagword (*_bfd_styp_to_sec_flags_hook) PARAMS (( . bfd *abfd, ! . PTR internal_scnhdr)); . asection *(*_bfd_make_section_hook) PARAMS (( . bfd *abfd, . char *name)); --- 634,641 ---- . PTR internal_aouthdr)); . flagword (*_bfd_styp_to_sec_flags_hook) PARAMS (( . bfd *abfd, ! . PTR internal_scnhdr, ! . const char *name)); . asection *(*_bfd_make_section_hook) PARAMS (( . bfd *abfd, . char *name)); *************** dependent COFF routines: *** 671,678 **** .#define bfd_coff_mkobject_hook(abfd, filehdr, aouthdr)\ . ((coff_backend_info (abfd)->_bfd_coff_mkobject_hook) (abfd, filehdr, aouthdr)) . ! .#define bfd_coff_styp_to_sec_flags_hook(abfd, scnhdr)\ ! . ((coff_backend_info (abfd)->_bfd_styp_to_sec_flags_hook) (abfd, scnhdr)) . .#define bfd_coff_make_section_hook(abfd, name)\ . ((coff_backend_info (abfd)->_bfd_make_section_hook) (abfd, name)) --- 721,728 ---- .#define bfd_coff_mkobject_hook(abfd, filehdr, aouthdr)\ . ((coff_backend_info (abfd)->_bfd_coff_mkobject_hook) (abfd, filehdr, aouthdr)) . ! .#define bfd_coff_styp_to_sec_flags_hook(abfd, scnhdr, name)\ ! . ((coff_backend_info (abfd)->_bfd_styp_to_sec_flags_hook) (abfd, scnhdr, name)) . .#define bfd_coff_make_section_hook(abfd, name)\ . ((coff_backend_info (abfd)->_bfd_make_section_hook) (abfd, name)) Index: coffgen.c =================================================================== RCS file: /rel/cvsfiles/devo/bfd/coffgen.c,v retrieving revision 1.34 diff -p -r1.34 coffgen.c *** coffgen.c 1994/06/21 16:46:51 1.34 --- coffgen.c 1994/08/10 17:03:06 *************** make_a_section_from_file (abfd, hdr, tar *** 99,105 **** return_section->lineno_count = hdr->s_nlnno; return_section->userdata = NULL; return_section->next = (asection *) NULL; ! return_section->flags = bfd_coff_styp_to_sec_flags_hook (abfd, hdr); return_section->target_index = target_index; --- 99,105 ---- return_section->lineno_count = hdr->s_nlnno; return_section->userdata = NULL; return_section->next = (asection *) NULL; ! return_section->flags = bfd_coff_styp_to_sec_flags_hook (abfd, hdr, name); return_section->target_index = target_index; From hjl@nynexst.com Sun Aug 14 22:33:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Sun, 14 Aug 1994 22:33:00 -0000 Subject: gas-940814 ld bugs References: <9403150407.AA06088@cujo.cygnus.com> Message-ID: <9408150533.AA18413@titanic.nynexst.com> gas-940814 configured for i486-linux. If I do ld -x -Ttext 5ffff000 -Tdata 6008e000 foo.o the size of the output file is ridiculous. I got -rwxr-xr-x 1 hjl isl 8367 Aug 15 01:54 a.out text data bss dec hex filename 4064 4096 0 8160 1fe0 a.out But I am looking for about 0x8e000 bytes. H.J. -------foo.c---- int bar= 100; void foo () { return; } From ian@cygnus.com Mon Aug 15 08:35:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Mon, 15 Aug 1994 08:35:00 -0000 Subject: gas-940814 ld bugs References: <9408150533.AA18413@titanic.nynexst.com> Message-ID: <199408151535.LAA09278@sanguine.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Mon, 15 Aug 94 1:33:47 EDT gas-940814 configured for i486-linux. If I do ld -x -Ttext 5ffff000 -Tdata 6008e000 foo.o the size of the output file is ridiculous. I got -rwxr-xr-x 1 hjl isl 8367 Aug 15 01:54 a.out text data bss dec hex filename 4064 4096 0 8160 1fe0 a.out But I am looking for about 0x8e000 bytes. When you use -Ttext and -Tdata, the linker will link the code as if the .text and .data sections start at the given address. It will also tell BFD to store the given VMA with the section. It will not insert extra zero bytes. The problem, of course, is that a.out has no way to store the starting VMA of a section. This is one of several disadvantages of the a.out format. The solution is to either use a different object file format, or to modify the linker script along the lines of .text 0x1020 { . = 0x5ffff000 *(.text) } Ian From hjl@nynexst.com Mon Aug 15 16:56:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Mon, 15 Aug 1994 16:56:00 -0000 Subject: Linux compatibility patch Message-ID: <9408152354.AA26013@titanic.nynexst.com> This is for Linux compatibility. Thanks. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com --- *** ld/lexsup.c.old Mon Aug 15 19:17:40 1994 --- ld/lexsup.c Mon Aug 15 19:19:42 1994 *************** *** 95,100 **** --- 95,101 ---- {"call_shared", no_argument, NULL, OPTION_CALL_SHARED}, {"dc", no_argument, NULL, 'd'}, {"defsym", required_argument, NULL, OPTION_DEFSYM}, + {"dll-verbose", no_argument, NULL, OPTION_VERSION}, /* Linux compatibility. */ {"dn", no_argument, NULL, OPTION_NON_SHARED}, {"dp", no_argument, NULL, 'd'}, {"dy", no_argument, NULL, OPTION_CALL_SHARED}, From hjl@nynexst.com Tue Aug 16 11:12:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Tue, 16 Aug 1994 11:12:00 -0000 Subject: ld -r in gas-940816 References: <199408161134.HAA02540@cais.cais.com> Message-ID: <9408161811.AA15636@titanic.nynexst.com> Hi, I found out ld -r in gas-940816 under a.out-i386-linux changes the alignment from 2**2 specified in the asm file to 2**3. I don't know what else it does besides that. For whatever reason, after doing gcc -c foo.c ld -r -x foo.o mv a.out foo.o the result foo.o is changed such that it cannot be used to built the shared image for Linux with ld -x -Ttext -Tdata -o libc.so.xxxxx foo.o ..... I don't know why. ld -r works with binutils 1.9. If I just do gcc -c foo.c ..... ld -x -Ttext -Tdata -o libc.so.xxxxx foo.o .... everything is fine. Here are some outputs. It looks like gas-940816 misinterpreted something and did something funny to .o file when -r is used. BTW, Eric, it looks my patch for tools 2.15 is ok. Please make tools 2.16. H.J. ---- # gcc -c x.s # nm.o 00000000 t ___gnu_compiled_c 00000000 T _foo 00000004 D _x 00000008 D _y 00000000 t gcc2_compiled. # objdump --dis x.o x.o: file format a.out-i386-linux Disassembly of section .text: 00000000 <_foo> ret 00000001 <_foo+1> nop 00000002 <_foo+2> nop 00000003 <_foo+3> Address 0x4 is out of bounds. Disassembly of section .data: 00000004 <_x> addl $0x5000000,%eax # ld -r -o 2.5 x.o # objdump --dis 2.5 2.5: file format a.out-i386-linux Disassembly of section .text: 00000000 <_foo> ret 00000001 <_foo+1> nop 00000002 <_foo+2> nop 00000003 <_foo+3> nop ... Disassembly of section .data: 00000008 <_x> addl $0x5000000,%eax # ld.1.9 -r -o 1.9 x.o # objdump --dis 1.9 1.9: file format a.out-i386-linux Disassembly of section .text: 00000000 <_foo> ret 00000001 <_foo+1> nop 00000002 <_foo+2> nop 00000003 <_foo+3> Address 0x4 is out of bounds. Disassembly of section .data: 00000004 <_x> addl $0x5000000,%eax -----x.s-- .file "x.c" gcc2_compiled.: ___gnu_compiled_c: .globl _x .data .align 2 _x: .long 5 .text .align 4 .globl _foo _foo: ret .globl _y .data .align 2 _y: .long 5 From hjl@nynexst.com Tue Aug 16 16:04:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Tue, 16 Aug 1994 16:04:00 -0000 Subject: An old gas bug Message-ID: <9408162303.AA17808@titanic.nynexst.com> Hi, This is a very old bug date back to 1.38.1. The reason no one really cares is gcc won't generate that kind of code, i.e., jump out of range. When some Linux people were working on X11R5, they used an Intel x86 branch/loop instruction, jcxz, which has only byte displacements in the hand coded asm code. The AT&T as worked fine with expansion. But gas 1.38.1 generated some bogus codes. I fixed the bug for them. I think it is correct. The test case is very easy to produce. Please let me know if you need one. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com ---- Tue Aug 16 18:48:10 1994 H.J. Lu (hlu@nynexst.com) * write.c (fixup_segment): fix the displacement range checking. "add_number" may be signed and is of type int. We only shift by size * 8 - 1. *** gas/write.c Thu Jul 14 14:57:47 1994 --- gas/write.c.new Tue Aug 16 18:47:11 1994 *************** *** 2195,2202 **** 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) { --- 2195,2201 ---- 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 * 8 - 1; if ((add_number & mask) != 0 && (add_number & mask) != mask) { From meissner@osf.org Wed Aug 17 06:08:00 1994 From: meissner@osf.org (Michael Meissner) Date: Wed, 17 Aug 1994 06:08:00 -0000 Subject: An old gas bug References: <9408162303.AA17808@titanic.nynexst.com> <9408162303.AA17808@titanic.nynexst.com> Message-ID: <9408171307.AA00342@pasta.osf.org> | Hi, | | This is a very old bug date back to 1.38.1. The reason no one really | cares is gcc won't generate that kind of code, i.e., jump out of range. | When some Linux people were working on X11R5, they used an Intel x86 | branch/loop instruction, jcxz, which has only byte displacements in | the hand coded asm code. The AT&T as worked fine with expansion. But | gas 1.38.1 generated some bogus codes. I fixed the bug for them. I | think it is correct. The test case is very easy to produce. Please let | me know if you need one. While it should be certainly fixed in the assembler, the X11 code should also replace the jcxz instruction with a compare against 0 and jmp sequence, since that is faster on anything but an original 386. See the optimization guides in the 486/pentium manuals. From hjl@nynexst.com Wed Aug 17 06:16:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 17 Aug 1994 06:16:00 -0000 Subject: An old gas bug References: <9408171307.AA00342@pasta.osf.org> Message-ID: <9408171315.AA23850@titanic.nynexst.com> > > | Hi, > | > | This is a very old bug date back to 1.38.1. The reason no one really > | cares is gcc won't generate that kind of code, i.e., jump out of range. > | When some Linux people were working on X11R5, they used an Intel x86 > | branch/loop instruction, jcxz, which has only byte displacements in > | the hand coded asm code. The AT&T as worked fine with expansion. But > | gas 1.38.1 generated some bogus codes. I fixed the bug for them. I > | think it is correct. The test case is very easy to produce. Please let > | me know if you need one. > > While it should be certainly fixed in the assembler, the X11 code > should also replace the jcxz instruction with a compare against 0 and > jmp sequence, since that is faster on anything but an original 386. > See the optimization guides in the 486/pentium manuals. > > After I told them that, they have then changed the code. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From hjl@nynexst.com Wed Aug 17 14:36:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 17 Aug 1994 14:36:00 -0000 Subject: An old gas bug References: <199408171947.PAA12811@sanguine.cygnus.com> Message-ID: <9408172135.AA21607@titanic.nynexst.com> > gas isn't my responsibility, but I think this fix is wrong. It > appears to assume that the field holds a signed value. You can't make > that assumption in the machine independent file write.c. Suppose the > field were intended to hold an unsigned value, and the user tried to > put 0x80 in it? > That is true. But, at least my patch won't generate bogus code :-(. > I think this sort of thing needs to be checked in md_apply_fix. > > Ian > -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From hjl@nynexst.com Wed Aug 17 19:26:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 17 Aug 1994 19:26:00 -0000 Subject: ld -r in gas-940816 References: <199408172205.SAA13025@sanguine.cygnus.com> Message-ID: <9408180225.AA23794@titanic.nynexst.com> > > Date: Wed, 17 Aug 94 17:30:41 EDT > From: eric@tantalus.nrl.navy.mil (Eric Youngdale) > > Enclosed. Here is the relevant output of some tests: > > Thanks for the test case. > > My impression is that this problem is specific to the relationship > between the .data section and the .bss section, since the VMA of the > .bss section in an input file is fixed at the VMA of the .data section > plus the size of the .data section. > > This patch appears to fix the test case. If nobody sees any problems > with it, I will check it in. > > Ian I tried your patch on the Linuc C library with ld -r -x. It still doesn't work. I got the core dump with the shared library in the dynamic linker while in __do_fixups at fixups.c:137. I compiled a "hello world" with the static library built with ld -r -x also. It doesn't print out anything. It looks ld -r -x is totally broken, at least under Linux, maybe all aout-i386 :-(. I will replace the .o file in a good static libc.a with the one built by ld -r -x one by one. I hope I can track down the really mis-lded .o file. But there are more than 600 files in libc.sa. I don't know when I will finish it in my spare time :-(. H.J. H.J. From hjl@nynexst.com Wed Aug 17 20:22:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 17 Aug 1994 20:22:00 -0000 Subject: ld -r on the static library Message-ID: <9408180321.AA24206@titanic.nynexst.com> Hi, Oops. I made a mistake. ld -r -x does work on the static library. But somehow it fails on the shared one. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From hjl@nynexst.com Thu Aug 18 06:00:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Thu, 18 Aug 1994 06:00:00 -0000 Subject: Is the GNU against link (ar/ranlib)? Message-ID: <9408181259.AA27933@titanic.nynexst.com> Hi, Why not link ranlib to ar and check arg [0]? -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From hjl@nynexst.com Thu Aug 18 06:57:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Thu, 18 Aug 1994 06:57:00 -0000 Subject: ld bug found References: <199408181255.IAA13727@cais.cais.com> Message-ID: <9408181357.AA28438@titanic.nynexst.com> The bug is in the way how ld -r treats ".stabs". It screws things up by treating it as of without -r. H.J. ------ # gcc -c x.s # ld-1.9 -r -x -o 1.9 x.o # ld-2.5 -r -x -o 2.5 x.o # nm 2.5 1.9 x.o 2.5: 00000010 - 00 0000 (6) __BUILTIN_FIXUPS__ U __GOT__AM 00000000 T _foo 1.9: 00000020 - 00 0000 (6) __BUILTIN_FIXUPS__ U __GOT__AM 00000000 T _foo x.o: 00000020 - 00 0000 (6) __BUILTIN_FIXUPS__ U __GOT__AM 00000010 d ___fixup_list ------x.s---- .globl _foo _foo: .long 0x100 .long 0x100 .long 0x100 .long 0x100 .data ___fixup_list: .stabs "__BUILTIN_FIXUPS__",25,0,0,___fixup_list .long __GOT__AM From ian@cygnus.com Thu Aug 18 07:39:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Thu, 18 Aug 1994 07:39:00 -0000 Subject: Is the GNU against link (ar/ranlib)? References: <9408181259.AA27933@titanic.nynexst.com> Message-ID: <199408181439.KAA13925@sanguine.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Thu, 18 Aug 94 9:00:42 EDT Why not link ranlib to ar and check arg [0]? >From the GNU standards document (available from GNU archive sites as standards.*): Please don't make the behavior of a utility depend on the name used to invoke it. It is useful sometimes to make a link to a utility with a different name, and that should not change what it does. Instead, use a run time option or a compilation switch or both to select among the alternate behaviors. Ian From raeburn@cygnus.com Thu Aug 18 11:40:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Thu, 18 Aug 1994 11:40:00 -0000 Subject: weekly diff problem; other lameness on my part Message-ID: <9408181837.AA00599@> As Eric pointed out to me, the weekly diffs generated this week are too short. Apparently, "diff" failed trying to read a file. Yet another fix for my snapshot script... Anyways, I haven't been keeping around past weeks' snapshots, so I can't regenerate the correct set of weekly diffs. I'd suggest getting a new snapshot, or getting the dailies since 940810 (the last weekly). You may have noticed that some of the patches, bug reports &c you've been sending to me might not've gotten dealt with as quickly as you might like. Well, the network connection between me and the CVS source repository has been pretty lame; in this case, it appears that both Sprint and the Little Garden are hosed. Having been spoiled in previous jobs by excellent network connectivity to anything that mattered, I've been finding it frustrating to work under such conditions. So I've been ignoring gas and concentrating on fixing our remote-cvs hack to function better under these circumstances. This work should be finished shortly, and I'll be getting back to doing assembler work. (Yes, Ian does work in the same office and has still been getting things done. I guess he's a bit more tolerant or disciplined than I am. :-) From ian@cygnus.com Wed Aug 24 21:16:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Wed, 24 Aug 1994 21:16:00 -0000 Subject: [harmon@metronet.com: GNU GAS i386 16 bit] Message-ID: <9408250416.AA13401@tweedledumb.cygnus.com> I know as little as possible about the i386, and I certainly know nothing about the differences between 16 and 32 bit mode. Can anybody on this list help? I'm sure that nobody at Cygnus plans to add support for 16 bit mode, unless, of course, we find somebody to pay for it. Ian Date: Wed, 24 Aug 1994 20:27:16 -0500 From: Thomas Harmon To: ian@tweedledumb.cygnus.com Subject: GNU GAS i386 16 bit Ian, My name is Thomas Harmon. I found your E-mail address in the 2.3 version of GNU GAS. Please excuse me for bothering you. I would like to ask for your opinion on some modifications I would like to make to GAS. I am working on a major project which requires a cross-platform, x86 assembler, for both 16 and 32 bit code. That is where my problem lies, I know GAS does not currently support 16 bit code, but how much effort do you think it will take to add it? Is this being planned for GAS? If so, when do you think it will be done? If it looks like I'll need to add 16-bit support myself, please send me a list of things I'll need to check. I think I can figure it out from the 2.3 distribution, but I'd like to know about any special problems that are not immediately obvious. Thank you for your time. ----------------------------------------------------------------------------- Thomas Harmon "He's no fun, he fell right over." harmon@feenix.metronet.com -- Four or Five Crazy Guys ----------------------------------------------------------------------------- From meissner@osf.org Thu Aug 25 05:56:00 1994 From: meissner@osf.org (Michael Meissner) Date: Thu, 25 Aug 1994 05:56:00 -0000 Subject: [harmon@metronet.com: GNU GAS i386 16 bit] References: <9408250416.AA13401@tweedledumb.cygnus.com> <9408250416.AA13401@tweedledumb.cygnus.com> Message-ID: <9408251256.AA11697@pasta.osf.org> | I know as little as possible about the i386, and I certainly know | nothing about the differences between 16 and 32 bit mode. Can anybody | on this list help? I'm sure that nobody at Cygnus plans to add | support for 16 bit mode, unless, of course, we find somebody to pay | for it. Adding 16 bit support is probably straight forward (ie, the work isn't simple, but once you learn your way around the sources, it isn't that hard). You will probably have to have a global mode bit that says 16 or 32 bit instructions are being generated. Note, some object file formats (notably ELF) on the 386 don't have relocation types for 16-bit relocations. All in all, it is probably a couple of months of work. | Ian | | Date: Wed, 24 Aug 1994 20:27:16 -0500 | From: Thomas Harmon | To: ian@tweedledumb.cygnus.com | Subject: GNU GAS i386 16 bit | | | Ian, | | My name is Thomas Harmon. I found your E-mail address in the 2.3 | version of GNU GAS. Please excuse me for bothering you. I would like to | ask for your opinion on some modifications I would like to make to GAS. | | I am working on a major project which requires a cross-platform, | x86 assembler, for both 16 and 32 bit code. That is where my problem lies, | I know GAS does not currently support 16 bit code, but how much effort do | you think it will take to add it? Is this being planned for GAS? If so, | when do you think it will be done? If it looks like I'll need to add 16-bit | support myself, please send me a list of things I'll need to check. I think | I can figure it out from the 2.3 distribution, but I'd like to know about | any special problems that are not immediately obvious. | | Thank you for your time. | | ----------------------------------------------------------------------------- | Thomas Harmon "He's no fun, he fell right over." | harmon@feenix.metronet.com -- Four or Five Crazy Guys | ----------------------------------------------------------------------------- | | | | From artk@congruent.com Thu Aug 25 06:28:00 1994 From: artk@congruent.com (Arthur Kreitman) Date: Thu, 25 Aug 1994 06:28:00 -0000 Subject: [harmon@metronet.com: GNU GAS i386 16 bit] References: <9408250416.AA13401@tweedledumb.cygnus.com> Message-ID: <9408251313.AA19072@Congruent.COM> I don't think you want to add 16 bit support even if someone pays you to do it. The real issue is the binary format. For object modules, the format is something called OMF. The executable program format is something else. I would guess that adding OMF to gas (and all that bfd stuff) will take man-years. From: Ian Lance Taylor Date: Thu, 25 Aug 94 00:16:31 EDT I know as little as possible about the i386, and I certainly know nothing about the differences between 16 and 32 bit mode. Can anybody on this list help? I'm sure that nobody at Cygnus plans to add support for 16 bit mode, unless, of course, we find somebody to pay for it. Ian Date: Wed, 24 Aug 1994 20:27:16 -0500 From: Thomas Harmon To: ian@tweedledumb.cygnus.com Subject: GNU GAS i386 16 bit Ian, My name is Thomas Harmon. I found your E-mail address in the 2.3 version of GNU GAS. Please excuse me for bothering you. I would like to ask for your opinion on some modifications I would like to make to GAS. I am working on a major project which requires a cross-platform, x86 assembler, for both 16 and 32 bit code. That is where my problem lies, I know GAS does not currently support 16 bit code, but how much effort do you think it will take to add it? Is this being planned for GAS? If so, when do you think it will be done? If it looks like I'll need to add 16-bit support myself, please send me a list of things I'll need to check. I think I can figure it out from the 2.3 distribution, but I'd like to know about any special problems that are not immediately obvious. Thank you for your time. ----------------------------------------------------------------------------- Thomas Harmon "He's no fun, he fell right over." harmon@feenix.metronet.com -- Four or Five Crazy Guys ----------------------------------------------------------------------------- From meissner@osf.org Thu Aug 25 06:52:00 1994 From: meissner@osf.org (Michael Meissner) Date: Thu, 25 Aug 1994 06:52:00 -0000 Subject: [harmon@metronet.com: GNU GAS i386 16 bit] References: <9408250416.AA13401@tweedledumb.cygnus.com> <9408251313.AA19072@Congruent.COM> <9408251313.AA19072@Congruent.COM> Message-ID: <9408251352.AA19936@pasta.osf.org> | | I don't think you want to add 16 bit support even if someone pays | you to do it. The real issue is the binary format. For object | modules, the format is something called OMF. The executable program | format is something else. I would guess that adding OMF to gas (and | all that bfd stuff) will take man-years. If somebody pays reasonably to get the work done, I would certainly consider doing it, providing I wasn't employed at the time. Others would too. I'm sure Cygnus would do it if the cost was enough. Adding a new object format can certainly be done. It depends on what trickyness is in OMF. If it doesn't require things that aren't already in BFD (such as shared library support), it would be straigtforward. That's what BFD is for in the first place. I also seem to recall there are gas ports to OMF floating around (pre-BFD). You might ask DJ Delorie (dj@ctron.com), if he isn't on the mailing list for thoughts, since he is closer to the MSDOS world than most of us UNIX-oids/GNU-oids are. | | | From: Ian Lance Taylor | Date: Thu, 25 Aug 94 00:16:31 EDT | | I know as little as possible about the i386, and I certainly know | nothing about the differences between 16 and 32 bit mode. Can anybody | on this list help? I'm sure that nobody at Cygnus plans to add | support for 16 bit mode, unless, of course, we find somebody to pay | for it. | | Ian | | Date: Wed, 24 Aug 1994 20:27:16 -0500 | From: Thomas Harmon | To: ian@tweedledumb.cygnus.com | Subject: GNU GAS i386 16 bit | | | Ian, | | My name is Thomas Harmon. I found your E-mail address in the 2.3 | version of GNU GAS. Please excuse me for bothering you. I would like to | ask for your opinion on some modifications I would like to make to GAS. | | I am working on a major project which requires a cross-platform, | x86 assembler, for both 16 and 32 bit code. That is where my problem lies, | I know GAS does not currently support 16 bit code, but how much effort do | you think it will take to add it? Is this being planned for GAS? If so, | when do you think it will be done? If it looks like I'll need to add 16-bit | support myself, please send me a list of things I'll need to check. I think | I can figure it out from the 2.3 distribution, but I'd like to know about | any special problems that are not immediately obvious. | | Thank you for your time. | | ----------------------------------------------------------------------------- | Thomas Harmon "He's no fun, he fell right over." | harmon@feenix.metronet.com -- Four or Five Crazy Guys | ----------------------------------------------------------------------------- | | | | From artk@congruent.com Thu Aug 25 07:53:00 1994 From: artk@congruent.com (Arthur Kreitman) Date: Thu, 25 Aug 1994 07:53:00 -0000 Subject: [harmon@metronet.com: GNU GAS i386 16 bit] References: <9408251352.AA19936@pasta.osf.org> Message-ID: <9408251438.AA19775@Congruent.COM> The other issue is the future of OMF and 16 bit x86. Microsoft's 32 bit compilers all pump out a coff'ish object format. And with new product releases, even Microsoft won't be supporting OMF. Its difficult to see why anyone would want to pay for work that will be useless by the time its completed., From: Michael Meissner Date: Thu, 25 Aug 94 09:52:18 -0400 References: < 9408250416.AA13401@tweedledumb.cygnus.com > < 9408251313.AA19072@Congruent.COM > | | I don't think you want to add 16 bit support even if someone pays | you to do it. The real issue is the binary format. For object | modules, the format is something called OMF. The executable program | format is something else. I would guess that adding OMF to gas (and | all that bfd stuff) will take man-years. If somebody pays reasonably to get the work done, I would certainly consider doing it, providing I wasn't employed at the time. Others would too. I'm sure Cygnus would do it if the cost was enough. Adding a new object format can certainly be done. It depends on what trickyness is in OMF. If it doesn't require things that aren't already in BFD (such as shared library support), it would be straigtforward. That's what BFD is for in the first place. I also seem to recall there are gas ports to OMF floating around (pre-BFD). You might ask DJ Delorie (dj@ctron.com), if he isn't on the mailing list for thoughts, since he is closer to the MSDOS world than most of us UNIX-oids/GNU-oids are. | | | From: Ian Lance Taylor | Date: Thu, 25 Aug 94 00:16:31 EDT | | I know as little as possible about the i386, and I certainly know | nothing about the differences between 16 and 32 bit mode. Can anybody | on this list help? I'm sure that nobody at Cygnus plans to add | support for 16 bit mode, unless, of course, we find somebody to pay | for it. | | Ian | | Date: Wed, 24 Aug 1994 20:27:16 -0500 | From: Thomas Harmon | To: ian@tweedledumb.cygnus.com | Subject: GNU GAS i386 16 bit | | | Ian, | | My name is Thomas Harmon. I found your E-mail address in the 2.3 | version of GNU GAS. Please excuse me for bothering you. I would like to | ask for your opinion on some modifications I would like to make to GAS. | | I am working on a major project which requires a cross-platform, | x86 assembler, for both 16 and 32 bit code. That is where my problem lies, | I know GAS does not currently support 16 bit code, but how much effort do | you think it will take to add it? Is this being planned for GAS? If so, | when do you think it will be done? If it looks like I'll need to add 16-bit | support myself, please send me a list of things I'll need to check. I think | I can figure it out from the 2.3 distribution, but I'd like to know about | any special problems that are not immediately obvious. | | Thank you for your time. | | ----------------------------------------------------------------------------- | Thomas Harmon "He's no fun, he fell right over." | harmon@feenix.metronet.com -- Four or Five Crazy Guys | ----------------------------------------------------------------------------- | | | | From dj@ctron.com Thu Aug 25 08:03:00 1994 From: dj@ctron.com (DJ Delorie) Date: Thu, 25 Aug 1994 08:03:00 -0000 Subject: [harmon@metronet.com: GNU GAS i386 16 bit] References: <9408251352.AA19936@pasta.osf.org> Message-ID: <9408251504.AA28263@delorie> > Adding a new object format can certainly be done. It depends on what > trickyness is in OMF. If it doesn't require things that aren't > already in BFD (such as shared library support), it would be > straigtforward. That's what BFD is for in the first place. I also > seem to recall there are gas ports to OMF floating around (pre-BFD). > You might ask DJ Delorie (dj@ctron.com), if he isn't on the mailing > list for thoughts, since he is closer to the MSDOS world than most of > us UNIX-oids/GNU-oids are. The OMF format is different from any Unix format, but EMX (gcc for os/2) produces 32-bit OMF so it *can* be done. I don't know what the changes entail, though. The biggest difference when dealing ith DOS OMF and 16-bit assembler is something that's come up before - segments. DOS has lots of them, and gcc et al just don't support them very well. With OMF and BFD, you could treat segments like sections, so you could probably get something that worked without having to re-engineer the BFD interface itself. Making gas support intel mixed assembler is a different story. Little of the i386 code will be reusable, since 16-bit opcodes have different formats than the 32-bit ones (might as well be a whole new CPU). Also, you'll need to keep track of operand and address size overrides, which gas does for the i386 but will need to be extended. Also, the concept of default segments and use directives will be a new experience for gas. I think someone who has implemented support for a processor from scratch should be able to add 16/32 OMF support without undue difficulty, though. Teaching gcc about it is a different story, however. gnuoids? From sac@cygnus.com Fri Aug 26 09:33:00 1994 From: sac@cygnus.com (sac@cygnus.com) Date: Fri, 26 Aug 1994 09:33:00 -0000 Subject: Gas References: <199408260937.LAA11348@obelix.wd.estec.esa.nl> Message-ID: <199408261629.JAA09496@jonny.cygnus.com> > > > Hy there, > I write to you because i can see you are the author of the z8k > porting of gas. I am actually investigating the porting of the > assembler to the 1750 std. because the author of the gcc porting to > the same processor has his own assembler linker not available for the > moment. > Could you please give the coordinates of some porting manual for gas > i can not find it in the distribution. > Hi, I've already talked about porting gas to the 1750, but I have since deleted the email. Perhaps you can ask some questions on the net and see if the work is already underway. There are going to be some problems, since gas doesn't understand what to do when memory isn't byte addressable. It looks like the right thing to do is go though gas and remove the restriction. This is quite a large ammount of work. I'm not aware of any document describing how to port gas even in the simple case. Steve From raeburn@cygnus.com Sun Aug 28 01:19:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Sun, 28 Aug 1994 01:19:00 -0000 Subject: gas and autoconf Message-ID: <199408280819.BAA23748@rtl.cygnus.com> I've converted the gas subdirectory to use autoconf. I'm using beta-test versions of autoconf 2. The configure script in tonight's snapshot (if it happens -- I *think* there will be enough disk space tonight) was generated with autoconf 1.107. The autoconf snapshots are available on alpha.gnu.ai.mit.edu; I've also put a copy of 1.107 in ftp.cygnus.com:~ftp/private/gas. The non-UNIX configurations will probably need some tweaking to get in sync with this change. Probably some changes will be needed for UNIX systems too. I'm aware of one problem with "const", which I'll be looking into. Please let me know of any other problems you encounter. From raeburn@cygnus.com Sun Aug 28 13:17:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Sun, 28 Aug 1994 13:17:00 -0000 Subject: autoconf changes to gas Message-ID: <199408282017.NAA23227@rtl.cygnus.com> If you update your gas sources (Cygnus folks: in devo; net folks: from the next snapshot), you will need to reconfigure any already-configured tree based on earlier versions of the sources. You only need to configure the gas directory, using the configure script in the gas source directory; reconfiguring the whole tree will take care of it too. The Cygnus configure writes a config.status which will cause Cygnus configure to be re-run when it appears to be needed. But Cygnus configure will be very unhappy with the new autoconf-style configure.in, and will complain about a missing "per-host:" line. It won't even attempt to run the new autoconf-generated configure script, because it wasn't there when the tree was first configured. From hjl@nynexst.com Sun Aug 28 17:02:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Sun, 28 Aug 1994 17:02:00 -0000 Subject: ld in binutils-1.9l.3 References: Message-ID: <9408290001.AA02599@titanic.nynexst.com> > > > This is a weird problem that `ld' should really detect and prevent > (via a warning message). > > To reproduce: > > $ cat > test.c > main () { printf("this is a test\n"); } > ^D > $ gcc -o test.o test.c (Note the missing "-c") > $ file test.o > test.o: Linux/i386 demand-paged executable (QMAGIC) not stripped > $ gcc -o test test.o > $ file test > test: Linux/i386 demand-paged executable (QMAGIC) not stripped > $ test.o > this is a test > $ test > [ no output ] > > When this snuck up on us for real, it caused lots of problems and took > a bit of debugging to track down a bad Makefile. > > Sometimes, they'll (twice linked binaries) run peacefully, but > sometimes they do bad things: seg. fault (untraceable) and suck up all > virtual memory are the two I've seen. > > Could some better magic detection be put into ld? > > - Dan > That is also true for the gas2 snapshot. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From ian@cygnus.com Mon Aug 29 09:46:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Mon, 29 Aug 1994 09:46:00 -0000 Subject: ld in binutils-1.9l.3 References: <9408290001.AA02599@titanic.nynexst.com> Message-ID: <199408291646.MAA10390@sanguine.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Sun, 28 Aug 94 20:02:06 EDT > This is a weird problem that `ld' should really detect and prevent > (via a warning message). > > To reproduce: > > $ cat > test.c > main () { printf("this is a test\n"); } > ^D > $ gcc -o test.o test.c (Note the missing "-c") > $ file test.o > test.o: Linux/i386 demand-paged executable (QMAGIC) not stripped > $ gcc -o test test.o > $ file test > test: Linux/i386 demand-paged executable (QMAGIC) not stripped > $ test.o > this is a test > $ test > [ no output ] > > When this snuck up on us for real, it caused lots of problems and took > a bit of debugging to track down a bad Makefile. > > Sometimes, they'll (twice linked binaries) run peacefully, but > sometimes they do bad things: seg. fault (untraceable) and suck up all > virtual memory are the two I've seen. > > Could some better magic detection be put into ld? I don't really see how to do this in a system independent fashion. On some systems there is no simple way to distinguish files which are reasonable linker inputs from files which are not. Of course, I am open to suggestions. Note that if you define a globally visible symbol in the crt0.o file, then you will get a multiple definition error when you attempt to link an already linked file. That should prevent this type of error from occurring. Ian From pk@cs.few.eur.nl Thu Sep 1 13:12:00 1994 From: pk@cs.few.eur.nl (Paul Kranenburg) Date: Thu, 01 Sep 1994 13:12:00 -0000 Subject: patch for listing.c Message-ID: <9409012012.AA17202@cs.few.eur.nl> I found that listings in gas (dd. 940823) can get thoroughly confused about line numbers when processing included files (or cpp generated directives). -pk *** /usr/local/src/gnu/ARCHIVE/gas-940823/gas/listing.c Fri May 27 18:55:56 1994 --- ./listing.c Mon Aug 29 15:58:51 1994 *************** *** 301,312 **** char *file; unsigned int line; static unsigned int last_line = 0xffff; list_info_type *new; as_where (&file, &line); ! if (line != last_line) { last_line = line; new_frag (); new = (list_info_type *) xmalloc (sizeof (list_info_type)); --- 249,262 ---- char *file; unsigned int line; static unsigned int last_line = 0xffff; + static char *last_file = NULL; list_info_type *new; as_where (&file, &line); ! if (line != last_line || last_file && file && strcmp(file, last_file)) { last_line = line; + last_file = file; new_frag (); new = (list_info_type *) xmalloc (sizeof (list_info_type)); *************** *** 728,734 **** --- 678,688 ---- if (S_GET_NAME (ptr) && strlen (S_GET_NAME (ptr)) != 0) { if (ptr->sy_frag->line == 0 + #ifdef notyet && S_GET_SEGMENT (ptr) != reg_section) + #else + && !S_IS_REGISTER(ptr)) + #endif { if (!got_some) { *************** *** 885,896 **** print_source (current_hll_file, list, buffer, width); } ! p = buffer_line (list->file, buffer, width); ! if (!((listing & LISTING_NODEBUG) && debugging_pseudo (p))) ! { ! print_lines (list, p, calc_hex (list)); ! } if (list->edict == EDICT_EJECT) { --- 839,853 ---- print_source (current_hll_file, list, buffer, width); } ! while (list->file->file && ! list->file->linenum < list->line && !list->file->end_pending) { ! p = buffer_line (list->file, buffer, width); ! if (!((listing & LISTING_NODEBUG) && debugging_pseudo (p))) ! { ! print_lines (list, p, calc_hex (list)); ! } ! } if (list->edict == EDICT_EJECT) { *************** *** 900,906 **** else { ! p = buffer_line (list->file, buffer, width); } list = list->next; --- 857,865 ---- else { ! while (list->file->file && ! list->file->linenum < list->line && !list->file->end_pending) ! p = buffer_line (list->file, buffer, width); } list = list->next; From raeburn@cygnus.com Thu Sep 1 20:57:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Thu, 01 Sep 1994 20:57:00 -0000 Subject: recent gas changes References: <940901190604.22e17669@EQL.Caltech.Edu> Message-ID: <9409020357.AA18261@> Date: Thu, 1 Sep 94 19:06:16 PDT From: rankin@EQL.Caltech.Edu (Pat Rankin) It appears that diffs-940831.gz ended up truncated. It's really small and after applying it first, diffs-940901 gets some rejections and fuzz reports. Yup. Looks like the last weekly diffs were empty too. I've deleted both. Yet another patch for the snapshot script... From jrs@world.std.com Wed Sep 7 01:06:00 1994 From: jrs@world.std.com (Rick Sladkey) Date: Wed, 07 Sep 1994 01:06:00 -0000 Subject: linux and bfd_gas Message-ID: <941307.040509.jrs@world.std.com> Recently using bfd for gas on linux was made preferred in the configuration. This doesn't work for a.out because the relocations for PC-relative function calls (e.g.) don't come out right. For example: $ cat main.s .file "main.c" gcc2_compiled.: ___gnu_compiled_c: .text .align 4 .globl _main _main: pushl %ebp movl %esp,%ebp call ___main call _sync L1: movl %ebp,%esp popl %ebp ret $ as-940906 main.s -o main.o # The stock 0906 gas. $ objdump --disassemble main.o main.o: file format a.out-i386-linux Disassembly of section .text: 00000000 <_main> pushl %ebp 00000001 <_main+1> movl %esp,%ebp 00000003 <_main+3> call 00000004 <_main+4> # Here is the problem. 00000008 <_main+8> call 00000009 <_main+9> # Here is the problem. 0000000d <_main+d> movl %ebp,%esp 0000000f <_main+f> popl %ebp 00000010 <_main+10> ret ... Disassembly of section .data: $ as main.s -o main.o # My fixed version. $ objdump --disassemble main.o test/as/main.o.good: file format a.out-i386-linux Disassembly of section .text: 00000000 <_main> pushl %ebp 00000001 <_main+1> movl %esp,%ebp 00000003 <_main+3> call 00000000 <_main> # Here it is correct. 00000008 <_main+8> call 00000000 <_main> # Here it is correct. 0000000d <_main+d> movl %ebp,%esp 0000000f <_main+f> popl %ebp ... Disassembly of section .data: $ The problem is that DISP32 relocations on i386-aout are relative to the instruction and not to the section. Here is a patch that fixes the problem for me but I am not positive that it is correct for all targets. ----- Wed Sep 7 03:59:18 1994 Rick Sladkey (jrs@world.std.com) * write.c (write_relocs): Subtract the address from the relocation addend for pc_relative relocations that aren't pcrel_offset. *** gas-940906/gas/write.c-dist Fri Aug 26 17:52:45 1994 --- gas-940906/gas/write.c Wed Sep 7 03:37:49 1994 *************** *** 702,707 **** --- 702,715 ---- /* bfd_perform_relocation screws this up */ reloc->addend += reloc->address; } + + if (reloc->howto->pcrel_offset == false + && reloc->howto->pc_relative == true) + { + /* Targets like i386-aout use the addend instead of pcrel_offset. */ + reloc->addend -= reloc->address; + } + /* Pass bogus address so that when bfd_perform_relocation adds `reloc->address' back in, it'll come up with `data', which is where we want it to operate. We can't just do it by fudging reloc->address, From ian@cygnus.com Wed Sep 7 09:54:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Wed, 07 Sep 1994 09:54:00 -0000 Subject: linux and bfd_gas References: <941307.040509.jrs@world.std.com> Message-ID: <199409071653.MAA24012@sanguine.cygnus.com> From: jrs@world.std.com (Rick Sladkey) Date: Wed, 7 Sep 1994 04:05:09 EDT Recently using bfd for gas on linux was made preferred in the configuration. This doesn't work for a.out because the relocations for PC-relative function calls (e.g.) don't come out right. Actually, this just broke on September 1 due to a change to make the linux targeted gas default to defining BFD_ASSEMBLER. When BFD_ASSEMBLER is defined, gas reloc handling is basically broken, in that making any particular target work requires a lot of senseless twiddling. This twiddling has not been done for the i386-aout target. You can make it work by using the --disable-bfd-assembler argument when you configure gas (this won't work for a cross compiler without a patch I just made to configure, but it should work for native). If you want to fix up the i386-aout target for BFD_ASSEMBLER, the places to change are md_apply_fix and tc_gen_reloc in tc-i386.c. Your proposed patch to write.c will break other a.out targets. Ian From raeburn@cygnus.com Wed Sep 7 16:39:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 07 Sep 1994 16:39:00 -0000 Subject: linux and bfd_gas References: <941307.040509.jrs@world.std.com> Message-ID: <9409072339.AA04759@> I will switch the linux a.out configuration back, so that it doesn't set bfd_gas. I had done it because the non-bfd version silently ignored "@PLT" and the like in the input file, where the bfd version would complain about not being able to generate the relocations. Generating correct results for correct input files is obviously more important than warning about code the assembler shouldn't be getting fed anyways. From matt@apanix.apana.org.au Tue Sep 13 19:44:00 1994 From: matt@apanix.apana.org.au (Matt Baker) Date: Tue, 13 Sep 1994 19:44:00 -0000 Subject: infomation please Message-ID: <199409140244.MAA20280@seldon.apanix.apana.org.au> ---- matt baker matt@apanix.apana.org.au From jrs@world.std.com Tue Sep 13 23:16:00 1994 From: jrs@world.std.com (Rick Sladkey) Date: Tue, 13 Sep 1994 23:16:00 -0000 Subject: properties of weak symbols Message-ID: <941314.021710.jrs@world.std.com> I am not quite sure how elf weak symbols are supposed to work but the following program doesn't work when linked dynamically using gas-940906 configured for i486-linuxelf. main() { extern char **environ; extern char **__environ; printf("%s\n", environ[0]); printf("%s\n", __environ[0]); } Under Linux (whose libc is partically glibc derived) __environ is supposed to be an alias for environ. I don't know why. Anyway, when compiled it resolves environ and __environ to two different addresses and environ ends up NULL. This is becuase the "weakness" of environ is lost when linking --shared. This only happens when there is a reference to the weak symbol in another object in the link. Here is a precise example: $ cat __environ.S .globl __environ .data __environ: .long 0 .type __environ,@object .size __environ,4 .weak environ environ = __environ $ cat environ-ref.c environ_ref() { extern char **environ; printf("%s\n", environ[0]); } $ gcc -b i486-linuxelf -fPIC -c __environ.S environ-ref.c $ nm __environ.o | grep environ$ 00000000 D __environ 00000000 ? environ $ nm environ-ref.o | grep environ$ U environ $ ld -m elf_i386 --shared __environ.o environ-ref.o -o libenv.so $ nm libenv.so | grep environ$ 00001260 D __environ 00001260 D environ $ gcc -b i486-linuxelf -nostdlib /usr/lib/elf/crt0.o data.c -L. -lenv /usr/lib/elf/libc.a $ nm | grep environ$ 08009480 B __environ 08009484 B environ $ Notice how the last grep shows environ and __environ being allocated at different addresses. So you can see that it is impossible as it currently stands to have a reference to an weak symbol in an library linked as a shared object. Linking relocatably has the same behavior. My intuition is that linking --shared or -r should cause weak symbols to be preserved and cause references to them to be resolved to the symbol the weak symbol is equated with. That is, weak symbols should only disappear in a ordinary link. How does the SVR4 linker handle this? From ericy@cais.cais.com Wed Sep 14 05:27:00 1994 From: ericy@cais.cais.com (Eric Youngdale) Date: Wed, 14 Sep 1994 05:27:00 -0000 Subject: properties of weak symbols References: <941314.021710.jrs@world.std.com> Message-ID: <199409141223.IAA15408@cais.cais.com> >My intuition is that linking --shared or -r should cause weak symbols >to be preserved and cause references to them to be resolved to the >symbol the weak symbol is equated with. That is, weak symbols should >only disappear in a ordinary link. > >How does the SVR4 linker handle this? Under SVr4, the weakness of a symbol is lost if you reference the symbol within the shared object. Thus you need to be diligent about not using any weak symbols within the shared library. I believe that even if the symbol is referenced and the weakness lost, the two symbols should be assigned the same address. This is probably a bug of some sort, I guess. -Eric From ian@cygnus.com Wed Sep 14 08:22:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Wed, 14 Sep 1994 08:22:00 -0000 Subject: properties of weak symbols References: <941314.021710.jrs@world.std.com> Message-ID: <199409141522.LAA14643@sanguine.cygnus.com> From: jrs@world.std.com (Rick Sladkey) Date: Wed, 14 Sep 1994 02:17:12 EDT I am not quite sure how elf weak symbols are supposed to work but the following program doesn't work when linked dynamically using gas-940906 configured for i486-linuxelf. main() { extern char **environ; extern char **__environ; printf("%s\n", environ[0]); printf("%s\n", __environ[0]); } I don't think your test case showed why this program would fail, unless your libc is incorrect in some respect. Under Linux (whose libc is partically glibc derived) __environ is supposed to be an alias for environ. I don't know why. It's because environ is in the ANSI C reserved name space. Therefore, a user program must be permitted to redefine environ. However, some library routines will need to get access to the environment. The library routines must always refer to __environ, not to environ. If they ever refer to environ, they could get confused by a user program which redefined environ. environ is made a weak alias for __environ to provide the traditional UNIX behaviour for programs which do not redefine environ. Anyway, when compiled it resolves environ and __environ to two different addresses and environ ends up NULL. This is becuase the "weakness" of environ is lost when linking --shared. This only happens when there is a reference to the weak symbol in another object in the link. By the above argument, there should never be a reference to environ, rather than __environ, in another object in the link --shared. At least, not for libc. If there is such a reference, you are doing something wrong. However, I agree that the linker is doing something strange. I checked your test case on Solaris, and it does preserve the weakness. Apparently Eric's i386 SVR4 system does not. However, unless there is some reason to preserve the i386 behaviour, I think the Solaris behaviour makes more sense. Eric, if you know of any reason to preserve the i386 behaviour, let me know. This patch to bfd/elfcode.h will change it to preserve weakness even for symbols which are referenced by another object. Ian Index: elfcode.h =================================================================== RCS file: /rel/cvsfiles/devo/bfd/elfcode.h,v retrieving revision 1.126 diff -p -r1.126 elfcode.h *** elfcode.h 1994/09/12 22:16:27 1.126 --- elfcode.h 1994/09/14 15:02:15 *************** elf_link_output_extsym (h, data) *** 5855,5864 **** sym.st_size = h->size; sym.st_other = 0; if (h->root.type == bfd_link_hash_weak ! || ((h->elf_link_hash_flags & ELF_LINK_HASH_DEFINED_WEAK) != 0 ! && ((h->elf_link_hash_flags & (ELF_LINK_HASH_REF_REGULAR ! | ELF_LINK_HASH_REF_DYNAMIC)) ! == 0))) sym.st_info = ELF_ST_INFO (STB_WEAK, h->type); else sym.st_info = ELF_ST_INFO (STB_GLOBAL, h->type); --- 5855,5861 ---- sym.st_size = h->size; sym.st_other = 0; if (h->root.type == bfd_link_hash_weak ! || (h->elf_link_hash_flags & ELF_LINK_HASH_DEFINED_WEAK) != 0) sym.st_info = ELF_ST_INFO (STB_WEAK, h->type); else sym.st_info = ELF_ST_INFO (STB_GLOBAL, h->type); From roland@gnu.ai.mit.edu Wed Sep 14 11:23:00 1994 From: roland@gnu.ai.mit.edu (Roland McGrath) Date: Wed, 14 Sep 1994 11:23:00 -0000 Subject: properties of weak symbols References: <199409141522.LAA14643@sanguine.cygnus.com> Message-ID: <9409141823.AA00558@churchy.gnu.ai.mit.edu> It is important for glibc that weakness be preserved. From ericy@cais.cais.com Wed Sep 14 12:03:00 1994 From: ericy@cais.cais.com (Eric Youngdale) Date: Wed, 14 Sep 1994 12:03:00 -0000 Subject: properties of weak symbols References: <199409141522.LAA14643@sanguine.cygnus.com> Message-ID: <199409141859.OAA01116@cais.cais.com> >By the above argument, there should never be a reference to environ, >rather than __environ, in another object in the link --shared. At >least, not for libc. If there is such a reference, you are doing >something wrong. No, the problem is different. It is general problem with aliasing which will come up with the following example: .data .globl foo foo: .long 3 .type foo,@object bar=foo Here we have two different variables at the same address. If this were in a shared library and we link against it, and the application references both foo and bar, then the linker will create space in .bss (actually .dynbss, which is merged into .bss) for both foo and bar, and it will generate R_386_COPY relocations to initialize these from the values in the shared library. In effect, this is what Rick has reported, it is just that the previously .weak variable was converted to .globl when the shared library was created. I have not decided what the correct behavior would be in the above case - one could argue that the current behavior is correct (except for the symbol being changed from .globl to .weak). >Eric, if you know of any reason to preserve the i386 behaviour, let me >know. I cannot think of a good reason. For all I know, it is a bug in the SVr4 linker that we have. >This patch to bfd/elfcode.h will change it to preserve weakness even >for symbols which are referenced by another object. I was about to suggest the same thing. -Eric From hjl@nynexst.com Fri Sep 16 09:37:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Fri, 16 Sep 1994 09:37:00 -0000 Subject: PIC and gas-940916 References: <199409161529.LAA17312@cais.cais.com> Message-ID: <9409161636.AA21249@titanic.nynexst.com> Hi, I fixed a typo and added linuxelf. While compiling the Linux C library with ELF, I got many lockf.s: Assembler messages: lockf.s:29: Error: expression too complex for fixup lockf.s:30: Error: expression too complex for fixup lockf.s:31: Error: expression too complex for fixup lockf.s:32: Error: expression too complex for fixup BTW, I configure gas-940916 with configure --prefix=/usr i486-linuxelf H.J. ----- *** gas/configure.old Fri Sep 16 11:27:32 1994 --- gas/configure Fri Sep 16 11:41:11 1994 *************** *** 982,994 **** # people who are not cross-compiling but are compiling cross-assemblers. echo $ac_n "checking whether compiling a cross-assembler""... $ac_c" 1>&4 if test "${host}" = "${target}"; then cross_gas=yes cat >> confdefs.h <<\EOF #define CROSS_COMPILE 1 EOF - else - cross_gas=no fi echo "$ac_t""$cross_gas" 1>&4 --- 982,994 ---- # people who are not cross-compiling but are compiling cross-assemblers. echo $ac_n "checking whether compiling a cross-assembler""... $ac_c" 1>&4 if test "${host}" = "${target}"; then + cross_gas=no + else cross_gas=yes cat >> confdefs.h <<\EOF #define CROSS_COMPILE 1 EOF fi echo "$ac_t""$cross_gas" 1>&4 *** ld/configure.in.old Fri Sep 16 10:59:15 1994 --- ld/configure.in Fri Sep 16 12:20:25 1994 *************** *** 70,76 **** i[345]86-*-bsd) ld_target=i386-bsd ;; i[345]86-*-bsd386) ld_target=i386-bsd ;; i[345]86-*-aout) ld_target=i386-aout ;; ! i[345]86-*-linux) ld_target=i386-linux ;; i[345]86-*-sysv4*) ld_target=i386-elf ;; i[345]86-*-unixware) ld_target=i386-elf ;; i[345]86-*-netware) ld_target=i386-elf ;; --- 70,77 ---- i[345]86-*-bsd) ld_target=i386-bsd ;; i[345]86-*-bsd386) ld_target=i386-bsd ;; i[345]86-*-aout) ld_target=i386-aout ;; ! i[345]86-*-linux|i[345]86-*-linuxelf) ! ld_target=i386-linux ;; i[345]86-*-sysv4*) ld_target=i386-elf ;; i[345]86-*-unixware) ld_target=i386-elf ;; i[345]86-*-netware) ld_target=i386-elf ;; ------ .file "lockf.c" .version "01.01" gcc2_compiled.: .text .align 16 .globl lockf .type lockf,@function lockf: pushl %ebp movl %esp,%ebp subl $16,%esp pushl %esi pushl %ebx call .L24 .L24: popl %ebx addl $_GLOBAL_OFFSET_TABLE_+[.-.L24],%ebx movl 8(%ebp),%esi movl 12(%ebp),%edx movl 16(%ebp),%ecx cmpl $3,%edx ja .L21 movl %ebx,%eax subl .L22@GOTOFF(%ebx,%edx,4),%eax jmp *%eax .align 16 .align 4 .L22: .long _GLOBAL_OFFSET_TABLE_+[.-.L18] .long _GLOBAL_OFFSET_TABLE_+[.-.L19] .long _GLOBAL_OFFSET_TABLE_+[.-.L20] .long _GLOBAL_OFFSET_TABLE_+[.-.L14] .align 16 .L14: leal -16(%ebp),%eax pushl %eax pushl $5 pushl %esi call fcntl@PLT addl $12,%esp testl %eax,%eax jge .L15 movl $-1,%eax jmp .L12 .align 16 .L15: cmpw $2,-16(%ebp) je .L17 call getpid@PLT cmpl %eax,-4(%ebp) jne .L16 .L17: xorl %eax,%eax jmp .L12 .align 16 .L16: movl errno@GOT(%ebx),%eax movl $13,(%eax) movl $-1,%eax jmp .L12 .align 16 .L18: movw $2,-16(%ebp) movl $6,%edx jmp .L13 .align 16 .L19: movw $1,-16(%ebp) movl $7,%edx jmp .L13 .align 16 .L20: movw $1,-16(%ebp) movl $6,%edx jmp .L13 .align 16 .L21: movl errno@GOT(%ebx),%eax movl $22,(%eax) movl $-1,%eax jmp .L12 .align 16 .L13: movw $1,-14(%ebp) movl $0,-12(%ebp) movl %ecx,-8(%ebp) leal -16(%ebp),%eax pushl %eax pushl %edx pushl %esi call fcntl@PLT .L12: leal -24(%ebp),%esp popl %ebx popl %esi movl %ebp,%esp popl %ebp ret .Lfe1: .size lockf,.Lfe1-lockf .ident "GCC: (GNU) 2.6.0 snapshot 940913" From hjl@nynexst.com Mon Sep 19 14:52:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Mon, 19 Sep 1994 14:52:00 -0000 Subject: merge elf into gcc References: Message-ID: <9409192152.AA26002@titanic.nynexst.com> > > I've been trying out Eric's modified gcc-2.5.8 to produce elf on > linux. So far it's been working pretty well. Do you know when the > elf code will get merged into a gcc-2.6.x? > The problem is not gcc 2.6.x. It is almost there. But I couldn't test it since the new gas2 snapshot couldn't handle the PIC code generated by gcc. I think the gas2 people are working on that. After I have working binutils, I will test ELF in gcc 2.6.x. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From ericy@cais.cais.com Mon Sep 19 15:57:00 1994 From: ericy@cais.cais.com (Eric Youngdale) Date: Mon, 19 Sep 1994 15:57:00 -0000 Subject: merge elf into gcc References: <9409192152.AA26002@titanic.nynexst.com> Message-ID: <199409192249.SAA01127@cais.cais.com> >The problem is not gcc 2.6.x. It is almost there. But I couldn't test >it since the new gas2 snapshot couldn't handle the PIC code generated >by gcc. I think the gas2 people are working on that. After I have >working binutils, I will test ELF in gcc 2.6.x. I am leaving this for Ken to fix. In the mean time, you can use the binary version of binutils that I uploaded to tsx-11, as this seems to work just fine compiling PIC code. -Eric From neal@ctd.comsat.com Mon Sep 19 18:17:00 1994 From: neal@ctd.comsat.com (Neal Becker) Date: Mon, 19 Sep 1994 18:17:00 -0000 Subject: merge elf into gcc References: <9409192152.AA26002@titanic.nynexst.com> <199409192249.SAA01127@cais.cais.com> <199409192249.SAA01127@cais.cais.com> Message-ID: >>>>> "Eric" == Eric Youngdale writes: Eric> I am leaving this for Ken to fix. In the mean time, Eric> you can use the binary version of binutils that I uploaded Eric> to tsx-11, as this seems to work just fine compiling PIC Eric> code. Thanks Eric. The reason I'm asking is because I use a lot of c++, so things are a bit messed up here. I had to install libc-4.6.x because binutils were linked against it. So with libc-4.6.x + gcc-2.5.8 I can't use c++, so I was just wondering when this would be merged. Need any help? From hjl@nynexst.com Mon Sep 19 18:57:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Mon, 19 Sep 1994 18:57:00 -0000 Subject: merge elf into gcc References: Message-ID: <9409200157.AA26260@titanic.nynexst.com> > > >>>>> "Eric" == Eric Youngdale writes: > > Eric> I am leaving this for Ken to fix. In the mean time, > Eric> you can use the binary version of binutils that I uploaded > Eric> to tsx-11, as this seems to work just fine compiling PIC > Eric> code. > > Thanks Eric. The reason I'm asking is because I use a lot of c++, so > things are a bit messed up here. I had to install libc-4.6.x because > binutils were linked against it. So with libc-4.6.x + gcc-2.5.8 I > can't use c++, so I was just wondering when this would be merged. I am all set to make an ELF binary version of gcc 2.6.x snapshot. But I need the binutils source which supports ELF/PIC to try it out. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From hjl@nynexst.com Mon Sep 19 20:16:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Mon, 19 Sep 1994 20:16:00 -0000 Subject: A change to ld in the binutils 2.4 breaks Linux Message-ID: <9409200315.AA26366@titanic.nynexst.com> With ld from binutils 1.9, under linux gcc foo.c bar.c won't link. This feature is used by the Linux shared library to make sure all the necessary libraries are linked in. But with the new binutils, under Linux gcc foo.c bar.c links ok. That breaks the Linux shared library. Eric, we have to either change our tools or modify the binutils. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com -----foo.c---- main () { extern int x; return x; } ----bar.c---- int x = 0; asm (".stabs \"_need_this_one\",0,0,0,0"); From ian@cygnus.com Tue Sep 20 08:38:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Tue, 20 Sep 1994 08:38:00 -0000 Subject: A change to ld in the binutils 2.4 breaks Linux References: <9409200315.AA26366@titanic.nynexst.com> Message-ID: <199409201538.LAA20692@sanguine.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Mon, 19 Sep 94 23:15:47 EDT But with the new binutils, under Linux gcc foo.c bar.c links ok. That breaks the Linux shared library. Eric, we have to either change our tools or modify the binutils. -----foo.c---- main () { extern int x; return x; } ----bar.c---- int x = 0; asm (".stabs \"_need_this_one\",0,0,0,0"); The new linker does not complain about undefined symbols unless they are needed in relocs. This is consistent with the SunOS linker, at least, and, I suspect, other linkers as well. I'm not entirely sure what the objective is here, but if what you want to do is simply determine whether a particular symbol is defined, you could just use the autoconf approach. Ian From hjl@nynexst.com Tue Sep 20 20:38:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Tue, 20 Sep 1994 20:38:00 -0000 Subject: A change to ld in the binutils 2.4 breaks Linux References: <199409201538.LAA20692@sanguine.cygnus.com> Message-ID: <9409210337.AA29137@titanic.nynexst.com> > The new linker does not complain about undefined symbols unless they > are needed in relocs. This is consistent with the SunOS linker, at > least, and, I suspect, other linkers as well. > > I'm not entirely sure what the objective is here, but if what you want > to do is simply determine whether a particular symbol is defined, you > could just use the autoconf approach. > > Ian > Never mind. I have got ELF/PIC working on my machine. But I cannot use the latest snapshot. I had to back out to gas-940912 and then apply the PIC patches for Eric. It works like a charm. Thanks a lot guys. I have built a set of ELF/PIC binaries of gcc, binutils and the Linux C library. Eric, I think we are on the right track. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From hjl@nynexst.com Sat Sep 24 14:45:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Sat, 24 Sep 1994 14:45:00 -0000 Subject: Does ELF support -N? Message-ID: <9409242145.AA00453@titanic.nynexst.com> Hi, I am not sure if ELF supports -N. If not, the ELF functions in ld should ignore that switch. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From hjl@nynexst.com Sun Sep 25 17:37:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Sun, 25 Sep 1994 17:37:00 -0000 Subject: Typo in Fri Sep 23 15:15:31 1994 changes for elfcode.h Message-ID: <9409260036.AA07497@titanic.nynexst.com> Hi, -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com --- Fri Sep 23 15:15:31 1994 Ian Lance Taylor (ian@sanguine.cygnus.com) * elfcode.h (map_program_segments): Don't abort if we allocated too much space for the program header, only if we allocated too little. (assign_file_positions_except_relocs): Similar change. diff -u -r --new-file --show-function-line=^[A-Za-z_] /cygint/s1/users/raeburn/offsite/snap/old/gas-940923/bfd/elfcode.h ./bfd/elfcode.h --- /cygint/s1/users/raeburn/offsite/snap/old/gas-940923/bfd/elfcode.h Wed Sep 14 12:08:35 1994 +++ ./bfd/elfcode.h Fri Sep 23 12:53:51 1994 @@ -1924,8 +1924,9 @@ map_program_segments (abfd, off, first, } /* Make sure the return value from get_program_header_size matches - what we computed here. */ - if (phdr_count != phdr_size / sizeof (Elf_External_Phdr)) + what we computed here. Actually, it's OK if we allocated too + much space in the program header. */ + if (phdr_count > phdr_size / sizeof (Elf_External_Phdr)) abort (); /* Set up program header information. */ @@ -2102,7 +2103,7 @@ assign_file_positions_except_relocs (abf phdr_map = map_program_segments (abfd, phdr_off, first, phdr_size); if (phdr_map == (file_ptr) -1) return false; - BFD_ASSERT (phdr_map == phdr_off + phdr_size); + BFD_ASSERT (phdr_map < phdr_off + phdr_size); ^^^ Should that be + BFD_ASSERT (phdr_map <= phdr_off + phdr_size); } /* Place the section headers. */ From ian@cygnus.com Sun Sep 25 19:49:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Sun, 25 Sep 1994 19:49:00 -0000 Subject: Typo in Fri Sep 23 15:15:31 1994 changes for elfcode.h References: <9409260036.AA07497@titanic.nynexst.com> Message-ID: <9409260249.AA15621@tweedledumb.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Sun, 25 Sep 94 20:37:23 EDT - BFD_ASSERT (phdr_map == phdr_off + phdr_size); + BFD_ASSERT (phdr_map < phdr_off + phdr_size); ^^^ Should that be + BFD_ASSERT (phdr_map <= phdr_off + phdr_size); Yes, it certainly should. I checked that in for somebody in a hurry before leaving for the weekend--I should have known better. Every time you think you don't need to test something, you get nailed. Ian From ian@cygnus.com Sun Sep 25 20:02:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Sun, 25 Sep 1994 20:02:00 -0000 Subject: Does ELF support -N? References: <9409242145.AA00453@titanic.nynexst.com> Message-ID: <9409260302.AA15895@tweedledumb.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Sat, 24 Sep 94 17:45:41 EDT I am not sure if ELF supports -N. If not, the ELF functions in ld should ignore that switch. >From the ld manual: `-N' Set the text and data sections to be readable and writable. Also, do not page-align the data segment. If the output format supports Unix style magic numbers, mark the output as `OMAGIC'. ELF can support this, except for the bit about OMAGIC. It may not work completely correctly, but it certainly could. Ian From hjl@nynexst.com Sun Sep 25 20:05:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Sun, 25 Sep 1994 20:05:00 -0000 Subject: Typo in Fri Sep 23 15:15:31 1994 changes for elfcode.h References: <9409260249.AA15621@tweedledumb.cygnus.com> Message-ID: <9409260304.AA08179@titanic.nynexst.com> > > From: hjl@nynexst.com (H.J. Lu) > Date: Sun, 25 Sep 94 20:37:23 EDT > > - BFD_ASSERT (phdr_map == phdr_off + phdr_size); > + BFD_ASSERT (phdr_map < phdr_off + phdr_size); > ^^^ > > Should that be > > + BFD_ASSERT (phdr_map <= phdr_off + phdr_size); > > > Yes, it certainly should. I checked that in for somebody in a hurry > before leaving for the weekend--I should have known better. Every > time you think you don't need to test something, you get nailed. > Thanks. I have two quick questions: 1. When will gas work with PIC? I don't think the current one works. I had to apply Eric's patches to gas-940912 and the PIC codes in the current one cannnot handle the gcc -fPIC output. 2. Should ld -N work on ELF? Has anyone tried it? -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From raeburn@cygnus.com Sun Sep 25 23:25:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Sun, 25 Sep 1994 23:25:00 -0000 Subject: Typo in Fri Sep 23 15:15:31 1994 changes for elfcode.h References: <9409260304.AA08179@titanic.nynexst.com> Message-ID: <9409260625.AA22422@> 1. When will gas work with PIC? I don't think the current one works. I had to apply Eric's patches to gas-940912 and the PIC codes in the current one cannnot handle the gcc -fPIC output. I'll be working on it again after I get a couple of Cygnus customer bug report out of the way. From dj@stealth.ctron.com Wed Sep 28 04:39:00 1994 From: dj@stealth.ctron.com (DJ Delorie) Date: Wed, 28 Sep 1994 04:39:00 -0000 Subject: [ghogenso@u.washington.edu: Problems with .cpp extension: minor annoyances] Message-ID: <9409281141.AA06727@delorie> Is this the desired behavior? gcc *does* support a lot of file extensions for each language. Return-Path: X-Sender: ghogenso@stein2.u.washington.edu Date: Tue, 27 Sep 1994 10:25:42 -0700 (PDT) From: Gordon Hogenson Sender: Gordon Hogenson Reply-To: Gordon Hogenson Subject: Problems with .cpp extension: minor annoyances To: djgpp@sun.soe.clarkson.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII DJ-Mail-Sort: djgpp@, djgpp There are a few problems with the .cpp filename extension under DJGPP. It seems that the various utility programs don't deal well with it. ld reports errors with the wrong filename extension -- always 'foo.cc' even if the file is really 'foo.cpp'. It doesn't seem to be a serious problem with errors and warnings from ld, since I can easily tell what is meant [although I suppose editors that rely on this to locate a position in a source file will not work], but I find that GDB can't find the source files. It looks for 'foo.cc' when it should be looking for 'foo.cpp'. Gordon From ian@cygnus.com Wed Sep 28 08:33:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Wed, 28 Sep 1994 08:33:00 -0000 Subject: [ghogenso@u.washington.edu: Problems with .cpp extension: minor annoyances] References: <9409281141.AA06727@delorie> Message-ID: <199409281533.LAA19725@sanguine.cygnus.com> Date: Wed, 28 Sep 94 07:41:21 -0400 From: dj@stealth.ctron.com (DJ Delorie) Is this the desired behavior? gcc *does* support a lot of file extensions for each language. Date: Tue, 27 Sep 1994 10:25:42 -0700 (PDT) From: Gordon Hogenson There are a few problems with the .cpp filename extension under DJGPP. It seems that the various utility programs don't deal well with it. ld reports errors with the wrong filename extension -- always 'foo.cc' even if the file is really 'foo.cpp'. It doesn't seem to be a serious problem with errors and warnings from ld, since I can easily tell what is meant [although I suppose editors that rely on this to locate a position in a source file will not work], but I find that GDB can't find the source files. It looks for 'foo.cc' when it should be looking for 'foo.cpp'. There is nothing about file extensions in either ld or gdb. Both programs get the filenames out of the debugging information. I suspect that if you examine the debugging information in your .o file, you will find that it refers to foo.cc, not foo.cpp. I suspect further that your foo.cpp file includes # directives naming the file foo.cc. If not, then there is a bug. Please provide a testcase showing the problem. Ian From ghogenso@u.washington.edu Wed Sep 28 19:07:00 1994 From: ghogenso@u.washington.edu (Gordon Hogenson) Date: Wed, 28 Sep 1994 19:07:00 -0000 Subject: [ghogenso@u.washington.edu: Problems with .cpp extension] References: <199409281533.LAA19725@sanguine.cygnus.com> Message-ID: Under DJGPP 1.12 with G++ 2.6.0, I experience the following problem when using filename extension .cpp instead of .cc. The assembler output contains the incorrect ".file" heading. Included here is an intentional link-time error to illustrate that ld then reports the wrong filename. --------------------- main.cpp ------------------------------ int main() { int i; for (i = 0; i < 55; i++) my_function(i); } ------------------- output of 'gcc main.cpp -o main -g -v' -------- Reading specs from d:/gcc/lib/specs gcc version 2.6.0 d:/gcc/bin/cpp.exe -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=6 -Dunix -Di386 -DGO32 -DMSDOS -D__unix__ -D__i386__ -D__GO32__ -D__MSDOS__ -D__unix -D__i386 -D__GO32 -D__MSDOS -g main.cpp f:/cc000073 GNU CPP version 2.6.0 (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: d:/gcc/cplusinc d:/gcc/include /usr/local/lib/g++-include /usr/local/include /usr/local/go32/include /usr/local/lib/gcc-lib/go32/2.6.0/include /usr/include End of search list. d:/gcc/bin/cc1plus.exe f:/cc000073 -quiet -dumpbase main.cc -g -version -o f:/cca00073 GNU C++ version 2.6.0 (80386, BSD syntax) compiled by GNU C version 2.6.0. main.cpp: In function `int main()': main.cpp:7: warning: implicit declaration of function `int my_function(...)' d:/gcc/bin/as.exe -o f:/ccb00073 f:/cca00073 d:/gcc/bin/ld.exe -o main d:/gcc/lib/crt0.o -Ld:/gcc/lib f:/ccb00073 -lgcc -lg -lc -lgcc main.cc:7: main: undefined reference to `my_function' ^^^^^ This is incorrect! -------------------------------------------------------------------------- Running 'gcc main.cpp -g -v -S -o main.s', we get the file main.s: ------------------------------------------------------------------------- .file "main.cc" gcc2_compiled.: ___gnu_compiled_cplusplus: .text .align 2 .def _main; .val _main; .scl 2; .type 044; .endef .globl _main _main: pushl %ebp movl %esp,%ebp subl $4,%esp .def .bf; .val .; .scl 101; .line 3; .endef call ___main .def _i; .val -4; .scl 1; .type 04; .endef .ln 4 movl $0,-4(%ebp) L2: .def .bb; .val .; .scl 100; .line 4; .endef cmpl $54,-4(%ebp) jle L5 jmp L3 .align 2,0x90 L5: .ln 5 pushl -4(%ebp) call _my_function addl $4,%esp .def .eb; .val .; .scl 100; .line 5; .endef L4: incl -4(%ebp) jmp L2 .align 2,0x90 L3: xorl %eax,%eax jmp L1 .align 2,0x90 jmp L1 .align 2,0x90 .ln 7 L1: .def .ef; .val .; .scl 101; .line 7; .endef leave ret .def _main; .val .; .scl -1; .endef ---------------------------------------------------------------------------- Thus the '.file' is incorrect in the assembler output. ---------------------------------------------------------------------------- Thanks, Gordon Hogenson From hjl@nynexst.com Thu Sep 29 22:16:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Thu, 29 Sep 1994 22:16:00 -0000 Subject: ELF/x86 as error message Message-ID: <9409300515.AA21112@titanic.nynexst.com> # gcc-elf -c loop.s loop.s: Assembler messages: loop.s:5: Error: Can not do 1 byte pc-relativerelocation Any reason for ELF/x86 as to do that? Thanks. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com ------ .text .byteloop: movb %al, (%edi) leal 1(%ebx,%edi),%edi loop .byteloop From hjl@nynexst.com Fri Sep 30 06:31:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Fri, 30 Sep 1994 06:31:00 -0000 Subject: bfd assertion fail elfcode.h:5694 Message-ID: <9409301331.AA21792@titanic.nynexst.com> Hi, I got # gcc-elf bar.c -v -fpic bfd assertion fail elfcode.h:5694 bfd assertion fail elfcode.h:5694 bfd assertion fail elfcode.h:5694 bfd assertion fail elfcode.h:5694 # a.out Hello world If bfd assertion fail elfcode.h:5694 is harmless, should we remove it? Thanks. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From eric@aib.com Fri Sep 30 07:05:00 1994 From: eric@aib.com (Eric Youngdale) Date: Fri, 30 Sep 1994 07:05:00 -0000 Subject: ELF/x86 as error message References: <9409300515.AA21112@titanic.nynexst.com> Message-ID: ># gcc-elf -c loop.s >loop.s: Assembler messages: >loop.s:5: Error: Can not do 1 byte pc-relativerelocation > >Any reason for ELF/x86 as to do that? > >Thanks. > >-- >H.J. Lu >NYNEX Science and Technology, Inc. hjl@nynexst.com >------ > .text >.byteloop: > movb %al, (%edi) > leal 1(%ebx,%edi),%edi > loop .byteloop With ELF, there are no 1 byte relocations, so if this is going to be resolved, it has to be done in such a way that no external relocations are generated. Since this is PC-relative, I think this can be done, so I suspect that we simply need to fix gas so that when these relocations are generated internally that the backend performs the relocations itself. In principle it should not be that bad. How well does the latest snapshot of GAS work? Ken claims to have fixed things. -Eric From raeburn@cygnus.com Fri Sep 30 13:01:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Fri, 30 Sep 1994 13:01:00 -0000 Subject: ELF/x86 as error message References: <9409300515.AA21112@titanic.nynexst.com> Message-ID: <9409302001.AA01130@> From: hjl@nynexst.com (H.J. Lu) Date: Fri, 30 Sep 94 1:16:15 EDT # gcc-elf -c loop.s loop.s: Assembler messages: loop.s:5: Error: Can not do 1 byte pc-relativerelocation Any reason for ELF/x86 as to do that? In gas/config/tc-i386.c, the `reloc' function tests for OBJ_ELF, and shouldn't. The 8- and 16-bit relocations should always be generated. In the case of ELF, they should always be eliminated before object file generation, but that happens at a later stage. And in the error message generated in that function, "pc-relative" should have a space after it. :-) From hjl@nynexst.com Sat Oct 1 09:10:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Sat, 01 Oct 1994 09:10:00 -0000 Subject: X11R5/ELF build, was: bugs in gas-940912elf.1.tar.gz and gcc-2.6.0-940923.elf References: Message-ID: <9410011609.AA23991@titanic.nynexst.com> > >I am not sure if it is a GNU ld bug or the Linux d-linker bug. > >I checked it on a UnixWare. It worked as expected. I think > >The Linux d-link should bind the undefined function symbols in > >the non PIC executable to the PLT address. I will be out o > >f town until next Wendesday. I will take a look then if you > >don't have the time. > > My main machine is here at aib, but I need to find a 10baseT > cable to connect it. Once I do this, I should be able to say better > what the problem is. > > In general, the dynamic loader will be binding symbols to > whatever address appears within the symbol table of the shared object. > This tends to be the actual address of the symbol, and not the PLT > address. I made the decision to do it this way because the > performance will be a little bit better this way, but as you say, the > comparison tests will fail. I had thought that I set things up the > same way that Unixware does, but it would be relatively easy to change > the dynsym section so that it points to the PLT entry instead of the > function itself. Eric, I was wrong in my previous mail. It looks the function address printed out in the shared library is invalid. I asseum either there is no entry in GOT or the entry is wrong. > > -Eric > > I am sending the test to the gas2 list. It looks like the bug can be in ld and/or d-linker. I want to first make sure the GNU ELF ld does the right thing. I was wondering if anyone has the GNU ELF ld running on a SVR4/x86 box. I would appreciate he/she could run the test included here. You can unpack the tar file and do cd elf vi Makefile # for CC and how to build the shared library make make runtest Under i486-linux, the address of the function in the shared library is printed out wrong. It looks like there is no entry for that function in the GOT. But if I compile main.c with -fPIC and link main.o against the shared library, the entry is there. It seems the d-linker failed to build an entry for that function. But the global variable is ok. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com ----- begin 644 elf.tar.gz M'YV09=B8>0&@H,&#"!,J7,BPH<.'$!&"F'BC1@T0 ";&L''#!L:)&F5\!$ER M(HR)-6S0D'$CQ@P8-BY2M.$R8XV(.'/JW,D30)TY=,+(F0@ C1HV/1D"#6/& M3-*G4*-*G4JU:L2 YN$65/&3!HV9:R*M0I2)8V1&SN.!#%CQMF,)2FR1*F2 MI4N8,F/$@.$V(XRQ@ ,?_!ET*$:C2*NFF9-8L./'D".+'3($1 \09\:,:8%5 M@8(P;-CH $&ER!0JGN74<4.G#-#1H-DH2 "$"9$O3)((D1)$2I8O4()00=+# M!0@7+TJ?]LPFC1CE5%S,>>,BA@L8UT>3J=.F31X7;T#,02.T#!GPLTF@L)T" M1(LV(+!^23,#A\<6+<:7)^,^_QLW8;11!@C-/6=:=--5YUYX) !PG;=?1>> M?G*8AUX"ZDG11'L%0B?=&[.QX89[^&%Z*&C(X8DNIACB MB/F9:.!I'U9WW74ZHDA=#)Y!-UH;8:3A!GA!UCCDCS# 2%E[+3#H())*,MD" M$\:UP 9TGKDP!G@Z2#D$E6.X9P842536PA,BD<##@B TZ!F62[YQ9))+CF$F MFN[!6>><5=8)A&=C@!6&&V5B&..&(*C I I^@##&&Q6"$ 9X==!!VH%-\CB= M"@I(5A!6+T#HG9BFMKI0632\I1%''L'%EEMKQ45##'2MU-)+,6D$$PU_@?"7 MJ\A&1)A01"%FU6*-)2OMM-129<<;:?"G:AXH7)MM"@KLH0!)%=)1AQQN[*! M'Z56Z^Z[\,8K[[STUML0JGBR:B]@L,H*0EJU@M26OW'-4(-((*3DZUW!_@L# M#2GYM:^KRQI6U%'/,C;QQAP#-H*2B=9!QH \ $5&&M2AX8-G9>#1&KH@>*LM M=]YUBRT9*:C;\LLCRBP>>162 8<<;XQA\[?J*K 4'6FDZ?/230]=]-$XASLN M2$,K28<9*(@ ]1A2CZ$=S7GT ,>)<" QY"*2Q*%YH6-@MU_!\4TV$0;33A(Y9X[(@SJLMOQY)17'A6J@)\WAN5/]8L6 MK6L-G"M),=QP0Z]V 9O77C#<9"SG@57<+,:*:0S[[;@?]+$;(8\,0LETG)SR MR@KL7 ;,/F_+=])/ QUXXGQ;35+6K''MM?-")SYVA&:CK3;;;L,M-VMTDVVW MY+FGK_[Z[+?O_OOPQR___/37;__]^.>O__[\]^___P ,H '2, "&O" "$R@ D A?(P 8Z\($0C* $)TC!"EKP@AC,H 8WR,$.>O"#( RA""L( end From eric@aib.com Sat Oct 1 09:12:00 1994 From: eric@aib.com (Eric Youngdale) Date: Sat, 01 Oct 1994 09:12:00 -0000 Subject: X11R5/ELF build, was: bugs in gas-940912elf.1.tar.gz and gcc-2.6.0-940923.elf References: <9410011609.AA23991@titanic.nynexst.com> Message-ID: >Eric, I was wrong in my previous mail. It looks the function address >printed out in the shared library is invalid. I asseum either there is >no entry in GOT or the entry is wrong. I am now looking at it, and it looks like a d-link problem. I ran the same thing under unixware, and both addresses printed as the 0x0800xxxx address. I do not know why the problem is coming up exactly, but I should have a solution shortly. -Eric From raeburn@cygnus.com Mon Oct 3 00:30:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Mon, 03 Oct 1994 00:30:00 -0000 Subject: net release coming soon Message-ID: <9410030730.AA04516@> I'd like to get a net release of gas+binutils out sometime Real Soon. If you haven't tested on your system in a while, please give it a shot and let me know if there are problems. I've changed some of the assembler's relocation handling a bit recently to try to get i386 svr4 pic support working, and it still bootstraps okay on the sun4, so I don't think it's too broken. If you've sent me patches that've only been half-way integrated, please remind me to finish; I'll be rechecking my mail, but I might miss something somewhere. If you've sent me patches that haven't been integrated at all, and they're adding new functionality rather than fixing bugs, I'm probably waiting until after the release -- but once it's out, it couldn't hurt to remind me again. If we get really lucky and there aren't any serious problems, I'll try to release it around next weekend. Otherwise, maybe early next week -- that'd still leave time to get a bug-fix release out later this month if needed, before the FSF's next CD-ROM is cut. I'll probably release the whole package under the name "binutils 2.5", and just send out a notice about gas being incorporated into binutils at this point. I'm willing to be persuaded that it should be "gas 2.5" instead, but I'm inclined to think that gas does not have *that* much more name recognition, and "binary utilities" is a more correct name... Ken From raeburn@cygnus.com Mon Oct 3 08:40:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Mon, 03 Oct 1994 08:40:00 -0000 Subject: net release coming soon References: <9410031426.AA04621@delorie> Message-ID: <9410031540.AA04578@> A reminder: the gas+binutils snapshots can be found on ftp.cygnus.com, in /private/gas. They're usually made each night, barring problems on the machine making them... From TRANLE@intellicorp.com Mon Oct 3 20:11:00 1994 From: TRANLE@intellicorp.com (Minh Tran-Le) Date: Mon, 03 Oct 1994 20:11:00 -0000 Subject: bfd assertion fail in cofflink.c:1397 on aixps2 Message-ID: <199410040301.AA09850@bridge2.NSD.3Com.COM> Hi, I was trying the latest gas+binutils under aix ps/2 and I am getting the following error from the new linker: gcc -O -shlib -o nm.new nm.o bucomm.o version.o filemode.o ../bfd/libbfd.a ../libiberty/libiberty.a bfd assertion fail /minh/gnu/src/gas-941003/bfd/cofflink.c:1397 At the line 1397 of cofflink.c there is following code: BFD_ASSERT(auxp->x_file.x_n.x_offset >= STRING_SIZE_SIZE) and that assert fail when I am using shared libraries under aix386 with: auxp->x_file.x_n.x_offset = 0 and STRING_SIZE_SIZE = 4 Does anybody have the same problem on other svr3 shared libraries ? I seems that some of my shared libraries contains .file symbol with a null symbol. Can I just ignore those bogus .file symbols ? Thanks, Minh Tran-Le. ------- From ian@cygnus.com Tue Oct 4 08:53:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Tue, 04 Oct 1994 08:53:00 -0000 Subject: bfd assertion fail in cofflink.c:1397 on aixps2 References: <199410040301.AA09850@bridge2.NSD.3Com.COM> Message-ID: <199410041553.LAA01001@sanguine.cygnus.com> Date: Mon, 3 Oct 94 20:00:16 PDT From: Minh Tran-Le At the line 1397 of cofflink.c there is following code: BFD_ASSERT(auxp->x_file.x_n.x_offset >= STRING_SIZE_SIZE) and that assert fail when I am using shared libraries under aix386 with: auxp->x_file.x_n.x_offset = 0 and STRING_SIZE_SIZE = 4 Does anybody have the same problem on other svr3 shared libraries ? I seems that some of my shared libraries contains .file symbol with a null symbol. Can I just ignore those bogus .file symbols ? cofflink.c is buggy. Here is the patch. Ian Index: cofflink.c =================================================================== RCS file: /rel/cvsfiles/devo/bfd/cofflink.c,v retrieving revision 1.5 diff -p -r1.5 cofflink.c *** cofflink.c 1994/09/27 21:09:20 1.5 --- cofflink.c 1994/10/04 15:52:37 *************** coff_link_input_bfd (finfo, input_bfd) *** 1388,1394 **** { /* If this is a long filename, we must put it in the string table. */ ! if (auxp->x_file.x_n.x_zeroes == 0) { const char *filename; bfd_size_type indx; --- 1388,1395 ---- { /* If this is a long filename, we must put it in the string table. */ ! if (auxp->x_file.x_n.x_zeroes == 0 ! && auxp->x_file.x_n.x_offset != 0) { const char *filename; bfd_size_type indx; From hjl@nynexst.com Wed Oct 5 14:55:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 05 Oct 1994 14:55:00 -0000 Subject: ELF PIC linker/assembler Message-ID: <9410052155.AA02939@titanic.nynexst.com> Hi, I am trying to add the shared C++ ELF library to Linux/GNU. I got the patches for gcc 2.5.8. But I am not sure if they work with gas+binutils. I was wondering if anyone has built the ELF/PIC as/ld for any SVR4/x86. It seems there are some bugs in the ELF/PIC as/ld for x86. If anyone is interested, please drop me a line. I will send you the patches for gcc 2.5.8. You need to apply the patches to gcc 2.5.8 and build the patched gcc 2.5.8. Then test if the ELF/PIC as/ld for x86 can build the shared C++ ELF library under SVR4/x86. Thanks. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From hjl@nynex-ms.nynexst.com Tue Oct 11 23:11:00 1994 From: hjl@nynex-ms.nynexst.com (H.J. Lu) Date: Tue, 11 Oct 1994 23:11:00 -0000 Subject: Bad crt files References: Message-ID: <9410120341.AA13720@titanic.nynexst.com> > > Better. But change the Makefile to use add -g to each compile and > link step, then it segfaults again. Can I use -g at the link step with the shared library since libg.a is not a shared library? Can a shared library be loaded in without libc.so? Maybe there is a bug the GNU ld that couldn't handle mixing a shared library with a static C library right. Or is that a dynamic linker bug? BTW, Ian, how compatible is the GNU ELF ld with SVR4/x86 ld? Can it be a dropin replacement? Has anyone tried to use the GNU ELF ld to build a shared ELF library under SVR4/x86? > > This simple example built fine with or without -g with the previous > tool releases. > -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From eric@aib.com Wed Oct 12 07:34:00 1994 From: eric@aib.com (Eric Youngdale) Date: Wed, 12 Oct 1994 07:34:00 -0000 Subject: Bad crt files References: <9410120341.AA13720@titanic.nynexst.com> Message-ID: >BTW, Ian, how compatible is the GNU ELF ld with SVR4/x86 ld? Can it >be a dropin replacement? Has anyone tried to use the GNU ELF ld to >build a shared ELF library under SVR4/x86? Yes, I used to do this all the time at my old job. I intended it to be a drop in replacement, but the handling of the SHT_DYNSYM sections in our version of SVr4 was a bit weird, and Solaris treated things more logically. That being said, a little work might be needed on some flavors of SVr4 to support a unified symbol table which the Dell SVr4 seemed to want. This could be a linker option, I think. -Eric From hjl@nynexst.com Wed Oct 12 22:18:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 12 Oct 1994 22:18:00 -0000 Subject: GNU ld, ELF and C++ References: Message-ID: <9410130518.AA16303@titanic.nynexst.com> > > > >BTW, Ian, how compatible is the GNU ELF ld with SVR4/x86 ld? Can it > >be a dropin replacement? Has anyone tried to use the GNU ELF ld to > >build a shared ELF library under SVR4/x86? > > Yes, I used to do this all the time at my old job. I intended it Have you tried gcc -shared -o libfoo.so *.o with the GNU ld under SVR4/x86? First, GNU ld doesn't take the flags for SVR4/x86 ld. Do you use a special specs for GNU ld under SVR4/x86? I had to edit specs a little bit. I changed "%{shared:-G -dy}" to "%{shared:-shared}". My test case is little bit tricky since I am working on the ELF support for the C++ shared library. My stuff works with the GNU as and SVR4/x86 ld, but not the GNU ld. If I create the shared C++ ELF library under SVR4/x86 with the GNU as and SVR4 ld, the global ctors and dtors in the shared C++ ELF library are called in the right order. But the shared C++ ELF library created with the GNU as and GNU ld won't call those global ctors and dtors at all. It looks that there are bugs with creating the shared ELF library in the GNU ld. If anyone is interested, I can send my test case. > to be a drop in replacement, but the handling of the SHT_DYNSYM sections > in our version of SVr4 was a bit weird, and Solaris treated things more > logically. That being said, a little work might be needed on some flavors of > SVr4 to support a unified symbol table which the Dell SVr4 seemed to want. > This could be a linker option, I think. > > Eric, there is a bug in the Linux d-linker. It has something to do with mixing the shared/static libraries. I will send you a test case later this week. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From hjl@nynexst.com Thu Oct 13 13:50:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Thu, 13 Oct 1994 13:50:00 -0000 Subject: A GNU ld ELF bug Message-ID: <9410132050.AA01944@titanic.nynexst.com> This test case shows a GNU ld ELF bug. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com --- This directory contains files for SVR4/x86. There are two .s files, main.s and libmine.s. libmine.s is used to build libmine.so. In ./lib, there are three speciall files, crtbegin.o, crtend.o and libgcc.a. The goal is build libmine.so and link it with main.o, then run the resulting binary, TEST. The expected output is: # LD_LIBRARY_PATH=. TEST A ctor called Hello foo Hello ELF C++ A dtor called But if libmine.so is built with the GNU ld in gas-941012, the output is: # LD_LIBRARY_PATH=. TEST Hello foo Hello ELF C++ Two calls in libmine.so are missing. libmine.so.gnu is built with the GNU ld: # gnu-ld -shared -o libmine.so ./lib/crtbegin.o -L. -L./lib libmine.o -lgcc ./lib/crtend.o -lgcc and libmine.so.svr4 is built with the SVR4/x86 ld: # /usr/ccs/bin/ld -V -G -dy -Y P,/usr/ccs/lib:/usr/lib -Qy -o libmine.so ./lib/crtbegin.o -L. -L./lib libmine.o -lgcc ./lib/crtend.o -lgcc For the timeing, this test case has to be run under SVR4/x86. TEST is built with # gcc -L. -B./lib/ -o TEST main.s -lmine ---- begin 644 c++.elf.tar.gz M'XL( !:=G2X ^Q=#71;Q94>68I_A,%.,! @91^- _F5)?DG=B#9.$%)"C;D M3X%"%D66GFT%17(E/6.R,9B*0)57;]T"N^UN2^D>MMMN.5T:*%!@SYH0DL#I M;IV0I4XW[:9LX 3B;L,>+_'INO7>^V:>-&\L62_!20/K.4>^[\[<^7DS\^YW M9^:^9T=5O-T?DX-5Y-P%J<:YN+96(I+DJEM_V7^/W!H*RXZV MB#+)=;B4==V2)7-74N'K#TD5-#FG1"D=5.-12)2VZ35K4:;?[ MP^$E$D1L"T5D1SPJ;?1LV&BWX]\ETC9_*.*(VTLJYZY<.4^"OUHQ\Z1%4:ER MN51YM[0HC-GL]H0<3RRQES3=Y&OZW(KUC>L_[UO;N''-4L<-4C@8U(J\@16L MUQ3E*M4K6!20*F_,B,0YF6B61M"YGVZ,W1X(R_[($I1DUI'W^:]QIY__:J<+Q*J=BZNGGO_S$>CSOT@.M^J/ M/;V^4)[V$IP@4X_\.0OIYQ^'^!S58=K^<]?5UM;"M0LTQI3]=UZ"8?P#L42+ MW :/<'12Z\BC_V'4:^CXN]QUU8NI_J]S3>G_\Q$>\#2MLE@L:=Y"K,3"I6^T M4EJC_9U++B$7&?)[4^^FAO[LM=YGD4F^C'_'$O:^ON2^T>2R,64DN<^67$82 MI6HA7(T-P+4RW)M$L;4G1L?&QGKED;ONQA+Z:&#ED>)T>PAQNAQ.%Q;,@E#_ MI@TG\.JN!U_3VKIZYYGC\OFT)?PO01(S2=OTJ(77 Z_VX5^P' M_$JX^(=@."2@I2P_CA;V^ +&ZZ/Y=:$^ M?51=3#Z?7!W\^)%%N0J.UV?1C4*]3W-E\.6M%.2>8>T0Y6XFQG[IA]]T3D[O M%YP??+\\-8V65\K*U?OE3F)\'@\2G%/C[V,ZUS8,_PF_0!8YI 5<_!J(V *_ MBUFY-M;&$J&\[T&F?\A2'LJ50$>7,8K]7E),^]560!_'8?_M75T_V?Q%/Z?CY /_YORX[\1?RFX]W:,)KM&QQ)7(/C;U<+]VK,, M^$_-@O?3L#\>OTE6[->#T= H.7,[XU-J'ZPV\$5D(\>C/;"#4'S1>3Z,MP?. MOWW0RO&H._]&X#\V_NL8?].$@)\5ZGW^0$(!&1Q37TLT>)_/'PGZ9*@NVJ;( MNB5@/F3#_77B_9+QN+\#NGDFR8_[CPGUY<+]7'(B[J.<&=S_'C&'^[GL Q'W MT3YHS"(GXOYCG#TT$>Y_2,SAOM5B#O?;(6*Y2=S_VRSE:;@.&1':2^"FFQF/ M=90P6P:I@U"[ '6P;9+M /^PP^>+8=_7)CEFZXA9/,3A+0]3$@4\BH@W[V5 MD"_M(J3O$? O*>0J>A'^$J?_C?R7D%8"[/=\EY,T/P'J'Q^/M0YG? ML>V$O =Y?O-%0CYZAY#? [Q-^QJQE%Y#+)?-)Y:K]P! ! *^EL"V#E#Y_GA[ M.!BJIEM72XD,5[FM5(@'*:JJ>L;A!'/,%_(%V&;EM'<&0&[$CU$ESRQVQ M4"31"E>MK7&:UAKJ"K8&0_0JGKY2(O&@D8EG&(-8G$_IXE.ZTBEZ=#CJ3P1# MP=;,=9R[[L+K6PG)"Y"!## MK1EO+YE'3?*=!YOGM]T%N=C*,MP"NM737(I%NH M%Q?W=\HQN2U.,B/JB%:E9ZL;]XZEAMIZJE8D="30-(_DJL6_=+;FLW@[\EN\ MMV]2NXM5I53UE._L3US;U[>K;/6NRU?5'TS,*'O^U0??P1VJ>0,G[=J.UAKE MUZY^,#_O]FGF9U;K%C7N=,"0F1!93QR.*CR'T:Q3II/=8/;<40!&J[226:UU MVBU,UUI^K649_'W14@5*RMU:!:HL4X!V>DMP*[T0*A@E6 'W0'@!Z?E"&GLN M@;_K>C #VA_3(-,+6J:X"T 1NLI*9D.LI8@3&*0";H, HKC$!$:H0&B[#!66 MT'2L$Q$3'GE P!EDAG;OL4073*-6S0;HZ\-^X1I[-K;[.(L]%J510;E%::/& M.KO4B*]#:8GXM\EQ+HF+,V_17V1(LY"K!)X/XRWF?!9Y@AUXN6+6_%/@E#M(50*[:09*S8)J&\IRUTITBL M=[-0'A:2;3>L0RCO98LYJ_A?(.&^+'+C=L. .46H=7L)R6T5UUOI2D,L#]MH M@4PW()U&^PEIB,7W((6"'V;Q7V;T:XP^P>3^F=%CC-HLE!+& _#A:754MWQT M#''EPA!GG6D,F04KC[B?0^KL[/2N_CWXGTOJY<[R6\.E6E. M1?F)UY/F]:#I(.J^&B%=;Z6H^W+)B;HOEYRH^U#.C.[C3Z-X.5'WH=R.+/6* MNJ_81FT%7$I,I/OV$G.ZZFWX>;/(B;IJ(40, ,4Y>#')K:M&+22-AWQY^725 MOMK0M4Q>'5-;;UK'/)G?3DT.58"IBD:J,EWU%*O>TI-?Z-.#ZBU6FTM3WI%4 M\^A/),@P[]54\]#.-QZX;K\']3=)'3@]J$+RJV^]D_(.GW3U&0,DJ8=4#_'"O?%PW?2?4@0_';M40NU%\5Z1;MV MKDF[]@.3=NVH2;NVRZ1=VPX,[[EF%BL>(-2NW">IRHS;C][CJT\XWNDN0?RLL>[R][?B!U8.>A1,'IP=3!/M>ATQ\U A*= M3AU0E5'.O91ZF":'MMR>S6ME;>^S. J;-(^1E&"6=%^O M,DHC=+'^M;V/XL"L5STCU-E$?11+ XA*[JW8>:CLH:0*J+GMB3]GS>P#!]GN&,#W9?8HDR@'+DMLEPF[,.[3?Z9*M]/6OV3U7/\;5:5MOZWB3Z_@,W M0E-='R7WSFQ0CI?]Q0NTR>KRXI3GE3[52#9?0)S8"LKU=+=$^8XC#D.K\)F M?V4#)&R%7AS4[W;O5CLT?BWC#@#G/3>TMY'GQ&BBFEGS$?_)R&1JZ54*[\<%NP[^\MV M>G^/PKNS"_?*C]U%#2S#\V1\EE2E&-VOYE,G+:*4JIP?UOY"?-9I3&I5>4IS MY\HX9Y%<=ALJ'"5!5OCCH8#4$HX&[I$Z8M'64#@4:9-:0Y%0O%T.2M&(-"=N M)ZL 0^%BH30G')1:,EGBDMU.;HQ$(_(RS?E@A5;.[#GS@TLDN4L.* DH8\Y\ MR)0(;9/GQN=)_F P)L?C2R5GUQS'_' 7D?!0.!&*1I9*O$]B:8;P"T,\BO"%804;;Y@J&V4"*.",(? M[>%&>V,/MFE=#S[J: "@0?F2EJ_3'U;P9,Y.C4K,(S&!7V@"T(=RQNC4D14K M1V/W*@LU=@W'Z- O?*'K5BY5ZL<>X+/VYW)FSESY_(>U?(^9<6\;UFI18+M MND_+1T>5)+%56)*A>5<0:A-OT3J_I84\#VA";96+(;I?*V&['(OZ[HW&@F2% M5@+MA$)J8115,=G?:K(XO&C#,M$ "%FL%BJ.\D5ZT5<7H'@@JD1@)'1A0#E6 MM&;2SV>R'DTV8A!.-Z*4+_4+5!)-R5XX86EU)Y MM,^*YC'Y-VG9V!'C&H$N9T4N)OB_FJ#^$&0*QFFC]\4LOB4+M-['I\0'T]/8 M$E:!Q%>PV5Z7$8U6A2""L!.6J>"(8BCK: M'?&PY'*XX.<$ Z6JVE75X)9<]75UDC<2ZI3#XY=(^'0)TQOGO#!K/Y8?:?Z# M%#-K*S&GZRQ;=D]2T=-5,DZMG)ZN*#>1IZN^1JL! MN1]GD;N)&)^Y(9#;P=VO7N\MPOV&RZ@WZ<6L/?K];A+*:R^F><5Z?8+ON&X]4FRHA<.&ZU7897;?: 0>9W+?1AYP_^^0A\I70,$V M4".;+#1]BX6F#S"^H(!29P&56\9H$Z,/L_2^ IKO:<:_P.BK+/[?&?\NXRU6 MRA-O00IX*[/X*(OO0GHEK,NMM']^8*7W]QQ0*W3T M2Y@.#]L^%O\S1K5]@&*V#U#$]@&*V#X &U-<[Z=8_%<8?9S1[S"Y/8R^QR@. MF 7J16,>Y4H9G<'H9RU4[D:D5]%QP/@UC-[*Z)U,+LSH3D:_R>@/&3W Z!%& M3S-:6$#I;$:K&6UF]$Y& XS>QZC*Z/<9?9'10XP>9]1JI?0R1JL9]3#:SBAA M_7(IH[S/J"-J8B^^IJ[>[/[(0G-OY$ZX_VVSG.5Z!)63F?WO]PDUZWG?6;Z, MQAZ\BW7:7S3*T:3_)RU/B]Q&C66T]0R;X+K;GVQ5'.QD7DVA??;')??$N.?6QQ7_RY'&_:BOOB,9/[X@^9W!?7^PUU9O7^&E-^Z4JQVHU^Z:JWHN'G.PH? MN+)A7WR:J__DY7T-^^XM?1$+9'[IB'G$I%\Z]=\^!W[IN, L3.]?I=^N&.^5 MCGJ&>J7KQZ74*]V?[;A4%V&;5X*(ME'"@P0]#=9!PL;N.]V8"Q@>/JW8<%8^ MY_IPF0R?9G_SD2SUBIC091(3OLS6I6*](B8,F,2$;YC$A!^8Q(1*DYA0837Z MP9K%A/L)Q82'6/PN1OL8_2:3T_W-WR,B)N"KQ>/]S-U3?N93?N8YZYOR,\

-VFG\?[1TGW7!#" WS5,W)Z4'-C&#W]BYW]"DZAY#'5.YR6/*XJQ]3NX[3/YC: MD^P^3!)7I@8P\V#JS73>HZIW4&T^FAI(O=DK'V GVQ/IS\?.=M\$!W\B_7D- MH>>X?T6H'Q2TNT&Q7?%30GGV49#P$<51TZWF[A>9B[]'RSH98<6//902M MYWTD8SW_ABLJA_51N^SB#8Z=E7ZEB?YJRX7YCNB(O_'/E^[**VK<):AO<[K M?YPH-PO\&=GS^EOAV;_)PK\K;CIDL_D'Q#:2+.=119ES$LR?ZSRJW#@$.<^C MRS+?I%X'K40&G& Y#^/PCV$;&N#5J&\X2*: M_V(6KY>W72CO]0)SN/OS I/G45;:A[@NF&AM$+89O[S'UVLOHU\C0LVGX? T MAL,VAL,VAL,0_PBCWV;T.4+7#B\QN7Y&]S%ZB,G]#Z/XGC#2:QC%\4*Y^8PN M8?'+&5W%XIL8WLOA5PJ_XO4J_=37/HEWM]3^:/M7$^'TEK/%Z>5D8IQ&KQ9$7 ]#7/W; M'WS^QAZ<-NMZ\!H-W\S9!N!/*-+&.0X9<-=)>&B6NSK0=R<4C621U\XYKF/R MEUIT#QOFHF6 :@>3:K087)C&EZGY _&0>Y=E_%IN\GQJZ!:;WG^? M\9/EQX M6)W96UM.*%;S?N,X4VX1>/&+9)\7^"T"?T;8GOYF3@YP#T5;1(\4?TLT]G&_ MLK9<;#,9C_4#A?1(,A_6]PCUY<+Z7'(BUJ.<&:S/M0\H8CW*;3&!]2-PO^TD M/]8/6\SYGOQI0?9W*T3?DRV<33"1[TFS2:P?**"XF _KRVW$\+5!O3RM'65T MA60MIZK;-IWN2=C *%E,J ]*/AL ?<(0\Q]D\8\PVLOH-YC MA]%=H03WML74_N'4_N'4_N'4_N&D[A_2+]>9WC]TU3J=9G6,B?\@H)];N]XH M>V6?,NU%W!5R2Z5Z^#A->"./'[]&^AL#Y<$'K5P&?L:ASS,SZS9L/9!.;OAL\Y&741LR&;C7L#EY[K#)O7=1AR MZ>-<81\V>8:M M6,SI]T9I^+\SAYUO(SK#+V1EV$3O#+F)GV$7L M#!OD7F.4,*I_R%3<'ZK.A0MU3M.VYPX!%[+L#QFVAW[I*3[R7X-'_N-8SW%/ M8D9RJ/B7LRJUW:"35VK[04>.<7&G!Y.'R/^Q=SW <53G_9W^^0RJ=2;"V,7% M5ZJD5NS8EI#_J'&#E>$HD^' TOB, SBR0 >21Y+-G586Q)=D M3=+0)IFFI3.0#,E :T"BKO]0MRBV@J58%B+5@(RO],*H2,EHK+YOW]O3[KM] MM]^=)%MR[PWF:?>^?6]OW][[?=_O^][WQG^E[9YTQ G U8QP HPA3"SLSPG' M"9X4U@P4T$95%,*&JZ,PL$:BAY\2([BIB"UJ*R16?\AI8A^S9'2R,!PBUQ;' M,NT/@6'%<"SI88615%C"F9@2#&.+'7XDW2-)YDCZ>"9Z)X[D::$_&4W).!*0,_M_9!Q)C..,$T>RWV7/?8C^D*T%.'_(5Y X ]Y1#$=2 MG(/SAY3DLM@PL3V8A8 C^21A]'(EP?E%+'&U>3RN-H_'U>;QN%HJ]QH1N ^> M/CL-_$&OHXBFB3\# O[D#23C3^)<&O@#@1)S@C] 6 '^O$(2^*/G&&_/04'0 MSX@!04OL(>@M(EE;8724Q:!K$8/"SA@4OA(8U'\-89 YKY(,@^)(#&I%8M V M) 8]B<2@(T@,6H[$H-6SC$%/$H9!3_'S?\'K([Q^CLOUD&0,:DT'@[+\>Y9_ MS_+O>LGR[_R^B1/_GK#=]&G&<8[9@I]C$'$X';$2(7YWX,/!W6Y=U56*("^E M'L%$+L*"J@OZ)#\8<0]$)C7_Y,\*5?_$0/-$1\S]SM:27?+G:EGI?AAP(Z_!LDH<,; M-KZ@QD-+1J#O=:YIE\-KQ,PD25T.S%MBRR"LQ!QIQ= M[&+Z?I7P>29KZ*R[5=GJ^NABI]\7FQY;JC@<+W'6[W=8AT"JW\OD1/T>Y##Z M?8,@9[0GZO<'Z<&@C5R2?E^ T^]WY5AW0Y;J]\B8VT9DS.V7D7$X<)&7Z_=% M1(Z5WE0QMSSN!G*8A* -VE"$F'*:%$BPM(!S3)[DM=O/\OH'7.Y-DNSKX'NR MX3!X$SYGQU%GKHFBDNCN8$C+*:?+IZ.3VT*? B@+3/X<-7&&]#5I9C\>L(QH84UX .4 0+Q <^'&( IOR^R9"$'$X6O(*S@Y$X MPJ;L4R/]TS;EB,RF' &;:5_*Y$1\;_G:.@6A'SS%;-J/YJRB&OUJ9% -QOMG-R:OHI,O"7YTC%O[J_/-P M%L1_@V"P(+8A951$(3%'1;CASXL#W>Z:MOTW[,2"[$,R5M98R':;7BK92;>"K8F M2(Z%\&0>"]&>Y:KX\?S1YZ&8N:IE<\!5M<\15[4,P57U([FJ74BN2B8GZOF[ MD%P5[-^QW*8]4<^'/.^86(@)I)Z_!\E5W87DJAY#2J5B.YJD.$ M<57?(%2MVJ\F;[5R ?!6&#R#20H3$U&!Q+.C2-[J M$)*W^@\D;_4.DK>J1_)6K?,H)J+=9NV.',?F+G\!6&#F]:.%Y[>'>F"'AM:<@>&NX"B" M.XQOF['M! F-4F$7_/ *$M[[VNEQT$/$S:U416$2J8["[&Z@UTO$G*;-M*6\ M@5[_2:0^_T1'"P/!_O_83C#8@&F;39^GCV&)X9VIZ62+75\1[XW8^_PQ>Q%T M"_W)L$LF)V(7R&&PJX_@?/Z#!&<[>=/P^9OCV&78M1^)7=U([#J#Q*YT?/[F M?>HM7""]8 ?!V4Q?(\QF,O8DZ.+U,[S^/I?K)J+-Q-[QL(!9&^5Q:NAR>'/!-=@5'G..T9XY;0.!F@%OA M1_3X,W,K!F[!:SM[N!7.XA8[GC^X!8,]6[@5GB/<.B3>&[%?!X7!K6-"?S+< MDLF)N 5R&-SJ)SC<&B8XW"I)8QT4!K=:D;AU#(E;;R-Q*YUU4/,!MUJQN)6- M4GM^M*CM3LYV'F>GN&\D60>& M8!.,#OQCH3^9#BR3$W5@D,/HP. ?-\\Z,AWX),'IP(5('?B[2!WX0:0._$]( M'?@UI Y\!U('WB'1@>$ZT(%O)W.L S>%&YI,&T$[XM/&+6@=^#D!GVSV<>F( M%=^W4_-Y.KN5I9K/K04*+SV6B,/2 F[-7\@<"Z]XZ06E/:H_UGGJJY_BU(YZ MZPJ. MI,0R [_ !9(1?H'3!^,W'R ,O_B86/SFT(:Q00P$-1@1R@SS;#>(,0#NE[K( M0WROQWPV1F: ^Q\BB>LR;F0>;QY#YAK3KH ]83F>WA\&ACSM_6$20X8O=MCT M3=/GLCUAS/,Y%)GM(9,3;0^0P]@>YK7K9CG1]@"Y,9M^1=NC-Y_Y?IWVA!ET MV?NZQ3UA5A?@]H3Y (DY8'M@]H1IIP!M64L/NW\Y!CA M[W&Y;EZ_RVO":W@W0PL0:_1WB&'-)$41BB=Q&ZR9!*SYM8XU7&J,H@ZM&=;$ MYR_6A.8+UH2R6&,]GO]8$\IB34(NBS7S"&N:]]6;H,81:\HWX..H>GD_*7W2 M%0+UQF&$,7"J$E,C<4WQ:)%B53FM1GK!MQQ9385@ZTK-%QOO5V%M97S\5YW= MK:XOJ(%131G1(J/LRHY(+XG\H>8[#6*#6J W(3:L*8-:9)@UVN6;V#ZE]$XI MIZ>4^)028RM&(?+JD[IM-*GV0@-]ZIN)Z_LUI4^+]*O*A!J!:"X*9EW![M1< MGX%9L)]#1I@%6)0*LVXA\&.]05^$!)C5$GP4UMFYV1I.^!D#]#Q#IM$)1LC8 M=?,)%[N*O1$6H(..C66?L+C% +K_)E*@,T0\>JMM@@C\!!;![?X!%2FG(C_- MT9^.JTKO;R?_I1@2.TP2#;I$1)!H,TG\4)=XE4N80?6P2XR-AD>5^,H+A)R< M&;;.7RX2WC+ 5K,/!EZ4+PC':6$O'UI9:+12W]BFBXB.GQ3%#IL'Q'LDR1SE MZD4XCG*E=0BD'*5,3N0H00[#46X0VC,.18X2Y(Z83L@XRBV+&)_IQ%$>R['? M0U3D*.%B#$?Y"^1:T_]"KC4%;,;$1L-^$-*UID6$_#7!Q40;W.3W>0V.%\#X M?R96+#_.ZS-?TG_/PV7M_)S]_-ZP?Y^8=XW<#/ MM_#Z27Z>\/YJFY4F.QUBD]1>Q>]Q?3?&7O7 -M>@(U!S=?P]U3>A_H+%6(.) MZ8N#A>EW%[WP5M$+2J'K-[D4S_T)2G-4'ILV8QL3G+J8_:Y96H1:_APMR M- M5$7AK:N. L=MP&J*_:X-$Y.Y$=OD_KH/B.=MGUI#!>R MV.&7.4Y!9EL^);0CLRUEI@(MB6S M/_"X4%&.WO>AT!D7*"@PLA*,M^/3MMLYB.+H"DZ@;+6,UX"6$MS2\OALYK^]#SNNC+MR\WI\SM_/ZJR1I/C]0VU#74M\4#*W;YSR?EU>4H?/( MO<1_6L9\[K&,4/*:?YC:==M->40JZGM'_UL^H'O4D7]X_[7>RN;Y&I_FX MI/CYWEN[],:V[\W1Q?9.Z56B/>,Y&\_=P(V=C:%6I:[)VQQLWA=ZW!ML?S@8 MK _6>QM;O'OHX_MCB-LTL.7%3'E Z#T5MD @S8VT YA>VW/T]P?>@8+$A@&U MM>%@JWDXJ1U,<:3.U >0"$;^@?7ZD##PN: WD'29!8=NYYW5Z%_0L:L]>E?; M]:Z^2/^_CG=UCTO255)^N3\EC/A\1K^"@EZ=TF3ME#X&\].KBN[7NSM,K,CY M#Q:"D.^G0+:M_J/2]4HXM+ZQY>$FI3ZX/MQ:W[AO7<.Z<).W;%T9_;>!OO3K M;RM;7UD..TAN\@9:&MN"3ODDBY.PWIP M&.<-!.:Z=#E($5>=.,IT.3W.4\+(LI6>,6#3XF0"NFX,<8:Z&?%'; MZ#\O_[Q3^%P3CM/4"Z;?$[N7/?D-LZ<_1:D#H4;ZSM0&VQMM?;JR8J=W'!:_ M'TGF0RO<#*^7D-1\:"\A%DW,S(=:8OV=0,+,%VUXTX#P/9YVL^^\A%CUCCU">T=SK#DYC,\:!;E%](M_ MVD;N<:'?!Q>SL8)^KS?U*^HQ9;DL;E)L3]1CNJG<'A>+Z_00N1[CS;?ZMHWV M])P2-P"447D/?W_RF%X*QW?SS^'YY2UE>B<E[?^(RSW/ZY_P^E4NU\OKB[S.<[$:-HUU M?8)QR""_C-;V:RWV6U_?S^G'.MWZ5RW7R6N/U=[@>F5G?!=K.NESCC';0G!Y;CM(4P!>DAI;&IM M;.$/RJP?0$N&Y@,F-_RT01UY5;]R?VN(/ P/I=@^;N<0H=97^-5]37" M( ,N;S5]#G-3C7"<%BX+0VP/NH^$@N8%#0[%=@\F\1Y),K9V(]=#U O]R7R- M,KFD/9@(<@\FH3U#3O0U@APFKVTO,@\31!+<:-.OZ&OT(M=#-")M_R^[D'O\ M(O,P>7+M?8U&'J85!.=KU..&EB3G77J6US_@I5XUW!B0>^A.!\,\8@>+BI M,.ASQ!Z#Z(,$ .*P8FZM2H_:J8Y"6E((=9G&H? 3>J[:S# (.EP8 '2MX@\, M[@W<+C8*_,[O%8YW"L<9X1$,MST8-=T334ILL<.F*O%^23(V32!S!!X2 M^I-ADTQ.Q":0PV#3MX7V9-@$,4@G#J&_P\]_B]7=X_?=$@E'A!CIW M)2#*&:/*R]!V4+=-W@KC>1GC <_&2]CO(FI^H',DD,V;87W?"%F8/D0#(Z($ MQBXGO3E??^<)NLPDGT;41D[T&;XD:4_T&8(3R<7]9]:=GARN,'"G4^X-)UNK_^97@PIJ"O5//5),EPO@+[ M'K.F]!W"['_^_/1%H.8VJJ+P0ZV.PH(PZYK2NE1+;.&YG& &+D&YEC+\72,& Q]VC%BB2'#%SN[_7.FSV5Q8E&A'=E\+),3 MYV.0P\S'1X3V9/,QR$W:]"O.QX?2B/_%K"T=1,:)_0U2AP0?,29.;"TR_G?E M%5I;^CZO"3'PH;ZQK?9 ;9A6YG@Q&3Z4E]V&CA>K%^+%4#GZ.R+%Y*"B^8K7 M^ JU@*?G@U6EO96^PO"M%#]J-+^G6@L4UNR\3V>0+\(.?::\!?[BGHLN?=U( M<<_P*LT/#92^<;,?,B/K"TR*JVNTP(1Q^==.T/ZB%S]A-&)=U=1\.H9=;EZH.7 9&6@,+RQIEKS3U3S=NCG'<.NKHK]]!8_?L-5=*B' MMEMY.1Q0)TKCE;[B<.VE5IY7H3(P$6[7?!/;2M^@S8_#/4W2;S168VIN_%S7 MG2Y-F2P]+C35+]>S[\N9#-Y5>SE6*[[WD%_(XE%ZFWZBKXIZ. M$Y?U' _TL8SW5_H\H66OZRMS%0^][-)-"?G7+\/90#%]RET5]*[<:KDZ8=K4 M(!4>P[JDC/ 8 NE3X3&PZH#'ZUTK*^.$O2%3:)9QZ[=0MT&0T<';P/$KQ3"F%4XK;'!TU1[8I! "F99NR9P7&Y)/F-JJB\"I41P&4K+9IBRZ;TC:M M%T32LDWY#65QZVKB%KP"L[Y_G3&TLYBDP0ZSS#&P,LP:1L9-R=9"B9@EDQ,Q M2[9F2L2LJ-">#+- SLX6%C$KSFUA)\PZ*+&%1&;=L(F[+YUW;Q^G]A@$7NG4?Z9\G)\WJ4M_*5/F3-A+2R/]:B! M/DB;X'>K_IBF%'9.*:'*C]IN44^J'XTK?:IO5 W$RJ8N;;;8?AV1/J+\GLZN MEIW1Q?H@]SG\=4)]&Y(R&9=V1):3HD.P#$@+Q-1 G"=WNEANL:TKQ]O6GO#I MZ%@VQ2Y9!9?HZ0 OYEIDH12]>J)BE>H;[NQ6[JB\?,"M^?HJ?;'0:!O"OS1_3/7'+T+DP.'#+WMIM<8W#)FD_,-GWZ?M:?Z1 MLZ.+3\!AD'XY_5#U]_2^V,?']8]C].- __@X?..WQZFT;U -]%=^=&"Q M9"0FS&,1;632M52Y)C* 9;.>O&R!=_6K-] ']STD?NOH^ 4._ M&G)EX!-XN.F)6AB2S-);V>I.0Q)[WZP3>05[6N8?D,F)_@&0P_@'*G*(Y84P M_A3] Q6Y+!>2V"]@NUF':: WNXSC\P MEL=.@BZ6*K?^&'T]/V_3GD4'$M=)Y0M[QQ?PO>,+^-[Q!7SO>"KWK[Q^C]=+ MD^QR:Q)*9[L%'GY:-/IVJ M\4ES&\;J)0BPM-KHBK.-WC83&WU!)5*\5FUT> 5FWT:?_42*=C@CWC,4T4:/ M(6UT<8V1S$:7R8DV.LAA;'1QSWJ9C0YR&!M]$FFC/X6TT7<@;?2_1-KH/T;: MZ&N1-OI6B8T.& 8V.OC,KHB-WE87J@L]&A9Q:8LTO@F_)]E=:?+%UNPCAP^G MPA_8:R@C_/&2U/@#A#[@S]\1Z_JE<%U;,!1\-&P)9(+&#++82ZP+E!@8F?/P M,OQ(:G!! ,FUBB->PG!$C W:(1QGM"8I,<3V@%+WT+Y0.DDH[+#$*]XG2<:2 MYY!8LD?H3X8E,CD12T .@R7B,Y!A"<@=M>E7Q)(7\UGZ!^#);J-LX3;.'G4'0I'ZHU*!BDI42JJ4!BD504*^OL]\[,[N[?DC=DRI;DYS MN^_N.]\S[[PSS\QL(3;)F$$=R;Q\U-VL1G16VP2M,1)ZP19>_/%XBQFT2.+E M4]E,L(7WV"VF6UKVF5YQF4L7\[!]Y#:5H*XGV'*E1U&UF%8^&2\@=-D+FM;P M0 =\IMXSE1D/MNQ)IM-91GH+&[CCCD*K!8R25E M=HX,C\J8A;K@(+==^K8T::/R0 @==PA"E43XRDH"GDAF[E-(\SWG MBJ6\19B+**^(4UX\"_FS$,]:OY**N$LJL-JFNY"JM)4EEE&W3YE-.0JH^Z03T8Z912? MIXSTC,>46;#4%FX+K[X"_CF;2OT_:Y%NMZ)AD/[?V]U=3?\/DZXO]?_.CDA' M;X0>=88CG37]?S6,%P&X1L[ELGHQZ]\AI]&Z#$9OMADW&M?S]\\;SH['-]<( MRV<.F\7L%4[_.72#>/^B(5;!-\CWF"%[FHBGY?N2M&H5 V:[-DF_,5NFYHJO ME3QJ%D_$5X0+-YAA4[-W:H;/S]15>:YC&VCM2$=C%5Y#OE=IV&A\7(:;0QK- M#+&+ J:%8GZ;YA;I"I'-R2G0ZRBV.)!\JEZ X:!W>_AQ4N^K]6+6%^\/T/6# M>K&# 31.)<>>[%9)'Z$K3JV]5=+X&B&F2SF80C\@3R-KG/"^XPD/I^MM;G#2 M\R/I7M$_]=#\I%F--J*['M[7OW=HH!H6S(10Y ]V)P3O^ZF=8.CTO5:A*42].M8PF.>X237*4A?S*YZ,0 GC$=QP] M16780)4A?8-84Y##E2I9 51+,$PNDX=2_ MD(:#Q&NGP?G"@4R1[;^=77^A1CP[?9:GO\W9:N):5>O*WY]MY)]@G9U^E[NY M/%62M__1[& MGGLQ#=>T ,B$3DJCY"/,&R0+WR'[-[(?D9TCNT'*/]1FR$J0Z%<@\Q^I$_(> M)X3 P]<,(8\1:XA5R%K(O0G:!Q:=(2IA&Y7 M[CL*BWJRK!,](>YO#KR\9OFG2CL^]4\]MP9P^ _77+53I>=!QR=B^0G#2AS/ M$(NX4J (6P=0%QV'@,7%K7PB*1M9Y__<0PHA=C05EP"\ M^W,3%8#[XLU-L@[7&8ZN](*A[>J4]F99I^MD/8<%JHGZK9!>U/?MLL[7R78! M^YH6GM+@U-<&ZF3]AUTG:;6Z$G2?QH?V MLA:1UQ'3 ZH%K_Z!F%5.O13_Z,:7U.#L(JO2>,[8CA( M.70:6%W?4TCTUS4^G*X,V^S#5S(C05C]*U8J25.:?Y!7A]P+'6S_ONW# MM\TG_V9DWH$/LA5Z=,EPT&25WN<-#?&'4%SK70$BS'<-]W/P?=,G'3_Q\#VU MUO]4T5]Z^ ZM\S_)VHNH%XGO]SY\7D3]HBQ4),DRJB/J%^EAH^;0O3[%WUS] M%?0+?='%N\JE\@LO;KK)0Z_WT!L\]+4>NME#;_30UWGH31YZLX>^WD/?X*&W M5*Q"0@J8.HV%\N,F#XW5]FI,%:#T0&ZI,4F \@.K1)A--_$5(JT:'=?\JR/_ M])D-A#]EB-4F*KQG/?2+GO!?H>M6+7SLB&G3PGM+\R*KR;K8SQ\_4T?LQ8# M[C$B5F_J8\KO2_^5^Y][PG\EX!ZSGO3P_R'@'C.?#;C'D-A]I(]QWPVXQ[@7 M/.%]''"/H3\-N,?81GRRD"\4Q\86L0QL+#L93T8+V:@<* Z,/K@_.CQT8#2* MI<2[7!1_-[AO%R>A>*@P-PE+)B30_22-N*7@VRNIOF,Q'U&[/I(W)X4P&A?#M3]YQ P M9*\R*\!'^X[OWOF%FC'\YW_YF&$%S?SK/\)DNM3\;V>WF/^-1+IJ\[^K8:K- M_^*D8U2"WTD5 O._]:21;B$=0+U7IR9O:Q26=T-R_O<]HM^[2;S'*M!!PYD? MAE:5;A061HT3E'8$<$V/Y@:#:YQ*W.[#=[=VCTVQ M^NIA5>^0_AT^;J&#>(\RO,N'[XMLK"7R=_L\\^IZN*HZHW3MX3I%BYM[&A0M ME) ]ZQ0M.O$1FQ9*ST&;%@X/V;2H32=L6MR@]-WFH7NU^ @/'%\[9]+5\GNJ"1F'')-,ITXG? MVQ[Z?0\_IC$O:N\_\= XK4Y/'[YH]Z&6OEN(OJ2E!_,NRCW2H6N:1@:ZKDP?Z"GX%U2ZK\F_C*<,:@-.%T%]4+KY,P$A-Y7_ MSWGXOQ<0^=$J_?MUP*E/X/\M=&E3Z>:F\6; J7]X#]WYA.G$]R./__\)./4= M_'/PWU2ZM\E/&%/MJ46>PBUUAL]%K=94VJHZK"K*S5V!+!-QY3^-F%,L G_"^, MGUW^Z.K@9QPOT_ S9KCQ,[3*>?"S2SP)E\J+PL\F%L+/'+QIYH*=7>W7 0X: MTO&SF7]0V'R>>/;U+_/XS%QP\G=.X6>C-GXV_% )_T;_?&SJOCA',?/ ML&?QRO"S-YJ7!(BAQD%^HB9"#X(& WT'84$/ H]9Y\:X(+_],"[H.;B'?N3% MN)29#\=+:U.)<^1H _537Y)]ET77>\GN"_J?(+#89PK,\8(]_DC-8B >!=\H MS$:0;HR'^Z'MIG2@I87 G0IL;N60P%B>Z(&! Z [&.L(MX>[V^_J9(N""%DZ MP:HY7P9V"%7BYL"'YO*Q0\>G_JD_F\ .WS>O&G:X>!,P' Q.C5?Q%3$O!K=6 M\L"B'<)>O$:T/QUC@$:O,#BT6UC3!V- ^U28%-KGGG4.)J5V 8)NT?@PKAE9 MYX_5A30^C'<.:GS-&E^/Q@?Y *LP/7W7XU<,!X.#/(+UP_0&-3Z,FV#],+T' M-#Z,!V#],+T1P\%S,,Z"]Y[%6@J=&??A M\\/^,AH?QCWG&OVQOZ+&!_E\N=$?JWO2<# XZ.F8T_##X+ .RW6B4)-[SD.Y M^9:6!S"/$-]O?/B>-=SA-*YW?^%*O7O!PW=JO3^F]V,/WP\V^&-Z-?/%,_;\ M[_[!_EU[!Z]*& OL_XMTX'P*/O\;[@EC+W X'.ZM[?];%3,ZDBXU.)">3C&H+*SR1999D:C/%UG%& M0U=FSPA8SBVC$(KY9((5L@R=N<:5M=A0AEE05=K,@N/]! UJ63Z7C*?X+EP> M#*,1^>'D. 65Y?%6+B3E*I8IXY.&UGG%4)$=3 M^3QEBF6:[HT"5:/'8T ,(8II2,@8%LKJWO)B;W=*E86&+5@\MOGH:9H*UV$6 MQAA]E(F_V:?.[C M!"(4^NKQE8___53RB&$A=31)N8M"I.AC?QH51#[):/S$6TV25\]B)I%TM4>4 MIBNY/,\I-!&5^T2@B#98F6RGH31B9II[K SLSQ3+*4+V!\]/^YR:5F MJAJ[_]\;>SP)0;OBZ._"YW]T]41L_+ZF^1V@GMYM_ XB$IC]T-9+6052BC. M6N_1NRJ')^L3$Z=[XC$RS7@Z&<,!(:W;]N_=SFXG@7V[G:S/N\1JIF9JIF9J 1IF9JIF:69_X+[P>B?0"0 0 Z end From hjl@nynexst.com Thu Oct 13 14:43:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Thu, 13 Oct 1994 14:43:00 -0000 Subject: A GNU ld ELF bug (more info) Message-ID: <9410132134.AA02150@titanic.nynexst.com> More info on it. There is NO .dynsym section in libmine.so created by the SVR4/x86 ld. H.J. ---- This test case shows a GNU ld ELF bug. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com --- This directory contains files for SVR4/x86. There are two .s files, main.s and libmine.s. libmine.s is used to build libmine.so. In ./lib, there are three speciall files, crtbegin.o, crtend.o and libgcc.a. The goal is build libmine.so and link it with main.o, then run the resulting binary, TEST. The expected output is: # LD_LIBRARY_PATH=. TEST A ctor called Hello foo Hello ELF C++ A dtor called But if libmine.so is built with the GNU ld in gas-941012, the output is: # LD_LIBRARY_PATH=. TEST Hello foo Hello ELF C++ Two calls in libmine.so are missing. libmine.so.gnu is built with the GNU ld: # gnu-ld -shared -o libmine.so ./lib/crtbegin.o -L. -L./lib libmine.o -lgcc ./lib/crtend.o -lgcc and libmine.so.svr4 is built with the SVR4/x86 ld: # /usr/ccs/bin/ld -V -G -dy -Y P,/usr/ccs/lib:/usr/lib -Qy -o libmine.so ./lib/crtbegin.o -L. -L./lib libmine.o -lgcc ./lib/crtend.o -lgcc For the timeing, this test case has to be run under SVR4/x86. TEST is built with # gcc -L. -B./lib/ -o TEST main.s -lmine From eric@aib.com Thu Oct 13 14:46:00 1994 From: eric@aib.com (Eric Youngdale) Date: Thu, 13 Oct 1994 14:46:00 -0000 Subject: A GNU ld ELF bug (more info) References: <9410132134.AA02150@titanic.nynexst.com> Message-ID: >More info on it. There is NO .dynsym section in libmine.so created >by the SVR4/x86 ld. > >H.J. >---- >This test case shows a GNU ld ELF bug. This in itself is not a GNU ld ELF bug. This is a "feature" of the SVr4 ld, where it generates a unified symbol table with .dynsym and .symtab merged into one. Solaris splits them into separate sections, and in this case I believe that Solaris is doing it in a more sensible way. -Eric From hjl@nynexst.com Thu Oct 13 14:59:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Thu, 13 Oct 1994 14:59:00 -0000 Subject: A GNU ld ELF bug (more info) References: Message-ID: <9410132159.AA02339@titanic.nynexst.com> > > > >More info on it. There is NO .dynsym section in libmine.so created > >by the SVR4/x86 ld. > > > >H.J. > >---- > >This test case shows a GNU ld ELF bug. > > This in itself is not a GNU ld ELF bug. This is a "feature" of the > SVr4 ld, where it generates a unified symbol table with .dynsym and .symtab > merged into one. Solaris splits them into separate sections, and in this case > I believe that Solaris is doing it in a more sensible way. > > -Eric > Oooops. It must be something else which caused the bug. Here are those "strange" .s files for crtbegin.o, crtend.o and libgcc.a. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com --- begin 644 c++.asm.tar.gz M'XL( $*MG2X ^U]ZY/;.))G?[7^"H7'CG/W5JD(\"55[&STN!\3&^&8[KCI MN2\W&UI)9-GRJJ0Z47)K^J\_XIT 9*BGN4"(FRQ0!),)(!$_A*)Q.!N//XX MFXVGL\>G0?'-21(*@B2*^M_T^RA)$_+;#T/Z-TTQBN/R_R1*TA0'Y8T^0B$* MOND'IR%'3]MB,UGW^]]\^KRH?6Y>U-]_ING5X&&^R%^]7LRG93? @]GKWJO! MEWQ=S%?+5Z\#- C0ZQZY,YZM'I_*1[/!?:_L,LNMS!C/[GN]09'/-N2=P2;? M;7J##V/R.Y[>E\4]K?,O\]6V@$]ED\V$/$5^W4^M5^(Y=N5^)Q',/G__JW?_1_Z-/'X4,H3.3WRK\TJA"D MA/%;([1Z/X?WI_#S=V4'QP]WY3!09-\67];1ZQYGB\%6VLZO!I/%_..R'-B] MP[3MOBTZ+_-I^5+CZLOY+)X MNF%_BWO97%T7<_[<\!UYZ-L;=IMF(2SSY&,HD7F3'>TGI-4W>;$AI4UV+/_5 MY[P_^!#*2D7EDS'M)._#>UK2M/^.?*DL9[;HO9HO9X(P<:\@]S)UCU!05G': M+S/92_0;$7WCCY)=91[_^&29+?IO,8$^N\@GB_ZMXF1!F+YZ$N3S2\E? M\IC^%&FE=4X'_0,M*1. 9_I([QJHT2QX EO 1W MAT&DW9XB[69LW"S?Y75E/(AU'L2)7O>$USUI5_?467=<4W?^ MD4U":Y?4UCVIK3LO:4%+6I@EB;KSN[+*XB+5ZY[RNJ?MZCYTUKT/W)7 MAG]_P9HJ=50FZ/%G>1W$Q? >/!0U#?\?([WN$:\['- H=%>>5*/(-^3ZMS2X MJ94%Z\VN5"L>V&09529+"W$CG;@1)VZD33\TG]4=NXK4%"[WAZ'"Y7RJHG Y MGP0*E_[,J\$\RY>;4J'YX8?[_KM2K?E6:#675G9]JJ1!B?\>)_/EJ; ?20WX M#Z5AHO!?1/!?$ ?(X[]S)(__//[KA/^L=)3YC^>HUG_>%Z#\8\:P=[@0!B8?N=F0W;JU5 5\OY@LA+4RTVLEZBM8%>FL"C4+JOT[ MLDKB8Y_6CH^INA](M,X7T0S"]NIZC_&+F%,AR1/MTXHATA[+#+7L2WHW%9E: MGQ-F9\U BT]JH15#5!AHQ2#N8I_E[U[>/ L(L=JIAD$P= A4*,:>LWUVV[;R MK0VNZL.,(F"-$]E#E7UFD^RTE26^DX$U:#:PGL$F.:Q"I"/:)(_YT4_U5 MS9I\ -4AN$:0@+1=N4WBK'4BT?*<"$IW@S@2)G8G&=6#3"5+;@<3D68+$ MM0$2UP> Q/6U@,3U(2!Q[4&B!XD>)'J0^"Q3B?^FTU,Z?WS3A/]"%,0A\/_ M!/\%R*__G25Y_.?Q7R?\)Z7E]^_^].W=MEC?$9?W;9;?%9MLOAI\&A0E%!J@ M\E]0#NB[$-V-E4J M V5V_V&^G!>?\JR_6O;?%O][?+;=E%]^^UU9\&;^F+\KONU/LFR= M%\6?^\'N[>"[Q8Z6DVCE"-G^Y_[;V^\*^D"J/5!6+/\S+9;>'.IOE]4I;[+W M1O 6KPP*]$R:[32!EO-3OIMOQH2HGK*#PFS-& IOM+*(CI(&BZ@LHI30,V(H M*Z> $9D'2.6$L"6[SC*RZVS\UP^_O/_+A_$O/__\]Y]^&__VE_1.:#A4$KI>]A]90O MO__UPV^:E4Q:3!F=0UYKQR0TM)3[E*_7JS4KF)D>1UJ3?1@RTV,D;6CZ1%4I MD/1)5ESEUDS= W5(I(G7QAULNP>,N_J15GOX>3%:PR:A9ULHJ-1#&ZU< M[2[F7.#P@1CQ@4A;G=X&;?!Y07M*ZN@I$JE,=I:5AT06 X8RYD,YD?TCM)0I MWX7C@Y;ZCHN*DLY($3CB[VEWJYTK5 YS:&3KH)( .JY8K23^DEU,)RJC1,T@ M453.X$ 1-8-$&:MLD1K"F$S^4+'*U'/W033JID$ATE+@A?:!QH(#I4 MQ.C>+6 PKN6PI=^\XS,M_' 5S[)UU5 -EL@<+#,*80$4I2\3U:4U,RHH4T=M\VHK?LV1,FBEND9 M:AG5S"NA2\]7\\H!W:-Q7@D3HWN(QX?'!Z2<+UCR)09VA-&IOB>,!:TFJ)#X M((3!:>EJUZ,>%F46?8%B:VI"USE8TV^0I=\8NU)_>&OVHW[%0E+A@)2X<)8KU0H04&^05UF4A M:W2#28%@$NP-=L*2+04M##->@9'JXH4C675\82 M/!)K\%K=ZGC@7(4GBYI$#K5G@1'#3M!27K N;"[(BZ_"#_3$FW6=7:SSLX(7 M6L&0A5&%A;%BG+PRUOV16/C76%/'0N?2_VRU7>HN'OLQ4$0!1"P,('+% 9ST MQ.-U7!,.!8C+@,3!M6&%:XGBE;PR(@,B$1I0XT8=UYR:Y')?MK4>>B)\(.+U M2AT!D9,#^6[3OOKFY#(4O6;(NL6P>7(9UO>< MH>#;D'%CZ. ;JLHL-=^J*R-V(1+!"S6&U# ..Z=%C/_9N5#L-XGJ= M3WQCP;ZQT+ZA\;,BSS!27)17V. G%OS$+?GIC+9&G*?&R^WC ?S$@I^8L08W M#\M)3[Q9QT0LF(@99["#B;@BVS!6K)-7AL0 M,-6XZR$D5QWN(%]F->QI=TX)8T_7C_F]6ZN)[S_Q*J_\=>_S]+ M\OJ_U__]^7\O^OR_;/[EI,<_-,A_%$1QJN1_$).L!,5>_I\C>?GOY?]YY7^7 M:(OC\3+_:,!T'+BV)MF '9]6?D+IB,\KYX#7C8'5)5E#=,,^Z(+!9@Q I_F- MB?.>,K^Q#,W\QK(:S&\L4D@D@E/L$6F..J6C??9MG M;F1S\\P-8!N4Y4';H%Y>Y4!%4J#:6RUW^QO15$1( Q*A18^E$JKX<[;=U.8) M'$9(+Q'503-E\G=@V%EEF,R9O3'+9_P98%BL!"^3>Z_Y&14BNI8EF.NMFV=U M;+\G=2D; .!'UJ$T#$;$,6PAAO8E"\]!/ M?06@$N.'!LHH:1>-R7<.T3V59F4,8@=&H (0Z>;H<0HT"SV7]L)"SV>#+A9Z M]NJ9HA(X3;:0CC:66]U(+R=#EY'^J+$(6NS/KM$BG)O)NA[/(C9]L3U?<,M7 M%R.]M-?*"V,7F-@$-FI77?<6XB\=ZROV9['M6:/]ZENUTLN=6FKS5KO-U'4[ M!J$"CZ?:3:*;NM7[]S6]^+W8&P^V5MOV@K?:,%]+?MB9_+B&_%B0K[:R1Q;R MV^T,:;M=?#_RTQKR4T&^A!,HL9 ?.Y5Y*Y8RMN>*W;D:(77;]M->Q9CF%+*: M,2UM8TRKWST,[6EJO^V+,*@]LS2X&^2V]R!RV*K)I&.]IJ<+ 4"4]T; [CJUI M9K+?=\UMOC\7PUU:)VJ0"S+%2I]=0%&)JO>E>%(N0QOZ:K-0OYI3FF M<0>T@=-M3+2>0*6B?;O 4O[NY3W' "%V\*EZ\7-V$6._G3?8B"+AEWN#KW:O MS>Z)A"\I>V+G+3=.AEW-[AL7'*EAF#-4$ DLT>5L)1$(B)&;[E?=*M:7&"4] ML2W'%I/+Z!XB^@\+_F/&_G%VC_H(0 ?9@JH!;6J-06?P8*0M>#H7QGI#CX9N M X]N?7J^B>#_W7QSTA. ]_/_I/X_81IX_'^.Y/&_Q__>__-%^W\^/!27W?^+ MH/\GBMC^7R__SY*\_/?R_\C[?YD\Z2G;+N M/"!G6CS(,[C8X2=_]#_\_//?__Z?XI@O=HH:N]_=+9=P;R!A767=X NQEWVZN5MNXJ._7V. M9/]_SE;?KCY'9[3;GL',9/&A.**5J<:D"A52[S_AT\D2T?_GN^PAFU_,_R-" M*%#Z/XZH_P=*O/Y_CN3U?Z__'UO_9_($ @"6HR, EM<2 L"#U'ILR\A>QZB) M4]0>%IF$#A(AE)E_E/^3_MQ_6VS>H6_+OY;%IOB]_Y:HUI-E-NV_248W;R>? MQ!G:8GN4.&3RH=@\T1,Z"["5HJSC=EF0:C*?"1;5)]2X1IU/'F:?BDXE@BT4 MDVQ&]V&8>R7*#U:BIH+]0M/=(8H_;UBI^?.F[Z3ZLW>O0/=7A'10_F7G?\[: MOSLL$/1F::WZP^/+9EZQ]XJ]3]>2F/Y?7%;_CT#\?\S\OZ/(Z__G2%[_]_K_ M\?7_HJ+_%Q;]O[B(_E\<5?^/@+9>V+7U8C_]?Z\2+Z__%X;^7QR@_Q?7HO\7 MAO[O/@9Y+V10?,W( -+ND8%'!AX9/(?$]/_-)?5_W?\SQ%3_C[W_SUF2U_^] M_N_]/U^V_Z=<4SC1%-"T_S]-X/HO/?\Q3KS\/TOR\M_+_V[V'^.XETJC0:GZ M ]U/MUB5'PIV@;J,T$- DOXPLC\\# +QL'@]"!_J#5%SCY!=U45@+#\'"E% M_FVLA\_)@KA:$>=LG*@0>ME.EA$9,03E<3O<&YCZZ.KQ%MG?_#[]N]#NF]$# M63S&T(BW6.T)I7S- -FLR>$B_T:%SJP&=%17U9*Y39 -0!ZE@09CE*<(T1": M(>7*AC0D,AN2Y(.O/Y3441OHC;2#&@12:V+EO3K/A5I?8\)7; L/J@*F8,NM.[>%&W8'K/(SS*44B#-$J(N,.#$_ZR.I*?U D3Z=Q M7_S?#?]WP_MY>[P_$P\W(_S"AO +.\(OVB'\H0'P M3^V!;@?:+7U2LGPV[=.K$@"2_(B#FRE#_XVZ?*;I\IG2Y;-F73[2='F;*F_J M[VX_&,Z'"DZMXM+KJA%K_UN,HC0:ADDT% ?T6GQOP#;E0YUO1#\W\4%Q&#XH MK@@?%&Y'?%>\;D,N> C@W6U>KH+?D*3^?T(7\ ;]/PW"$.C_,=/_0Z__GR-Y M_=_K_U_W^E_5%YUG6M!!"X_T[J?B'6G]K]"6/K03OL#:Q]/%5@4A/=>[A'#$ M=<'(+)0>;V>LZ'5<%QSJI9QY75"U@'-=4"%9L"[H:JG]U@4;UEO9NJ!ZB*\+ MPNY'OV(*S_NHL .8.'#'G=;< 7,T^'$#+\5<(OX+=.*OU_.-\.5F, MC[PMQR\5>DN"W[CS$A*P_UQP_3X@I5>:ZR!PJ_T*C[XE=X]<%YEI;0W8AUSPR.U Y";U_Q.& -AO_S_;_YFF7O\_1_+ZO]?__?Y_O_^_ MV%UP_S\&^__#@,E_'__]+,G+?R__+^?_8W/I00]N0]'AWD [FS?0SNX-M&OK M#81-$U(+;R!R$/-P3]/2T!X-@#A=@(W+3=X_S'"$CN0*M+%:LW22LOF7/6TZ M7X5C4,/&]A<7, "VFUX*<=TQBEEDU!H:R")M._S;A&NE'3Q]WAX[P*-*>>Q@ MP\IJ>.P0NP?AG&*CW@;/AQ' >4_LGK_SCMNNBX(NAEWOM.--OWL[[0#\?SG_CQC: M?Q'U_\#>_^,LR>-_C__/M__?BO?SCGA_1EYMQOL6CY&=W6-D=P4>(QN;QX@= M8[\\CQ$[)/4>(VYP4?$8V1WF,;*[(H^1W2&Q 79?LU](-_S@'4->(#I@^O\) M%_^^:7/^,]S_G_KS'\Z8O/[O]?_CG_]6766S+;&U6%\[EX:]SX*"=OX;42#! MPHQ0![7CVG;['0"W7Y&7/P'.-&$?8K^^&N.U:;G>RS[MC=->N?3*I4_/(!'] M?[&:;+)Y]G J!-"@_\=!!/=_4O^_,/+Q?\^2O/[O]?\SQO\-'AHW>@II!/&# MR-,1A,AM9;.76O4>/GHQ]RC9!VK$_P55:G!6A/ 5 2;>D@2!083#G;0 ]UYM M"[B>,>\L+%5[4B30^>=*YQ??>H- @0QI:/YK.^B:)EU^N),/]T*:K,EY M1TB_K1G*@5^087*W^.!PUSI2-/?SH9\B98L6@-?4/ZC6(QQN]!7!'>-7%TG/&==NVH+83LDL\LO/(SJ=GE!3^*RZ&_U _+\P]?\* M8[__]RS)XS^/_ZX1_Q46_%=8\5_1$O]U.+'U(O@O.3;^2TZ$_Q1\L6T,J?@S M>01H08")&P'2Y;\"^)'1D$FW$5R\A #Q;,=2RL%H ,3B((!87 ] +-P ,7?( M7UUN>8#H :('B#X]@Z3PW^92^,\6_RE,O?_?69+'?Q[_^?A/+SO^$Y/_NTO) M?R+WS?A/4>#E_UF2E_]>_E]V_V=0&[1)R*:J-7!GM0;NFJR!UVG^,PU-Q['] MT;*J9K^)8?;+-+L>NP_,?L 0)D.R0..7N)ZT,-39=[+N;Z@[#CT5PYQ@NVR' M9L<,T)YGL;OM*G:WW4%VM]WUV-UV;KN;YG1N-;SMO.'-&]Z\X6W?5.K_BU)< M9O/P8OL_XRA 2O]'N'PL2*/(Z__G2%[_]_K_D?=_H^GK/*_5VCT. M&M;NF6:=P+5FH5D+E6XB-%L]XJG%0QEJZ#M'<$6I4@^U9\WW]_:8?A-B_IJ* M_FBNRX/ F55]]2/;7VIQ)X +^Y.=MG'4=-8&@$!^OR"8Z.UL4<$+T(V9LBK2 M6<7VGKX/[VN^(ZLD/O9I[?B8JON!1.M\,8+#.-]C_"+@ Y*LNPY C_NRWDS; MB&3U]6Y:]9.@&W9CBP>X=8'_6.A"#%&!+<0@[H(L^+N7QQ6 D/WW\2HQYE'% M2<-,TC]Y=9-VU4U=U9TZJYNZZ\H_OF 8*7$@J*#'G^45$!?I61'4\*0(:J@3 M-^3$#0T$-?0(ZFM)#/^MKPC_(8K_8K__]RS)XS^/_XZ/_]85_+>VX+^UQW^G MQW\6)VT'_JO$Q]2AE!.2 2?F5OC/\IT*_G/B-A/_=28:U^%(YWOM\%_R+/'? MVL!_ZP/PW_I:\-_Z$/RW]OC/XS^/_SS^^WI3B?\>5]E)X5\#_D-!G #_[R F M60D*/?X[1_+XS^._\_I_1VY>UJAR)5K)YECC7@"?:%)S^)SY$TI'W*_\*K0O M2=80W; /NK0D0[=PPV\FS@'Z9AD:^&99K;!WW"%N%B+<1>&>KI,H!,=;2H!M M ;&-7I7:(8R! 8#)(8S&ZA^ 9+)$ .^,$F,34I,2(XGM;9M[/W(W0E:C6V2N M$3*(K#"B@2U-J&Z>A568Y/T2O1\_"TX VV&C\7NR)8&BV M>L*>Y)IVPMX^#<$0LN2=8B?C'841[QDJ?B\IE4U1RZ?07.H=[L>GDAB@^>I_6+O-KITN2QX<:,^M:,3)/:)41"AH;D$AKV((( MZTT8!: )!;9YG\)@V9&E"2.GA+"=^ZJ&$PHL/'*8X:@H!$:@Y/AAX+#5'L0G M#6$.XI-*%VL0>[6U,:@%/JXQ!CD- Y"._6U!T7[UI>1H%1[)>HH+*@"T*@C,H7FY9S65AC@ 3[6;1,5UHX3W-;V8 MS.X]01 G%>L:*/NX0;Z$3*@M^6%G\N,:\F-!/I+D1Q;R#9""!$K1S6YUY,>= MR4]KR$\%^1*5H,1"?NS$!/LZQ;>Q-R*+R[Y3R&H&Q[2-P1$9Y"%!'S*]]I%W MVS]%(O:_[6G=_YOW_R9@_V\0,?N?/__U+,G;_[S][\C^'TR>0 /4MN+]S[): M&: : _>U-.$,F$/( /HB:/CK[B^__EKF;Q>\X+N__3)F60J%5I"=Q3T#&DZ@ MO:01[%E]"&J<%H803;^:<\IE)#^6 ?>GSKD5CF^DG0FKG([+85U,-XE6S@MM M(I=O=;9JY=W6E!T=,"I6^^R_MQ<%KK"U'9>"XGW6O!>"S6I MU/_9TMKE]/\P3<#Y3RA@+@%^_?\LR>O_7O\_LO[/Y G0_UF&IO^SK ;]OU;A M;W2\'L#(VDW+2Z#@?5:6C(4E;'Q.7Q:R!MXQM>63.OGRAA#*,F^H+LJRX MK+)<=0MIKRS+?NJ595?4&-RL"ONH,<]:>Z3ZW^_C3Y-EMLC7IU$"F_P_4WC^ M2T3C/Z;>_GN>Y/4_K_]UTO^D>/G^W9^^O=L6Z[OYOH<8H)5!O8 23A&JD?.KF^]7T<]FL MFFZC[D8][6]". DWV2\GALEVL=&_Y]1CRRE'>U)18MS1-%OC7DL5%SA/$M_) M?5TG0T?4RW M^#[]&".BLF=1*//WSMU_^K8 M/B4(B"Q65U/7; $"ABXV-C./?VG#6),V,B_5F6> !U[:@EG*[:4)\"#U9GDQ M=(*'JA1VR6"W!#Y8_AX2]7< /==U"P6,4,M=:PU2J7_M0#I\=A1QTIT3*Q%G M$W#XMIMX0Z#?[2OA0(-WAJIEEQ^V:KAE2%@O0\)>C0P1WKW*#SETC@>[LR8V9 X6,D>SHM9Y MDUI.>''S5[/E(=S*G]105)'05)%YS MZ6>>\N-+@;KQZ*KF\R#?YI%CG.0=P&,9N.JJARF"@L%,9#.]BIM*+N/RZ;I6>_;0J2R]\SJN\3QM- MLTQT.,:_LJ%KN1MS+1?HN/SA&AS6;EDX\,O"7_FRL$\O)#']OP2?%]S_%2+@ M_QFFS"7 ^W^>)7G]W^O_)]+_2Z%B4?[+7*OF7^:W5/L=08?(?!SM"0&B+A! MBQ],3UFQ.TD%YR"&(IW[\>N,*):<8JA@;/*=G0J&2;L%Z# M#^L6MO7!]YPQ3_&'T[45FNX]@/$ Q@.8SJG4_XM/F\GTA.I_D_Z/TQ #^S\] M_S%&WOY_EN3U?Z__=]/_I9LL$1\U;KOTOG38Y7]+EUPD+K"XB,3%4#Z3B*M0 M/I7(QQ"6#^)8/ADC^2@*L'RXE"_RZ2@8R<>':*2>3\)AI+Z8)O*-)(Y#^0H* M49#*EW""423?BG&$AXK^\J-QFB@:1BF*57W1* H#5>MP.$P"4/>TE(J V$< M1Q'@0XJ"\@7%C3#"J'Q#\2091F$< ?!IMS(4ME&&:C0UJ R]/)^ /3ZO%?'DJ M!X"&^1^E(=S_0^(_H3@-_/Q_CN3G?S__GS?^NY\#KFD.*.7_=O;X=-( ($WK M/S$"\A\'[/Q'C__.DKS\]_+_R.L_7)X ",ASM'4?GM=RS<<( 3* FQI;'@=A M"UT'(P3N>&Q[$+OC\Y2%__\\8<?S).<;AHB/^8X<"P@7BNAIB$.- M1W1G4;485KRVH&1_71Y]\ :+=9QA]:C DP81$8TI%G)$,.]O;GO-@R>5DQ]]S'!':-N=V$XA4'T@DSS\FTS%/S,'@J^ADJ3Y97FN76'B]B'_;Q;@Q4\&?V>G>)G;Q:\;WOH MI[$9?4>]!:+:9Q6>&2T$&M'68!.MX,E.QK*?6&+PFW'K(P?.-\<45>S?Q_?V M!IA9&LO5L*T:RU9'XN*IZD@!_3MI++C!SA,.>+BF*7TW6_"]:K&JK70LI37% M6+6,B$W*AX*,5:ID#Q!Y[&TF?&+0H\")/;JIPLE\U1U8H8@5JE[43TP@\<7Z M&J%RS-JZV'*U >/8>@*AI6%KI.!16YY2Q^[3)D;OR(NNPR%(D;#.MF,OSM-W MB$4,$;2/B<@0DY6\;9,M],2J3EUMRKH5Z6Z6C]'A#VI!\D0T7B"?FJQ&KB%JO(-CL;08C!!)]H-<>!L/7=(H9.@2V7=8>XZ67MK(^&9%M(6M77&0+V_Y,> -J\_SL$YW\FS/_'QW\_2_+V?V__ M/X']7S\ E.=4[/[-1X#:C/G<7+F7*=^PY//8E(&X4C8']K="XOQOK/\MC4P\ MDB^IS.,JR^:1#.)[@O!/@HT0M78][9*_>QUHM?:\2UQSA(_J:L\9J"[;5O[K M0)YN>%)?7>]\XYUO/#@Y0\-G%_B; M1;HG)/2EJ1Y5;G@I*K.CZ0])G%WDX8MSL1U11)[D+D,%/T/\U>23<0F*>@V?5LGA#"]4JRFBEJ^TU$11MV-HI[IZ2L]I@&76"5B<[>C M*%)X]!E$0N)D)G ^ IYD1DEMZZQY%66:D]VM[KQU)"ZR:*72IUPQ**?'.54_ M;70\9:-FG R@URMK$6I ,[Q\M;XS%WUG"$I1I)CMO >QH/=--&(Y949G89M8 MB3,[X^ZT4%^> /_KDJ(I\Q&>++0/A%BR5?B?.R*W$E^%JDLLN9%(>WVDU4-Y MZ-V:SHG$](K4IEQ4:72C 8'+.?R*]#M7-)D=2A^!=I=;Y6FIM2-W>SR@-4WO MZH;6)*G7I>ZU'. M 5NU53FN;U7%D!0V;;X%15?0MG8NX;-O[8KFVAFS4*5VD:4'4^E'>==6\+%. MS9[<+II$9YA42P#?(@-''^;OR?F1"3],PL%B,M=3]^'*$(YL M+1"ZMI+4C>M)=2N)I5NPVDH6<,_=PX8O)##4?7O9AI=(\R"V;7AIZB=FGU2= MN6$46'NXV5TM8\KHF=J@=LV5H!RJX^%(4R'4%,J=SOFN $OL"'.K %/_]/T% MJM+4=UIKX(AG#<3.'': (V>)1:0QYE6V'S!$5VH:[WIZX\7UQ@S M..!T\38<_^?@?YTE^_=^O_Q_;_Y?)$VBP9SFZM9[EM3+5#PU+_?2XWL!FT#S[&?=' M]A'>'ZM54.?T(&=BWB82DO%6ZX3'V+M7 ,84(1V0F.RWSQF&;5\6#'-O<;X> M&.:=B3W(N-94ZO]?)NO)^F-Q,?T_Q"G0_T,:_R^(O?_O69+7_[W^?Z+S7XM) MV8_RCT6O>@BLN&4]"5;UN2;N5JHK]3-/.Y4\.>3( M4U'(Y?5M&T5693WY_;5R1+&<+/G#;[_\[_&'__S[;^,QV&L$DD#T#:R-\MM3A'Y&9ZY#G:-W(S$I&; M>74H8R7AU-P+V^#[O_[R6UD*L:ONA/,U\ZZZ13?.!Y6_%9ADR7(LCQ 9F26Q M")_"1VW$_7W8T_K#@7J6>JPB[1LJJ*06,]0HB/#O.^"_"@M=RFBK2-J_*QW) MY(II%6>*4:\Z>F>IA'!LZH0U4*.*H<+".C5G-V)@=/C:^2FV$SO_Y M,KOH^=\1./\[8.=_8V__.4MZ]O-_JZGUD,G?_,"/%YN[&^;*E,\H^\R4*9\H MQ1SPHW-2E &EZ?+DI#I1BGP^:87:G)7<.^:VR#:5B2T,XDDPF;%=,^VF6+$+ MZ103DVS?R6RS+=N/J#KCZ2K[UWBRS,9Y.2Y6'[>; 'NQK^0IT M+4E7^DZD+B&]7] =*^U:D^VU"5NJ3+I:AD;'49E&8B_-]:E,7Z%NXI-//OGD HDT\^^>233S[YY)-//OGDDT\^^>233S[YY)-//NV7_C]Q&0*) ( " )-/ end From hjl@nynexst.com Tue Oct 18 10:03:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Tue, 18 Oct 1994 10:03:00 -0000 Subject: A bug in gnu ld 2.5.0? Message-ID: <9410181701.AA07050@titanic.nynexst.com> Hi, Could someone please explain to me that why ld 2.5.0 for elf_i386 still sets the interpreter even if -static is passed to ld? The function in question is gldelf_i386_before_allocation () in eelf_i386.c. # gdb /usr/gnu/i486-linuxelf/bin/ld (gdb) eelf_i386.c:136 (gdb) r Starting program: /usr/gnu/i486-linuxelf/bin/ld -m elf_i386 -static /usr/gnu/i486-linuxelf/lib/crt1.o /usr/gnu/i486-linuxelf/lib/crti.o /usr/gnu/i486-linuxelf/lib/crtbegin.o -L/usr/gnu/lib/gcc-lib/i486-linuxelf/2.6.0-941014 -L/usr/gnu/i486-linuxelf/lib tmat.o -lgcc -lc /usr/gnu/i486-linuxelf/lib/crtend.o /usr/gnu/i486-linuxelf/lib/crtn.o -lgcc Breakpoint 3, gldelf_i386_before_allocation () at eelf_i386.c:136 136 } (gdb) print *sinterp $6 = {name = 0x20d90 ".interp", index = 7, next = 0x4e788, flags = 131603, vma = 0, user_set_vma = false, lma = 0, _cooked_size = 0, _raw_size = 19, output_offset = 0, output_section = 0x8ef30, alignment_power = 0, relocation = 0x0, orelocation = 0x0, reloc_count = 0, filepos = 0, rel_filepos = 0, line_filepos = 0, userdata = 0x0, contents = 0x31410 "/usr/lib/libc.so.1", lineno = 0x0, lineno_count = 0, moving_line_filepos = 0, target_index = 0, used_by_bfd = 0x4e6a0, constructor_chain = 0x0, owner = 0x5bc90, reloc_done = false, symbol = 0x4e630, symbol_ptr_ptr = 0x4e620, link_order_head = 0x0, link_order_tail = 0x0} (gdb) print config $7 = {specified_data_size = 0, magic_demand_paged = true, make_executable = true, traditional_format = false, dynamic_link = false, build_constructors = true, warn_common = false, warn_once = false, sort_common = false, text_read_only = true, map_filename = 0x0, map_file = 0x0, stats = false} The dynamic_link is false. But sinterp is still set. Why? -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From ian@cygnus.com Tue Oct 18 10:14:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Tue, 18 Oct 1994 10:14:00 -0000 Subject: A bug in gnu ld 2.5.0? References: <9410181701.AA07050@titanic.nynexst.com> Message-ID: <199410181714.NAA00675@sanguine.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Tue, 18 Oct 94 13:01:22 EDT Could someone please explain to me that why ld 2.5.0 for elf_i386 still sets the interpreter even if -static is passed to ld? The interpreter is required if any object involved in the link requires a global offset table or a procedure linkage table. The interpreter is required in order to initialize these tables. -static does not mean ``create a static object.'' It means ``do not search the dynamic libraries by default.'' If you are linking in an object with a GOT or a PLT, then you must have an interpreter, and ld will give you one. If you are certain that all objects you are linking are static, then set a breakpoint on bfd_elf32_link_create_dynamic_sections and find out why it is being called. Ian From hjl@nynexst.com Wed Oct 19 05:36:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 19 Oct 1994 05:36:00 -0000 Subject: ELF and libg++ References: <9410172231.AA25796@getafix> Message-ID: <9410191234.AA08604@titanic.nynexst.com> > > > > > Hi, > > > > I have got the shared ELF libg++ working under i486-linuxelf. The > > only problem is I have to link with libtermcap.a and libcurses.a > > althought I don't use them. That is because CursesW.o requires > > them. For the shared library, they must be linked in. > > > > I am not sure to put CursesW.o in libg++.a is a good idea. Maybe > > there should be a libcurses++.a. > > On SVr4 there is a linker option to ignore unresolved externals. This > solves the problem you describe above. Of course, if you write a prog that > uses functions defined in CursesW.o you have to link it against libcurses. > This technique is routine when linking X apps. > > I don't use the gnu loader so I'm not sure if it has an equivalent option. > May be a good thing to suggest to the bunutils crowd. I am not sure GNU ld support that. Eric, can we tell d-linker to ignore unresolved externals? How can we pass that from ld to d-linker? -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From eric@aib.com Wed Oct 19 07:06:00 1994 From: eric@aib.com (Eric Youngdale) Date: Wed, 19 Oct 1994 07:06:00 -0000 Subject: ELF and libg++ References: <9410191234.AA08604@titanic.nynexst.com> Message-ID: >I am not sure GNU ld support that. Eric, can we tell d-linker to ignore >unresolved externals? How can we pass that from ld to d-linker? When you use the --shared switch, it effectively does this. I am not sure about what you can do when linking a normal executable. There may or may not be an appropriate switch for what you need. -ERic From hjl@nynexst.com Sun Oct 23 02:03:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Sun, 23 Oct 1994 02:03:00 -0000 Subject: some more problems with binutils/gcc/libc (fwd) Message-ID: <9410230902.AA01564@titanic.nynexst.com> Forwarded message: >From riepe@ifwsn4.ifw.uni-hannover.de Sat Oct 22 21:35:21 1994 Date: Sun, 23 Oct 94 02:38:33 +0100 From: riepe@ifwsn4.ifw.uni-hannover.de (Michael Riepe) Message-Id: <9410230138.AA02201@ifwsn4.ifw.uni-hannover.de> To: eric@aib.com, hjl@nynexst.com Subject: some more problems with binutils/gcc/libc Cc: riepe@ifwsn4.ifw.uni-hannover.de Hello! During the past week I encountered the following problems: 1) ld (both gas-9410* and binutils-2.5) has problems with .comm symbols when a.out format is used: $ cat >test.c < #include char **environ; /* this should work... */ int main(void) { return 0; } EOF $ gcc test.c environ.o(*IND*+0x0): multiple definition of `environ' $ Using `extern char **environ;' works. ELF works, too. Binutils-1.9* worked. Libc was 4.6.16, gcc 2.6.0-941014 2) ld -m elf_i386 -static is broken (this is sln.c from util-linux-1.10): $ gcc-elf -static -O2 -m486 -fomit-frame-pointer -s -N sln.c -o sln $ ./sln bash: ./sln: No such file or directory $ ldd ./sln /sbin/sln ./sln: /sbin/sln: statically linked (ELF) $ readelf -S /sbin/sln # this is the correct one, for reference There are 12 section headers, starting at offset 3acc: [0] NULL 00000000 00000 00000 00 / 0 0 0 0 [1] .init PROGBITS 08000080 00080 00059 00 / 6 0 0 10 [2] .text PROGBITS 080000e0 000e0 02a64 00 / 6 0 0 10 [3] .fini PROGBITS 08002b44 02b44 00003 00 / 6 0 0 1 [4] .ctors PROGBITS 08002b48 02b48 00008 00 / 2 0 0 4 [5] .dtors PROGBITS 08002b50 02b50 00008 00 / 2 0 0 4 [6] .data PROGBITS 08002b58 02b58 002d8 00 / 3 0 0 4 [7] .bss NOBITS 08002e30 02e30 000bc 00 / 3 0 0 10 [8] .stab PROGBITS 00000000 02e30 002a0 0c / 0 9 0 4 [9] .stabstr STRTAB 00000000 030d0 0066b 00 / 0 0 0 1 [a] .comment PROGBITS 00000000 0373b 00330 00 / 0 0 0 1 [b] .shstrtab STRTAB 00000000 03a6b 0005e 00 / 0 0 0 1 $ readelf -S ./sln There are 18 section headers, starting at offset 3328: [0] NULL 00000000 00000 00000 00 / 0 0 0 0 [1] .interp PROGBITS 080000d4 000d4 00013 00 / 2 0 0 1 [2] .hash HASH 080000e8 000e8 00014 04 / 2 3 0 4 [3] .dynsym DYNSYM 080000fc 000fc 00020 10 / 2 4 1 4 [4] .dynstr STRTAB 0800011c 0011c 00008 00 / 2 0 0 1 [5] .rel.plt REL 08000124 00124 00008 08 / 2 3 7 4 [6] .init PROGBITS 08000130 00130 00051 00 / 6 0 0 10 [7] .plt PROGBITS 08000184 00184 00020 04 / 6 0 0 4 [8] .text PROGBITS 080001b0 001b0 02a70 00 / 6 0 0 10 [9] .fini PROGBITS 08002c20 02c20 00003 00 / 6 0 0 1 [a] .ctors PROGBITS 08002c24 02c24 00008 00 / 3 0 0 4 [b] .dtors PROGBITS 08002c2c 02c2c 0000c 00 / 3 0 0 4 [c] .data PROGBITS 08002c38 02c38 002d8 00 / 3 0 0 4 [d] .got PROGBITS 08002f10 02f10 00010 04 / 3 0 0 4 [e] .dynamic DYNAMIC 08002f20 02f20 00070 08 / 3 4 0 4 [f] .bss NOBITS 08002f90 02f90 000b8 00 / 3 0 0 10 [10] .comment PROGBITS 00000000 02f90 0030e 00 / 0 0 0 1 [11] .shstrtab STRTAB 00000000 0329e 00089 00 / 0 0 0 1 $ 3) I couldn't get tcl7.3/tk3.6pl1 to work yet. More exactly, if I link wish with libtk.so, the program will dump core whenever I close a window or hit the OK or quit buttons. If linked with libtk.a, wish works fine. It doesn't matter how libtcl is linked. I guess this is yet another function pointer problem (probably a very weird one) - tk passes functions to tcl, and tcl is expected to call them back, but that never happens in some cases. While dealing with this, I also found out that I can't debug a shared library with gdb 4.13 - it just tells me a lot of nonsense :( I have another problem here I can't solve - one of the tk demos reliably kills my X server with a floating point exception (SIGFPE), but *only if I use the ELF server* - the a.out server works fine. It doesn't matter whether I use a.out or ELF versions of tk, it always kills the ELF server but never the a.out one. Linking the server with -mieee-fp helped, but I'm still curious what happened. Strange, huh? 4) Finally, an easy one ;) libc 4.6.16 needs the following patch: --- chainsaw --- diff -ru libc-linux.orig/rpc/clnt_simple.c libc-linux/rpc/clnt_simple.c --- libc-linux.orig/rpc/clnt_simple.c Fri Nov 20 07:11:24 1992 +++ libc-linux/rpc/clnt_simple.c Wed Oct 19 20:24:19 1994 @@ -57,12 +57,13 @@ } *callrpc_private; int callrpc(host, prognum, versnum, procnum, inproc, in, outproc, out) - char *host; + __const char *host; u_long prognum; u_long versnum; u_long procnum; xdrproc_t inproc, outproc; - char *in, *out; + __const char *in; + char *out; { register struct callrpc_private *crp = callrpc_private; struct sockaddr_in server_addr; diff -ru libc-linux.orig/rpc/getrpcport.c libc-linux/rpc/getrpcport.c --- libc-linux.orig/rpc/getrpcport.c Fri Nov 20 07:11:25 1992 +++ libc-linux/rpc/getrpcport.c Wed Oct 19 20:24:19 1994 @@ -46,7 +46,7 @@ u_long prognum; u_long versnum; u_int proto; - char *host; + __const char *host; { struct sockaddr_in addr; struct hostent *hp; --- chainsaw --- Michael. -- Michael Riepe Universit"at Hannover Institut f"ur Fertigungstechnik und Spanende Werkzeugmaschinen Schlosswender Str. 5 30159 Hannover (Germany) ... beware the storm that gathers here ("The Prophet's Song") -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From hjl@nynexst.com Wed Oct 26 22:28:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 26 Oct 1994 22:28:00 -0000 Subject: A serious ELF linker bug Message-ID: <9410270527.AA10707@titanic.nynexst.com> Hi, The x86 ELF linker in gas-941026 seems broken as far as building shared libraries are concerned. The last known working one is gas-941015. For whatever reason, the shared ELF Linux C library built by ld in gas-941026 is bad. Many symbols in the shared library with the value 'T' now are '?'. All the ELF binaries just hang. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From hjl@nynexst.com Wed Oct 26 23:42:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 26 Oct 1994 23:42:00 -0000 Subject: Update on the GNU linker bug Message-ID: <9410270639.AA10875@titanic.nynexst.com> Mn-Key: GCC Hi, I have verified that diffs-941022.gz, aka binutils 2.5.1, broke the ELF GNU linker under i486-linuxelf. It is still broken as of Oct. 26. For those Linux users who compile binutils yourself, please use binutils 2.5 plus the following patch only if you want to use ELF. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com ----- *** ld/scripttempl/elf.sc.orig Tue Sep 27 11:42:33 1994 --- ld/scripttempl/elf.sc Sat Oct 15 08:53:00 1994 *************** *** 55,60 **** --- 55,64 ---- .rela.rodata ${RELOCATING-0} : { *(.rela.rodata) } .rel.got ${RELOCATING-0} : { *(.rel.got) } .rela.got ${RELOCATING-0} : { *(.rela.got) } + .rel.ctors ${RELOCATING-0} : { *(.rel.ctors) } + .rela.ctors ${RELOCATING-0} : { *(.rela.ctors) } + .rel.dtors ${RELOCATING-0} : { *(.rel.dtors) } + .rela.dtors ${RELOCATING-0} : { *(.rela.dtors) } .rel.bss ${RELOCATING-0} : { *(.rel.bss) } .rela.bss ${RELOCATING-0} : { *(.rela.bss) } .rel.plt ${RELOCATING-0} : { *(.rel.plt) } From ian@cygnus.com Thu Oct 27 13:05:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Thu, 27 Oct 1994 13:05:00 -0000 Subject: A serious ELF linker bug References: <9410270527.AA10707@titanic.nynexst.com> Message-ID: <199410272005.QAA04964@sanguine.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Thu, 27 Oct 94 1:28:13 EDT The x86 ELF linker in gas-941026 seems broken as far as building shared libraries are concerned. The last known working one is gas-941015. For whatever reason, the shared ELF Linux C library built by ld in gas-941026 is bad. Many symbols in the shared library with the value 'T' now are '?'. All the ELF binaries just hang. I can not recreate this problem using either the current sources or binutils 2.5.1. Could you please provide a test case? Ian From hjl@nynexst.com Fri Oct 28 21:59:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Fri, 28 Oct 1994 21:59:00 -0000 Subject: gld in gas-941027 is still broken Message-ID: <9410290457.AA20840@titanic.nynexst.com> Hi, One more bug in gld of gas-941027 under i486-linuxelf. Again the last known working one is gas-941020. This one is kind of subtle. The test case is very complicated. You need a shared C++ ELF library for iostream in libg++ 2.6.1. Jason and I are working on the patches for gcc 2.6.x/2.7.0 so that it can generate the shared C++ library for ELF. After building the shared C++ iostream library, I ran "make check". A c++ test case was compiled with -fPIC and linked against the shared iostream. The test case just hung. But gas-941020 has no such a problem. I don't know how to create a test case without the shared C++ ELF library. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From hjl@nynexst.com Fri Oct 28 22:11:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Fri, 28 Oct 1994 22:11:00 -0000 Subject: An annoying bug in gas-941027 Message-ID: <9410290509.AA20861@titanic.nynexst.com> Hi, Since when does the linker abort on the empty library? # rm libfoo.a # ar cvru libfoo.a # gcc bar.o libfoo.a libfoo.a: could not read symbols: No symbols libg++ 2.6.1 creates at least one such file. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From rms@gnu.ai.mit.edu Sat Oct 29 01:18:00 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) Date: Sat, 29 Oct 1994 01:18:00 -0000 Subject: An annoying bug in gas-941027 References: <9410290509.AA20861@titanic.nynexst.com> Message-ID: <199410290816.EAA23541@pogo.gnu.ai.mit.edu> The linker should accept an empty library as a no-op. From ian@cygnus.com Sat Oct 29 09:23:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Sat, 29 Oct 1994 09:23:00 -0000 Subject: An annoying bug in gas-941027 References: <9410290509.AA20861@titanic.nynexst.com> Message-ID: <9410291623.AA00647@tweedledumb.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Sat, 29 Oct 94 1:10:26 EDT Since when does the linker abort on the empty library? # rm libfoo.a # ar cvru libfoo.a # gcc bar.o libfoo.a libfoo.a: could not read symbols: No symbols Well, I must admit that this bug has existed for about ten months. Here is the patch. Ken, this should go into the next release, if there is one. Ian Index: linker.c =================================================================== RCS file: /rel/cvsfiles/devo/bfd/linker.c,v retrieving revision 1.40 diff -p -r1.40 linker.c *** linker.c 1994/10/25 15:47:59 1.40 --- linker.c 1994/10/29 16:17:43 *************** _bfd_generic_link_add_archive_symbols (a *** 867,872 **** --- 867,875 ---- if (! bfd_has_map (abfd)) { + /* An empty archive is a special case. */ + if (bfd_openr_next_archived_file (abfd, (bfd *) NULL) == NULL) + return true; bfd_set_error (bfd_error_no_symbols); return false; } Index: ecoff.c =================================================================== RCS file: /rel/cvsfiles/devo/bfd/ecoff.c,v retrieving revision 1.74 diff -p -r1.74 ecoff.c *** ecoff.c 1994/10/24 19:37:18 1.74 --- ecoff.c 1994/10/29 16:17:53 *************** ecoff_link_add_archive_symbols (abfd, in *** 3860,3865 **** --- 3860,3868 ---- if (! bfd_has_map (abfd)) { + /* An empty archive is a special case. */ + if (bfd_openr_next_archived_file (abfd, (bfd *) NULL) == NULL) + return true; bfd_set_error (bfd_error_no_symbols); return false; } Index: elfcode.h =================================================================== RCS file: /rel/cvsfiles/devo/bfd/elfcode.h,v retrieving revision 1.143 diff -p -r1.143 elfcode.h *** elfcode.h 1994/10/27 21:25:25 1.143 --- elfcode.h 1994/10/29 16:17:58 *************** elf_link_add_archive_symbols (abfd, info *** 3738,3743 **** --- 3738,3746 ---- if (! bfd_has_map (abfd)) { + /* An empty archive is a special case. */ + if (bfd_openr_next_archived_file (abfd, (bfd *) NULL) == NULL) + return true; bfd_set_error (bfd_error_no_symbols); return false; } From ian@cygnus.com Sat Oct 29 09:27:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Sat, 29 Oct 1994 09:27:00 -0000 Subject: gld in gas-941027 is still broken References: <9410290457.AA20840@titanic.nynexst.com> Message-ID: <9410291627.AA00896@tweedledumb.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Sat, 29 Oct 94 0:58:39 EDT One more bug in gld of gas-941027 under i486-linuxelf. Again the last known working one is gas-941020. This one is kind of subtle. The test case is very complicated. You need a shared C++ ELF library for iostream in libg++ 2.6.1. Jason and I are working on the patches for gcc 2.6.x/2.7.0 so that it can generate the shared C++ library for ELF. After building the shared C++ iostream library, I ran "make check". A c++ test case was compiled with -fPIC and linked against the shared iostream. The test case just hung. But gas-941020 has no such a problem. I don't know how to create a test case without the shared C++ ELF library. Could somebody please try to give me a reproducible test case for this problem? H.J., can you confirm that this patch was in the sources you were using? * elf32-i386.c (elf_i386_adjust_dynamic_symbol): Don't define the symbol to be in the .plt section when generating a shared library if it is a defined symbol. Ian From hjl@nynexst.com Sat Oct 29 13:11:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Sat, 29 Oct 1994 13:11:00 -0000 Subject: gld in gas-941027 is still broken References: <9410291627.AA00896@tweedledumb.cygnus.com> Message-ID: <9410292009.AA21496@titanic.nynexst.com> > Could somebody please try to give me a reproducible test case for this > problem? > Do you have a Linux system? > H.J., can you confirm that this patch was in the sources you were > using? > * elf32-i386.c (elf_i386_adjust_dynamic_symbol): Don't define the > symbol to be in the .plt section when generating a shared library > if it is a defined symbol. Yes. I think I have pinpointed where it went wrong. As I suspected, it looks the old bug I reported earlier. Your fix may be a partial one. root:3[4]> grep t1__Fv /tmp/*.sym /tmp/941020.sym:Tag: 8006a28 Value 05407 R_386_JMP_SLOT (8001ed0 t1__Fv) /tmp/941020.sym:084: 8001ed0 988 FUNC GLOBAL 00 010 t1__Fv /tmp/941020.sym:126: 8001ed0 988 FUNC GLOBAL 00 010 t1__Fv ^^^^^^ /tmp/941027.sym:Tag: 80069e0 Value 05407 R_386_JMP_SLOT (8001a98 t1__Fv) /tmp/941027.sym:084: 8001a98 988 FUNC GLOBAL 00 009 t1__Fv ^^^^ /tmp/941027.sym:126: 8001a98 988 FUNC GLOBAL 00 009 t1__Fv 941027 hangs at t1__Fv, t1(void). As you can see, it has some bogus value. It looks like i486-linuxelf is the test bed for ELF unde x86. I think binutils should pass i486-linuxelf before it is released to public. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com ---- begin 644 941027.tar.gz M'XL( "2ILBX ]1:?724U9F_ 0:'B"8@E0 )C#A@5(0$\H4&3""$($&&\!5$ M'<+,A'?"D$DGDQ#;:&,'U\0QGMBB9;?MV;1J-^ZZW?3(.8U5(4?\8%O;DW6I MF_;8-?9#WR%9# 0,5M;L[WGN?6?>F0'\JW_LZ,/S_NZ]S[W/YWWO?6%E7F[. M\ASQ-_WEYN04YN?;A,V66U!80-RV8D4>N]QFRR_(S\M?GI=;N *- MA7GY><+V-U9+_IH:@S4!FTUH=;ZKCO,V7KW__^GO6^LJRU-24J)XDI@L"+5E M"6L>N/ZJ;$B2/VX_\-J M2=<02)?]0\!#FNSOF23$ (2GJOY)I-=]H+KX]:>J-9;YO'N7>7RURWSN.WS> M^J:6I8W^I;E"U)"]:N$%H&U*KS6@&U5["R@-] @H()<3WP2YU/QW@W:!RD S M04'074JV6/$[0)0LMX*^ 8GIM A:!FA:L4 MWP/:KIYMBA>!ZM4SY?)#IGFV7F8=RMG:K]!E7@*^"92AGM>#IE]&YK:OF)-^ MJR[3Y@6M-.%%EQFS%O0UT'Z%#X!*3/T+0ZKZ$ ^.CE;6/>ER)JB M/!\$?EI(3'FH P\H3#E\$;A(C2==V@\(*]76#+10[M@V"FL.CT_E6&5D".L, M)4^UE@V)O";]%Z)OP^S0&\4N$/03W ;RD\#.H#KE7X2_(7\"*%KX$?!C-B_IH- MK .W*9P-?-&$5P);YPAKAO+?/> 9P-D*WP]^)%-8=ZGQ!X"+X-]TY8]FX&R, M=ZC^9Z@?N$_A?TGAA(B.?QVXQ80'@"LP?HD:_Q=@S=0_3O.;<"H*MW=_#&!EP->9[6DCEW^O &6;[@2]B_)UJ_!^!K7-C\WU&XX'O M4?A:;(#9P/7OUX&K@: M->!RA;]/\L#Y1CR!VX$;%#Y.\J;U!@F;XC$"W(#ZNTO9_U?@'L@7*GDK-KQ^ MQ/.(&C\/N _]3ZG^-,GO ]:!NXWZ!;XX5YY7.%[ UGG"ND?9 M\Q1P!O _JOX>X&S@C49] A<(Z M7^&'@6T%PMIRC<2'@+M7(U_5?&'"JX1U7.GS'>"A4F&]I.3_@7"9L(ZI_A_3 M_!7"FI8B\6N6V-EMAC@[\19PVVR)9X+]BM;WQOH_ LZ9;_2GBC%@S2?KF_)G M K@O,U:_4V'GRZ:1[WC7 0?OC>F_GP^N\DQ%,3](^OFX#%C_T%1Y MUI4X370"#V*^#6J^OS?UWX3^'P'K)GM?3)C_*' ZZG.2FO^-J?+]9NCS&V"\ M_*Q%:O[?)O1_0/8?,/D?.#LK5F\? Q.N#M>)@P!NLV>OS.)TKO/Y& MW,V<_@9/O4(N3R @7-YZ 5&W:933&: YO7+.*EK$W^P)U/K\!Q/[D@9[$QM\ MPNUQ.9WE7J^H]0<.X EF>=2SR5*/T#PMZ/4EVNA+G+$VL<&=T.!PB7V>H!E[ M7<)3[_9A^BIC6N%L#BZ53JGW!J7ECI6R;V]3K2,VSIF;6ZO::QH]7N@*6TC: M&"*GH98B?ZVYR>7S-WH2Y*6D-TG26YO/:+IGI<]/;#J/RMY5Z?LL8K&IJ"1I.C&;W-+@/ZY#*F/@I.S(]5!0&/RQ]P M2Y4=/G^0!DH%#R!MG,YH(];QU>SU^$Q-E.(N;\#EBQ^'@=[ZA";*B]P56-0< M"R,4N3G^:(]<&_&.TU. 88+EL0F:*)%R<[S1%G8&F2L7CTN?H,?GVQ=KX\+R MQ"6P4B1>PUCH5B;HYW3N;?+Z@MYZ9[V'RBJ6>FJB>$TY2=T/U4-+5Z(9CO+M M7J>CV5'N:'8V>P7%V:2J3]3ZFAJUF*Y8K$G5@S).I= M!QJ(!_T^DU.;(4R.#>9B;+,(+I=LA61YDN5+5B!9H60K)2N2+#='<35/KIS( MY]T;KTDT;U@HGA4HXUU=N7E-:Z=Q<7KYUW3;GMM(UE>N< MT,_M=^[S^??6^)RNH#\ EVS8[&P,NK$3.T4M!TK4[/4'@B93W!Z?)X@=,^#Q MB ,U/I_?E6"G&H"PNKW-;N\*>CK@=],3]'21@GEHXY053@QM"1KKXFU!6CGW M!O8[:]SN +TZZIN] 7\]%3J$I35&6ZV*EY+&^AA6V]#D=/GK@P$9@,9&)WTI M#(H:+$2>\+AK@C5@]6XA&YR-GB"$7,A V8#9?$@B)XR+?9/"Z_ './M,G2;$ M:\1Q:7R7. Z[@\1+<'\@/A?G4.*XH/<3M^/,13Q5B)>(XS#R ?%[A7B3.";N M(XX#00_Q>3AC$,02S-\NYC62;O M=):%\BYIF2?O+)9\>9>P%,L[H.4F>5>T+)!W>@OT68*S(-UQ)X[!_A/@MR ?BV8@O<1PJGR=^&^)(_';$FS@NE[W$[T < MB2^%_XGG((^(YR).Q)YCW@% MSIC$<8B=3AR7V73BN'3-(EZ)O""^28A,XEMPYB=>)82=^%;D"_%MB#_Q[8@_ M\1V(/_&=B#_Q:L2?^"[$GS@NR67$=R/^Q.]'_(D_@/@3?Q#Q)^Y$_(FC[NXG M?@#Q)XZZ1/R)H_Y:B;<@_L113X>(?Q/Q)]Z* M^!/'9;*+..KL,'%-GI&W=G5UO=J+RT)H%?TY$4SMZ@J=N!2Z:Z+I8NC$E-!= M(C@]/!E/$P-X;CJ_^\0;+#>1;X?7)Q9EJWO2Q"*J$IXT,C2!WR*J%HWZ(@., MJ6HT.J)'^AE3]6CT"3'2RYBJ2+,1[F9,U:31)[%(%V.J*HT^B47:&%-U:72% MB#0PIBK32@CO84S5IM&GN(B#,56=1E>42 ECJCZ-/EU'MA^QE356N];#]CJFZMC^UG3%6N];/]C*G:M9-L/V.J M>FV [6=,U:\-LOV,:1?0AMA^QK0;:#K;SYAV!6V4[6=,NX-VD>W_7\(OY/@3SF'\ <>?L(WQ$,>?<#KC/W/\"0O& M.L>?\.@EPB,MA^QK2K M:;UL/V/:W;0^MI\Q[7):/]O/F'8[[23;SYAV/6V [6=,NY\VR/8SIEU0&V+[ M&=-NJ.EL/V/:%;51MI\Q[8[:1;;_"\*T2VKT=QR1(<:T6VKT#2 RP)AV32V= M<#]CVCVU#,*]C&D7U6R$NQG3;JIE$^YB3+NJED.XC3'MKEH1X0;&M,MJ)83W M,*;=5JL@[&!,NZ[F(%S"F'9?C3[-1G(8TRZL[2%L8TR[L:813F=,N[+60%@P MIMU9:R$\^E>N?\)M;#]CVJVU=K:?,>W:6A?;SYAV;^T(V\^8=G&MF^UGW,;Q M9_L9'^+XL_V,VSG^;#_C)SG^;#_C+HX_V\_X,,>?[0<6ZK>KXT\=0QV_3'D/ M_PV$^JGZ-S5KC,;GV./@:E_=Q"YRN''L#DH3>G MZ*G@6AO>(7J.:NG^?&)"OQT'"(>^"DV[*5DQS_"XB/U.O-K'+Y\^?OE,^XIW M3U?7"1'_V[&5MBBQ^]$3O\,;/EQIGQ[>9D_O#'7_96+"$5XS/1RP.G9TAGY, M,.W8)$=GJ$?V3,'C3^EQBU[R.>D+4]8;#TN-AW7&0Z;QL)8?ICOT5-FR^T%H M%?N%1J;LC.FTCG0*T281%FTM,T5P06?H*"U:MZHSU$\/G:%_)Z9?NDBSI1N# M'?H7W##EL?XFR'S",JL39$XFROR766:<9>Y.D#DL93I#4S\F-["H0U^-UG"H M-4[/+!I05YH@O\U8LU6MN=6\YJTLLR9!QI8HL\PLLY)EUB;(C(PK/2NDGJVL MY[/CI&=;G)Y.EB]/D']I7*W9IM;\U;AIS3J669\@TY(H\[A9YB&6J4B0*3/T M?-SLSS.?34QTEMEO<HS^0C]<.FME:<;!>76N+?I& MGL@Z/+,JMCO.-B^Z2)TEE&H"%MBTE?5V?;HE^GI*=?8?PJ\_A56_0_ M?';U\8GS_^M7C%]H'K]PB_[PU<>G'0O:T]3X+.I?1!L22G&=DIMU.?OK%AK^ M_>F%B8FZ5 -U7[A25FQ*B-:S%^(J)KXD[TT8[)6#\?_N!YU(@Q.ROEM-]>W! MK:,S](PY]&/G.?2W14/_[0O MC<2.\PD-V\^;0Y,0 JM4^G=E]HS0B/4/F7:'OFA,O1U&SF$\G)")UU&&HRK! MS[\YI\R]<$Z-?^WS6$DQY[]Q5[/8F#'[AG+*[S&SW9K1V!NW%.PPS'QF3 M9KY*9NY,M--F:#O;>+C^'-5?G3LZP:8Q*5=O7D8_:\3;>'C_[)6L;$C<_\_& M[<50[IT2*WW;@=[VZ+)OQ[R&.K6&[A1IA_O[AR:UKYD)95K,RNPV=*@B';Y[ MB+=BJV/B/53VY7UY,$&E75(EW@Q:3T3?]]6F_6#[&MH/NLSK_FD4OFZUEW6^ MW/L):]!9:2_KJ+27*%[%@[11:&CS(Y#9YVH8O\B+;2C*?2O 5!C._5K MN6D6TJDD''J21J^AW"H.A[H4*+,7LP$+.T.OD@8:_?U_@@W/C$JW8BR@"JEN*R:Z1:>)GDB>J.]3.5&K/=/P]G1X.1-> MGJ5X.KR=&?5VD?1V]ZC)VRGL[1^.&M[&6^NP=/ [J'.*,QTPPZ$C4:^G&UXO M9,6ZDA5;\*GAE/28U]?PZ*>31Y\]$QWMT,^?,;G0P2+?218Y9A;YZ(PI4'M8 MY+O)(N$SRNM^W92M^6=DCI;9TQSX(\.A/R=;NAD%>H_Y:#-B@7MVZS']Y+UF!Q5?5;8D5DW*>WX&NMD6AF' M]XD!CKRIN5(V(S1$,0%GR<$S1I;8S%EB5UF2;2Y4 MC/A!%" %NZ/YDVGDS[^QC_XIV4%2^\0 O5$@D$T"V#T^'^$D M*HYWS]%D5?J'U4'-UADZQD>E,C[LS(B8]_]A8_\W'C;@H3.TV#RH8)C?_[?3 M#'D._>?0@!)]173 HN&$<_SQU-C)]X:ZU"UZ2$X_/#-V?OVR8Y3/KVVM]GFI M9,D*6E/[1;(EGYV63D6B=[S3^7(QQEUZY1IVYO,8M,NLZQ.GE1V/GN:WN7V' M/LX648Y'DQ6W7UW$HAOORQ/)&@1/7S'5WDP>77[:E#<;3B>EVEO)(C>810I. MFW:WA]@K;R>+#$6B7G'(7'HJ(H^T\>;\.EGTA8B1I7#/X.DD]Z3 /1^93.;$ ME&E9P6E929O-]&37O9>\ULK(%5WWG\FCKXV8_'!]Q.2'=O;#J6210=TD\H6> M5*6_O8S]NMKEOV=.GJB>''<55^G]+_^;$VSR8 M//\Z.7\N;8-=H8EIW[K;?,GS%5>JTLCH.-,Q:ESR]NBR1-)4?9Q1];%^^/4N M.-_R?^Q=?70459:OA'PT;2_)0- 02M,1Q()@?"QDBA,0()1"38?G8PB'TVZ MFTXFZ>[M#P+*5Z;#CC5M8^:(KNN9<>2,,V>.PT'.Z'%V_, LLN"L(Q,@0(3( MAP8L3,Q&9 193/;>^^IUO>Z.SMF96?:?],GM^E75N_?==]]]]WU4UPO6;*). M#U_$VCLJEN-'U,=G'8"^0X+2C+/0V%V5+@[695G#;Y!FZ:29>9RFV:VB9@?8 M$*U[=,S\F^M7W+IM 2F_[ALY*_3@JF8;1*TZ2PI8]N& 0H<4"]^E3L9Q ^5 MN:G>#5ZENNU*-.3U"[QNS6)_E\_[.QQVKFC:CYU=W'K3?*'O.W8G"D[[5+!1 M#0C6^JTZ\(.Q>*\N*8*BU8E,OT)>S1/PINOS1.U61K4KU%V[D%)?2DP]54]M M4:=?$/RTA%B^2&3Y^KS (HLL]Q++Y426_V0LQ5]")&YI43[?^N^VQV%8#9W1 M_$CX1>#Z,*GJY-UF$/3A(^8**'"9A0U.YK)*7A#J'[[Y75+ M312ZI8L'6)B)_O8\.C#YB?KE^?AQW-,DPY0HXZZN;QO'\7G3_!CG)?_-%_QW M]$R4NTNT\B\^IK%;5N25_9_R^5,6C>39T12A,;HV7IO*QFN'NA+F3^]U\;%: MIC@L,^GS)SIY,3HLBYKM?2IR5F*1*S[F13;IK>($I1Z=F'JLGMJBCO]863CP06(V=!G2X1RRV)+*\R%AA*&:'3RZI2G^K"ZDR"D0%T=<_ "3T3 M=!4F:5]5ZD_(,F;79;R$7W5VF-FK/^ZBNI=CS9"3F.7 M+=3BA^_YQ3?-Y+'1,WPL&=E!9YKK-)O1&,Q[6JA IKKDNKMQ M>6NC6:Y6G_B8N<\.DJ1[T Z2%0[]6CMOIG-NLW+4TC4MT6;_<([5+$O.SS5_ M6$IQ5/)_? MG4%?#8E9OPB7IK8J5Z[_'H<#EW8K[UYIJ[!400_6;,:'SQ9U)*@"HC%L\^+] MDC29EZC),V>X)M>)][4S@ME_2USW)'*M/J//+V+LDGZ&+8.!+OC,S +EP8ZJ M2MU^#K6.O($5)&H><0U4J4VLKDM45/4=RO2^Q$R[3VN99I?L,N. 5.?IM0/ M)*9^BZ6.E-/D9Z,^7SG'YRM\R%HW:7M;NLDD+?( W/QS: M$XW*%>+<>J$VM[:(0;Q"G%L#[ZOLI.X1=>99G)!">>N@5F9ANPCA4TAEP4)0 MFGZM@5E7J9//\D@[7[FT[4C0<*!L9$IW6DL+'*4#9:,D)?-@&?Z>7#I81K]W M<1XLRY3AQ/0=NI:51@=:'\*5!BBBK!VSM6,6%-D<+7(9*W+>:5[D++'(V6*1 M<[0BRV*1L\4B9XE%GG=&*'+YF6\L4/7>YFD_!E M%K7K%#01B>$.YJ0MN*A#377DUHJ1R<6MW?/T_*8>P;NA]2E2( ,<;[UATOH4 MY>JVUHP=^YJ/!#)I/:@LQ:+^E&2ET"-E:+Z&?\-&UGT7R899W+R4DGF&QI%+ MU&:6KCN3^^>\E(S7I(%Y*43;7@])S&4\0"=3=G=B@D?^;YP-P^1'Q\FK><^2!N$(:CU/LH=4-BZJ>%U(+],KD)##3P M*-1'J4T]?3&_,O#?@3*K>X1>( ED0N3?0Y'?W,FG6\F1T)\':-0E=V(;8'W6 M+HJWMW:2)^P1^JPMI/*F1)4_ZN!]UA[BO=0A]%EAXMJ4L:ML'A+(MZJ^."T7[@O1\ M=I#QSW%>M&RQT>1$JQ 7YM2'J6GE+%_9M+]/7Z5HZMD1MSY?/!$R""=_!KT4 M/I?!Z?I"LP5PA7;$L8$E&D?J61RY?IR-R:&)Y7[ 1J/?,#*8'XT?$5S-7PB= M[T+HC-DQ9[!.^ 5=]G]T<-DQO6U.=):HV_..8P,#N/B P3T)VJ^KBZ5=QL X W)_#[E?PR]\3Y&5J_1H4 M9K'ZJV/D'PLN%O!>L/A+*FZ]>7X+*^*%XV1+7A^[@+2#48Q*=?X89G)]UEUF+7=+6 MB>""+DD:PPXWPR$2JO]," 4[0/](N(FUEAE36V$V.D.<43R^;^N^:Q!!L'%6 M6$ZEX'H7^S$"U4G&WDM5$7>2-1)Z5I<:IBG<-3 ?I)FZN,("AQF+JR#1;C'K M,6@Z&+KG8G X@'?HYZ)QP>&>(UH0FX4EA]J/7>'1BU[R7<@Y@-V[]K"]PK25 MU\:;232*&PECP915"@ZM?A_4)3RMS'A \' 2G M?[N\3I27\;L#T>*7:V_37EOY90_C9>_C\18#^<%-I&=J[^8\FP MU]148<(W>/D59]B2B9..55+&V]?X1;#=P-=1[6#8;S)_;C(H\TRN]!])DKH% M[KF^6C\PH :%5!C?*6$*)*R3U(>^%NLC!?--UO/%+/X;Q)# HA@Q*4Q,,N9' MN61$;RO7P@9(\'B;\UFG,C<3CQK7M)7 P--%_IAZC2\#V1 ^WE'M(=! MI@:3-;456F%FTN:Q.*3,[,46N@!F0/>3?YIP:M3:W!IHB)IN%MP.M2;7&>O MZC-XJN#H\+W:HRU+1=*U)>&RA?A;PW#C0@N,1X^PV4O&VPLJDJZ"?/;8J^1J MX.9(:%2O$*BS#E'EJ=?!.]1T8%-'XM=X_,K'K^GX-0>_[L.O9?BU"K_J\"MX M!*=%I;U"F-GW/EQB/SSBO_;)>*ULI"7RRN)>^LW5TEX*-\M%ILC[FC,U<_ 8 M!S_DH/9]%/D462691((P)Q/FP<,2=0%/.YN#&1S92)"8DZ M??5'C:./@T\XZ.7@& $Y$MHNWH@M(,1^K(4A7&D*6S/#Y5F6 M)8N7NO %./4EJ &&O%@7CQVFO@O2A\NA?0;28'P)QE9Z5KPSB+QMIX(Y;^#< M67C419^=.?A:3]M2]:;#?&C8$UYQ/2J&R8=^:8#)YNHYPX6$XMHGL*]:>;.J5@QNNHNM)6?(32="H=&E*5H\I5SA?:E"UE M--=A:]S4=[#\,HT/K=GARC[%&*Z\K-R?M:!IR2%RR\K?:HHST,Q3]\ M5!U>WD[GG^\@R>?*!W*I2O!=K3,T2N0[(!B[2@YV9@6'%72 MORYCH+(G7-DQ*=@Y#NJALD-0+U!8<&7=_1 M;E2Y/#ML[5,RP];+BB4E7-FC5%X-0T647P^77PU;KT<<[X)7B_X#PY.(]>J2 M!" 2G1?^R&L@KP<"IKYVV_ID;*\Y?F!4MEIPW.[;+-[W?X M K4>M[PZSS_1R%CXKA+ 1N?:MA)P6N&HK_<4RHT>7[U=7E=KD_&^D7::X!D1 M%B7@^;=)@/M&W*8B*@ @W[%".]79'>Z PR<#E\OF*]7. BZ?PR'7 E[K\/GE M?+_+XPL4XH5"N=[C7EM0*ADERLON(.LX:WW^@$S6PJOX=CJ0B:T^.NW\#*#)H$N#6@I"P)OZ/IZ':L#U#U4O-SR;-G0_5)BSR-*-7G M0/$V6?,O9 4Y/@?JAB7ARA?*-B]8S]N M=-HM1/8YT=-\CAHRN2]JX/)2@5'*?\@3E!ML&V2V+0/H*-L"6'4!,AMD 34/?*Q] MZ+N"%$%= Q3;(CL3LJ08P%T?R@VMW8LE;=B 6W$$_2BREO*A'-"?XN4+[8U. MA!*P"[3327X!BD4/+%Y5[W"S[5@ Q%Y=IK5R8EP[&??TL&MM76;*Z-E'"[?& M1IF[/,%ZN]N#>T2 W7(=48LC3'0H;;N1:#AS\G#F9.',*=C-&1MBG/$QS!D7 MPYRZ39RQ,<@9&X.4537-.PB_L<68437<8\]R2!1I%K2>HR8!H7#QM M^HR94M[D.XKN\.=-7ROT*D9^=9)=O I"H"]S!XJQEJ=/E_*A.RR@T0)T8PQX M:@(%\G*HO$:L; A^*XR)%YU.N#IYC51M\[DI1E$/Z;-#_>473)[C=P2P)MD M(]<(1G';ZF6WK<'AEV^'"@:_1=\>+N73%B/4PY?2%L@R70)A;-Q1JE^#,0(; M26C7C X,S4[JA\#UI*3DY&'P2=$^J7&?M+_P2?\;/X;_YT]5K2\0!",W.!H\ MO@VR8WV-PV$'EX)0NMKM:)QH9&-$[H6VP5HTF+$:PT^@T4,NAKTYNCR&5'R9 M5MNG#C^';I$,IX%Z@?J!1F1+AEN!BH#F "T"6@GD!MH,M!WH>:#=0'N!#@&= M!NH%Z@<:,0;X@8J Y@ M EH)Y ;:#+0=Z'F@W4![@0X!G0;J!>H'&C$6^(&* M@.8 +0):">0&VHS[*0(]#[0;:"_0(:#30+U _4 CQ@$_4!'0'*!%0"N!W$"; M@;8#/0^T&V@OT"&@TT"]0/U (W* 'Z@(: [0(J"50&Z@S4#;@9X'V@VT%^@0 MT&F@7J!^H!'C@1^H"&@.T"*@E4#N\;K-_UX?G R^E,J.2]+8'L\IZ6S?7-Q[ M$/G\1D[S! -N&6AW209<.8<2)'HU:<1Z6R/9-Q$8[0F%^ >\4\!\$W"=@W(.4 MXW(!^P3\M(!?%W";@-%Q."X5\!K"RPE["#].> /A/Q)N)LQVN&XA/)/P29CMC'T? MX5L(5Q-F.T[7$!Y#V$MX+.&-A-E.U8\3SF%V(SR>\"\(W\KT)WP;X3<(?Y?P M>X3I+1[I)&&V:_HGA L(7R:L[7"=CICMICZ"\!3".839?Q$H(%Q,^.YTW;;W MI^OV?"A=M^?:=-V>Z])U>S839CN^/T5X#N&=A+]'>$^Z;ML_"SC%H./9 JX7 M\,\%W";@L<-U7"W@B( /"OA+PG\B/,R(F)[/2B;"E81O-N)>Z_6I&%O,1MQ# MOSX58],TP@VI&!OG$G:G8LR[C[ G%6-W"-/2]Y>2W#Y#?VLAO'TC# M.,QC[!K!;_<(?KMGR&^'_%:Z43%V3QKZVR+RU9?)5Q\F7WU9B+&SI.6"K[8* MOMHZY*M#OBK=*%]UI*&_/4B^:B=?M9*OVF-\=:'@JVV"K[8-^>J0KTHWRE>/ M)*._S2-?/9*,OGJOAG&.QGSU+FF]X*M]@J_V#?GJD*]*-\97;Y=>2'JKFL55 ML[0["7UO%?GJ[B3T6[N&T6]KV3@A"5>8_!1[=R>)8UHQ]N+_7KE-P$/^S#Y# M_OQ_'7OW)Z._L=B[7XB]^X78:Y$/K>&SS]^Z MAK]5>HSF*;<;\7^0;B8\B];V?YB&,6^?W.CQ_6"*5%2$F/ZG;C0='E;5>!J\ M^(.'(JG6'2@-%,_V%?\/>UL*$+J64U/ M_;K>^]6K5U6O^FN[IA]7%;VF6YJI6]-)LC9-Z,.+D3H3JM/RM*+"'GQ,4:** MVLT4A]U!L-.E-_9!5$=1>?IQA>MGY39$JAJ!9S8:+(LQ6F MJAJ@2)_&A'TJ[M-A+^&/9$8*];>%NVCEDOW4N0HV$,&F[?B7F$6*,3.P0M_I M-)2J7-74Z6#/V8&TIB(0PG&1Z&R3E1EG)66@[VJL\#@O:P1ZR>)6[/<"#W;5 M9Y0Z"?T=V^TX@T%C2Y5G_+5U>V/A[&9#KL["+Q@SCS]J]9-D#A-:]0S^Z-79 M>29G5,^QA DBF\N86:O.TU^KNKPVO[#-LNO5LPMK"QNS*PPJ,H@O-NVM]:9- MRU&J@#87YM;7YMD.M;JXLCZ[Q<4U$)]=B97UZLKR*J;MN979S MX^[BPV=[/<^'VB@S_E/KR_,4R=5SRS2A5)=8 JO4W&1IK

K4YSU)&E2>P M7ELL6:NNLX15/;=($_7J$DO0^FSQO5"939Y2J_,\I56W>4I'49XVJIMS+&56 MYWFJ5MWF*0LE>;I>G>-54.7J7%P)I3K'35=I&W&C5:TZQXU6]>H<-ULU0.3, MRI,,F-4Y1JW6(+787#C'$!:Z.KMMK\Y"*6L+]NKZ_$)#K:-_(3_I*^J,CSGV MQNS:_/HJ.)BBY;4M<#%-TN:C;J:P.;NQM0S-CQ(:DYB; X>SU/IJ (20._(@YF,+8VP"B8,]/2(8I&U(M@3JQ$B6\"$$P ?L. M7=<+7&/,/*9P^R.+YLN,-88*SU1,A%:V)H\$Q31V3&F0S6Z.)B M>TYXP0^A)"&R!_*!FVNV.LS.(^P?FXE.BZ.R&)@.IX(FS_*X'69PPV8N/ MV^'NNBG$V4*#<0[,9K$&RV!E5!53SJOP(I2Z&FM )1,B5=6% F9P<=4P8_&! MLR\*5JVDX);C7ACVDQQ-315-=3B59K"2F?<'&)(TBU48.E#0Q:BD*W%5GQ_N M]0<-39EY3%-Y&^ N:,2JKK.R\1G@;@_Q^L,]06&G0\Z%'0S0R M=%[6,(2#K\YPKPN1W:B9X"O4'':' ]^#4&: @RSH GAT@=U TV8<>F0 QP95 M4Y8A,]7BD5HG22(U2N,55QN+T,_9TY.-OJ9#XQ/_4C_T891 C( ]]%'J1E\A MM#;.GD]W7VY]=]MM]=IX/)]EM/-=/KV_?6,33 M;3PS>J'1UW$;EB3'*DY=R:BFGEG)J*:>65<4LXE[V$N<3LOV)'3:FS"Z8D3!UY\D)+.,M (7J!G)YJPW^BK MYLQCN"\LYYURWBGGG7+>*>>=[&*5R/*^R3J5UGL$NFO,M=$&6_44BF0K\S MM=.+6*(U&+!$OQ.A8@!;FHP@9)&I-NPA4V[4"T',8S]ASW,B!R#=4B:@=O8" MES"Z 3?+:='RX$ 25QDBM_W!-[_@>XSP_2!_0T@%WS/T0"I_C/_B6UX.6-=RN.X"?.E[ M8/+EXMMT[.I.3NNX]4X$L72D*Y#Z;DGDS)X7H- M\*7K.(SS_;'<%KVN75-[:QO?+C,J]E)+#]3*DIPFY/I:5P^_/\;JB M'*Z]\O8SK'TG4G)8K\_Q7Y2[)Z#OX0;D7'V+K=,1\ M6/^7B>B[5/\2E#$K<,SQY1S?K_X1(5?'1N7NR?$9?TS([Y%1N=C'\>>-KX$? M8<#@6YJFB1@?1W-\K_TU(6^F&CAM4]%G/"/Y' E MAX_F\+$,0?WQ#5S_O$DJ1RF^F_PH8AA'$L7'Z9O$)@*VC@QB[)+W M!VQ]&L1-^'UK@51.'L)^=(P\ERMO%Q.I\BYR?L+U/T-8O&#X+O)+A,4%AC] M7H'?:RG\.RD^+._U7'G0+^B%2>92P>>KK@-^:)97_.83X M&/D[P-<_3"HFSW\;\&N@?X+K?P?U'R*5,SS_KD-L[2"9,/T/ ;9 '_V(^8\# MOCY)*C_"Y4] WCI05*I\OP>X*L@ M_S3'+R(?S(-O;_(\^&_=M@ST:_ M1^#[M7'V3M33O+WQ78E7'A3Y7\?RH;R?XGQ_#_@4X"T!^1_G^-OC[-Y MG95WG(Q!XHT.ZT]8_N$)]O[KAWEYQP%??XCY'_7O!WP*ZGN2XX].L.,G0G&% MG 9\"?*W>'X#\%6PYYD+8_Q' +Z%]4/X.;]\O 'X[Y;]7T-X'A?VO [Z2LN\;@$_LL?6^L+Q_1'L> M$NW_;X G0?\4Y__N!#N^&W+_3$ _NI1JCZ. )U/]9Q)QJCX_!OA4"G\,\!L0 M?_^!]^<%P%=2\6(5\"[TET5>O@OX:JJ\YP\S>]AX.T;?76F!_F]P_2\ K@#^ M%-?_;<#7<"TYGG\#\#;@"9[_#MH+\E_B^7? (8&5LOV]JW+]PO8L3R^!_/C[:^/[5CT%_X/[8 _PV M^/-%;@^^#7$[5=[G,1_L?YGG?PGPC0=$/,+W6>ZFY/\,^6=(Y=N\_.N KP%_ M.QX_:+]"*K_+[?FG.]C:!2>X/'W'Y5K.9/W] M6<3 W^?ZOW9$S-^8?PWY]@3^4\"3)T7__2O ;\V3RK=X>=\ ;(%]U^+X OC4 M2>'_=Y#O$3C^F6#RWP*\]&'!=Z3"UH:ZC_-- K9 _^-Q/ '\;JJ]=<"G0/\9 MCI?0TB52.<[C;Q/PTLG8'X0\!?B)QT@%VPGSGZNP]7VF>7D7 %\%_CJ7CP!O MI^K[(N#K#XKYZ+,5MFZDQ/5_'?"5/3&_?QGPJ\#WEUS^JX!OI-KO+P#O O^; MXPQ?!RP_'/,!M&PW1Z]B]GNA:YO1SV;7GBP[;FM]0U[97ESR[8! MS6<0S5M8FZ? Z]D[G5[+Z=CL"L9[+"*FF3^8DUT<&2W%=EQ<&-3&:RIVJ^== MMIVN9_M04F]GZ*,1\M0F\7I=/W6#]_VDDL>6#LS%%5RQ?GNV76>KCK:&[>:< MZY-(D<'S^P27G]ZQ[5K LCO$WH^FK*#'URC5($7\KC< X8T:WRO>S@4I14O6 M),9+M4'3#0*RZU_"=@V(/?_TVNSJ\AP(TLO%E%Y1AZ=BV M*72#T$60V,/,%<^:Y4K=P%(S3@I(9%+SVIWA8%?8 ')V*[Q@.YX'K4\SQ6,& MA*XX'CN=57A*.&G'CW)%^MW](.QU<=5@\< U<5J],")\L>:8AUY)S%D=X+O8 MHEX'_12T7":S!][+U)RY*]/K,M>V26Q%UMO8A&W>%>F0HX8T4WT]Y9.,66A/ MNS^T[&RTYXP/HS^"%0>1 =;$%2;Q^=5QI'"]Q1:;$KB#3]I'" M1EL4=MV]/I9 5P#/EC*D-]>P]2!.V-YP;^\R#3NQ4'!@Q5@#Q U(NSWS!;\^ M"YTF,]Z:B^<#N[G?7&SNV_O8XQ19K&I.APT1#LX4N273JK$*U=C P.$L]_(C MB#:2&+P;9NB[O=##_P4;#+@S M6^4^$^# +PHCMUE)>L[UZ'8V%I-I9(,W]+X;.[!S\*TKNH@Y;^!%VK)T)"=. M;X>^?\ L7GY^$!]Z1TO&^UG?OS(4639U72*2I)@U$W\E3:,8/Z8I:[(D&::A M&ZJNZB:(R:JN$4F^-?7[_PPQ#$H2V7V^Q9^3DI]5D[O[*2QO'#?U)V M*_VX)/._8\\JSTG\9BEJ-#?6SYY9WMI,&"S4\70IV2HUQJ!2?0485&# VZQ, M8VEV:I8ER3IET(!!!P8-&-@M6M2 @^3-IU=S#'H-2V?;6AL* M9C;H8 $RZ)PA"E%C*U4%@U3$X!LWH1A:X@!=W*P2=:!@!A13M"R);V7#E5F#,@HTP@$& M/ &Y"8-'C:!;36[K(T:T@ (/.(HI=!^5V19L?S&!:/@@; M= M\%%'45*>A65EP^0E,4"AM@> @MT2&*Y[&9CFDZ/J@9="N& MAP;JG +C!!L:^%E;3]O *5H8&PRZE54UTQP64F"@P(,#W:#4C73(Q%"A8*S@CW3ZA/^O6" 7&BOAI ME9M9T6K1 2JWU!$*C!7L 1A4@9!91-'VL%5;/H^:\&-)6HMYPZ+>"&.20CO< M5@M)+,_)V;&Y"[.6)\'9;.B$EQO2LY!*+I@,>E,JU%0Y4,K%;!USCTD;?J?G M.G36BV<_[/.-)"2?DB]!$X+#P\ ?G#ZVY>PT)-KIZJ[TE-,98CRORZ:T86N6 M28_][?G9+4DZ%75J,)W-I*%NEA$4NJI+I0O]V@VY6+VD6Q2_2\V3FT5IAXWH)BU[$HKAM M2TI=+\GZ(/&EVBZT0F$^R%XVR7;5I'NH:B&-RFF"8E\F-$JKD$9C-*-5290U MHU!99\HCUT"R3DV:5',+F7@'.^@J1]8UPL-*(9G)>UE09%(K,4DI;J<:=W"O MT,%^8HQ1-(P5;.[4!8BL?F*&7F2&@IY)70G(Z->3-I*+VPAC86\8@>(MPB[. MU1AVU0/"+D94$78-7M3<>O-I-G$4AMV6<#6$W2+%6X;=EH@N$#&+:&X9,3&. MB6!70',;P"'<&:T#PEU=%4>9BESC17UBM6EOKJS'D;E&1U;NADS: MX+HFQI=:R.+E68(L1S+'P'ES$8>?Y\C9(1RG%W*T\QQ>ED-XQ"S@T%LJCE9^ M=S2CK0M/U(HLL&"D9F\O92F$(ZQ""ABEF;MR60;AAE8A _@J>ZLR2R&\X!92 MX##-W;S,D!C"&5XA"8[0Y#9K5ETXPB]4-T=LR%9$1 FY74A2&R')]DU#''3+ MA236"$DFB-=-,9D4#C6K'A]S!UD+3'$&5#C"+#@.3MT6R>J+R%0XNJQ6K)^^ M;Y:E$8XH'&"6&Q_(=;)UJ D'&(7*(U$BZ\2:\$/1Z%0L?Z0ELH,T%::+!VE[ MA"0;)VK"%87#M"[G29K9$6()E]0+22!.\]2"A<5 M#ET,MP?>7LPRBT'C&VB93L>;MMARVWM?::N]W%Y_+:W^[L7O M/$&@'[8IHD9$C1;E!"*"($2+YJVU]L?9YYPYR4QZWWW_W.AAGS5GK_VQUMIK MK[W6FC/>H@,9YWY1 M#RHE2>S?WHY%'L\-HY[KD2099O:F+!IY+K=Z4"1)\AEL[6AN&L_55T]6B2ME MQMZ.12+/M5A?3H+HS@*RMV01R7-IUH,B<22;V-NPJ..Y-.LKN>'I2"FQM6.Y M:DJ]%D>PH0(7AY;+86_!HHNGQ55/BD9+I+&W8'F-O5=#@]C/4LI_LC=O.3^] M%PD(KC-ITM;(8LM/X[U @+&.I#U[&XI20>_%0<9,F\LX7FS1R',WK"<;1N:, MV=$M&GANA TEVL603R79@,Z**Y..BO4 MD!+?7]"7HNS(8RMR5E;\0BC.>VV0"Z M9J7[2%IO.8^"GAMF0X4T_>T)Q/:&%"7*/)Q\P1D.ZHU;:^5%:@'*X7GUME1K;EZ+:-2 U'+W*C67+U6$&SD M@%KN0K5<'V5>"Z6T'.2 YY3:4:VY>JV1TB:P?7G>J!W5FJO7RBAM1-1*-ZHU M5Z^%$32:4"1*7+B6:Z/,ZI$1:1.X.L!1NNYL7P5(=#AF(M;T:YIYY>!"8"3[*WHUH!"<]]#P,*/"'> MCFI-VYMVL.]3TKL-T_)<5'AJKT7<>VHC;)P\[]F&:GDGRCS/-H.%_2R_1(7GUH?Q!G?'5KS'<[NC M"(/*2K:C6U/VE&^*,;@Z#NF!2B_,P0*5EF![$QM$&'.4 7'6U^]K6-:R4CCK M>:9@3DE)R;4J3T7\>]OML^\(3_7Y:F^_<7*MCZ<\^J"F 34KA8O>YRLM"\&_ MT^INN]''D\1E39?W'E #$K4148U@62JH2P"Q5"(V(6*@I#(51.PQ*!$7TV"- M0"J(C8!8QA$IY@%_L-'@/ "'N2W>>H!+23FTS#$?)I6K,B!H8K:&*#D\TE> M>\E2J"P% MW[@\S$[OD'/"D-E40NH]R3J79W/V!*<4!'/LF@%Z;T\0..E(1* MZL=769Y2;SC.,HE9P3&#*6&"V!KE$K,R''/J'0HW?* H00EG>4/U @H2:'E M;P12DQ1890$E*8O3P00%$)#R$B)E$Z@L204S#-(9D/(2HI4="'E(FLN_#JA2 M8!9QME=Z+&ZGH0.8%5)?B458GGS%RO@X8$B!"7%%XC7!P1WXT(Z4H1#U;'@+ M>1*O?4Y)J50UF-,PQ,!MZ0Z :DC4BB'G;(]\ ZX4J5"0ZT./42>+$ !VJ>RY M?,B>;9%[0 U*U,#0@U[B&+3M33$.J"[U M42@T:'4>V(#Z2F;JA]BP;-$,0)1:*-0PJ+#90AB IE00U[#EGBI(BUL FM(_ MC8/V9@M6 )K4/1B&@-F5)ML+#.\(!;2@=) QM&C;,H8 5XG*8K[A>=#6%=( M5"DC]26#DBE)'",'#AD2F8^YPDL/) E> +:4H'J^F$->7;LC%H LQ:F^E.\3 MWHHS29@"\)42"@Y);E=6$Z!+Z5K$EU:YQS;E/-4#IA2P^N"@!E^2H @@2S&K M)Q8'O(7:%0D!9*F)ZFGME0:\MU9W^ /0I9#5\RF7E29'=\0\ %&)&"D6P^L8 MD230D5-2KG:XLJ'YE"1G#%J0&]VBH5L(.?E<'I!GDPK:-)*>UPQ'< 70I,ZJ MK^>T\C36M(@*H,GM#;VC,-*RP""3=8A&N9(K;HT&/:B<>@@&VE3BQG5HF<(G'U?J@I4PU<%/12^4,$2J! MAJ3N:N!'QX!'[UI\!)"D>#5P,Z;4LW>[H0J84H@:N!U3JC8GNZ&P4A[N*Z3L M-%0X$)*=J^SA#\"6 K1H\:#Z5?.^ 9(4(JEE!CV.":1**46-@SLA-&<;("GI MJ1QTS 9JPT9&8'ZDM48\P M4IY,/1LJ' ((@L$4 MZ, .O!AF" Z'!('GF^H+?4_1GG NC \K#\> (+ZRJG;D(8:4F.KD-CHJI>N 0H4A06<5WLO9.3:9IC2,]NL(E..H/('KWT"A ,>V @ MJ<1@#UQBEL$1%I "4LRX!/B"'F)F?7<&D.1YIK*IQ!NIS*?>&P4HZ@S#;;0* M#Y9J,3) *O/J1Q-GZ,?J17GEF@:7?[']&^2]39UF(#F (Y4"?BN'EH$7R;0O M[ ":PZ_OS4_K_4@YAO+=-O(C+@> G5 MI6'(G6*>)K,8C5KVW-=9[LEU&:D#'+GXK<-R?/MMMJJ&3T32AJX:\(G8V=!52WTB6C9TU:!/Q,>& MKEKF$\&QH:N6^T10;.BJ%3X1!QNZ:J5/Q+Z&KAKRB<#7D%7QA1@E3L7H416Y M9:3$+0.Y9:3$+0.Y9:3$+0.Y9:3$+0.Y9:3$+0.YY51S'E616T9*W#*06T9* MW#*06X&4N!5 ;@52XE8 N15(B5L!Y%8@)6X%D%N!E+@50&X%W-P"775SK:XQ M2'G*]Z9J@2/NO-7TK5UL[>\GM<)&9:5-W!P()<,+^FQO8K5B1["%$EII(!E: MF4]_9:L5*2H/E1 62,9@6/1N5RU %#+*:(AER;'L+X&UHD/!LB9^-%+6E)TD M^MMB15PH%=I;+WVUPD%PB$F+^BH6),B8'*_,9WN-K!4&HE?M>*(%?+97VEH1 M('J_CB=:J<_V[ELK^@-HE8.C66^WU4(_%DF24M_UGEL1\TF7!4%EUY:GQ0(9 M W*?Q09E@0P% 5$&00LXB"+C0( U".,4!R16T#6U(4G)CWLJ%$3O=?)$-9)Q M(:BDI6+P7@=]+;$("J7(S9*K9VF1H,:F08A4XL,W'8O@3RK-JS<7BYA/NCCN M_6-HG%1UB8[CWE&&QG%O+4/CI+K'Z#A"),HJ&AJA=J"L//EFH5X<+0(VZ7;C MMA6&QDDKO:E<.<^'XYZ5T9B4?5;E*M"7=@Q"'HF'$? O'W9\3\9ATLAFL\(L MPXMEJF!+RLE$,LJ2AINN/$UGB0JR#">8I6(LPTHP4>&5M!.!*H:;*JEB*NEF M9U6H328UEY(53DDWCT*%5=()E*EHW#"R V1095B!U\IA^%I5<"7E (/*24DW M3:UR&$F4E<--IZU,S_>JXBS#R%:J5*HDO7342B4HP\D$D8&88 /Y;O%K H.X M>_E;^*UP3/HIL"$5A$LWF*E"-*F&C%0B0)IQ9R:U",RF&L+6X3#J!"<7_='/@#$.EPI8,:2C: MLVBM6$W(6#2X\&COPQ\L6N,515%[1[K?&U$1F]0#,,K"^+MRFPTK#3_-!/Z_ M-YR33NJ'%4O&E:J?4H)RT9IB8V[22USKK?UGX4! M/&5<_'UY6H;*LA]&EIJAO*K_=>F AO2X#B?[U"A5"63#39LS5!9^JE_3,*3[ M-<6,':-4*9[A9 4;*N%^N%G@1E =FM.)2$L_;+ I,*B)X?AI'T"4GM@0*=HR MP\,;@[\!!+6%3*68SV2H%/QTOWED!)4>&F;6KZ$2\E/,(S6"*@TIO:]7&D$E M,^E^G<60R?P8Y9H=QM<)#.F='6;VH%&NMJ"44G.49S:- M%&%#.F=3S=(TRO^N+Q$:*AL^I?PAZ9I-,>G74,[887S?Q:@8=G9CQ3#2G%2. M>[K?=S644W887V4RI&,VU21;0WEE4TO'DG[8%-.H#>EZ3>\[+X;*;$_U6]>& M'B;9DE^P [0TWFC@5&IOKJ>^M?)#>5Z3>N; MAX;RO*:4QELY[.SG_]^_2_8_?_\]?_3[?Q7_;_O =S*#"<62_OX?6)X!W-/% M[__A;VE@/*&L@OW/[__]-_P].+5V6D9&AH)'L)$,H?8+67802O,9_GF0^5@6 M*V;GLW/9*(+IHM\EWRRN++@RX1H)UUY^T?/SQ(7/,L0E_NCY._/X-1J!?/Z\ M!^">"'^^901C78 \2CP?@>/Z*ES-]OY'B3ZN:5G2<$U3R^)K6AJO@BVX;37^ MWI/!6#W.5W1\,5RSQ;BFP'6N^'PU7'EP/0#7"MX=^P>X%HGV\7?G[X"KFHG? M@X?K.H$[2917P87"%<'U5U/\:7#? =:V OP376FV,* -S MX5K%[']GPG4WXPP?PP;_\\-5(^Z7,RY/\B^HW5\#UY4.W/EPS4C2YG3&Y689 M7,WBLZ%^<_86[;X-+E23]PMXIB@7PE4G[GVBK(1KJ;A'6?ZZULZL)/V@S"X> M8BSC'/ E+?]4D^6P)72(,G)*ES(USGP'6O@/'G8ZNT MY^/A"L U!ZZ+X&H<9 Q(H\(+6/8]&7Q-H9RO'L>RO\LXC'(8*63970)&&38! MKA3U<2P;[F/9N+;.@D]0=K+A>0G5'T.\V@#MGR7P<:WM/I]E7RA@E(D-]UKX MN*:[6C@^PJ@3LL^W\+\%5S' 6P2\":YNZ._+ OXY/B]BV7,$_"0^A_JS!?P2 M7#476/!K.'_0MR$!OX// 7Y)P(>Q#Z#'8@%_@>U#?Q,$/!KHL+K0HM=Y ,^# M^NT"+@9X6Y$%AP#>#?4+!?UN@3("XRD6\)V(#\_O$/7O [@2Z)LOZ'$_PE _ M+)X_@OC0_C8!_WL&"82J_QR.3X.[ *Z!]B>*^N\COO;\%,#%&IP#"W?KO19\ M(<#;6BSX&H"W 'V?$.U]!6!SG#6^>0"OOH#O%2B7"Q ^WX(7 ;Q;>]X,\(9" MB[_? +BPR!KO!H K@3^3!/P#@.==:#U_%)]#_^N$_#V'^/K\ )_!SDZ@_#N!^Z/]A\7P:P":,OUS =[Z% M?P_ $6AOLUR_ &\JY/8*\0OQH;V%8CX/ UP(]7\BGF_!^M#>K7)] MP-]7\A MX+T ;X#G:P7< W EP!L$? S@W=#>I4)>/D7X/ [C\R_!)CA/TS<7 %Q\H05? M"G"-QH\ P%LNL/"O!=B$_GX\@L.3 =XVCM,7Z3D+X$U0?_](#G\5X W0WIA, M#M=C?:!'NW@> ;@?GI\8Q>%EV!^T]YL1'+X?QP/]723@M3A>>+YZ-(?7X7. MKQ7MQ;$_@$^)\7P/X&Z8_VF!_R.S8P$L MMY_'X;%0_ %@WQ+K^;L EUPDG^>PXP!'6OCZ1OD90%A;SZ-@GMO.M]9_+L#A M6UEV@<"_$. (\&/?2/Y\/,#]0*_U61R^'."MMTIZY[ ; .X"^"(!UP!\=#K+ MOES =P)<62CE'?8Z@%MOL\9_+QFNW*9"GJ\">'<++0,:?W04MW4YG,<2.!X8 M_\VBO7_2GE\"SW\*<+&FK_[-T?Z3 .?#^APAVG]Q%-_?Y'C^!' W\*]2M/^J MX_E^G/]]&OT!7EUDK;@#8+)+T8NR4&$^F& ]SI2DX/EGB@)W/ M&QDZ6IC*H67V(#BS9;HPS%MFBY8L9?:L->9,#&-6MI[SF:OR$N<'+4PZMICF MUF'N4 R3:;B..;4X6USL_*"1.1,1F2LK@3F36IF,AK+!\S584N\P<^6\,+<3 MGR5+PV6N>!=S9PTP=^XU,1[%9XXL6&8+F#";CY#9 M'&O,*T;+W'D3S)53Q)(DQ+)DN8\LB4>8)<_S9DF#SLR9@/HIH^Q%Y@S=,'14,Y[*S)*%&YE*E&0J+Y6I'_%F MXOL'C.?+,^W-"DS+E64JFY-I681,?B9RX9CUC@%FRS5C6OH%XV%FQN.3# -_ MC'^@0DOL;OZ!]GUWRR<%V^$_@^TS:@QCSV()A\8_8@G&;C>657!^P/("L$.Q MA -Z)Y9^QC9CF]LAKY M&2S+SVV9K.7\S)R%#B2P';(NXC9(UOW\[)-U#3_398WG9\FL56 +=)F$)-D<5EG ( MJ,82C+T:+.]CK!9+']A'6 )=9V.)9Q8LSX'S+I97,+80RZE@OV%IP'BPA$-\ M"Y:%C"W'\DRP[; $XV8UEDL86X/E&6##8AE@;!V6N3!^+.&0\1TLX3#=@>6- MC&W$L@GHC64QR .6<-C;C&4-\!]+.-QOP1(._8]C"=;85BSS@(]8S@3Z8[D" MY C+$N 3EF!C[\"R%?B"91'(%Y9@G'5A"?*R%\OS0=ZPO SD"$NP]7NPG UR M@>4,L.FP##'6AR48NT>Q!*/T!);3P$;%RU@!EM4@%UB"D5J$Y9U@\V-Y-F-^+.>!O& Y"_B/92WP'\O5 MP'\LX;!4B248H9.PA,-T%997 O^Q_!+P'TLPRFNQ!#D/8WD7\!_+"X'_6/X# M\!_+.N _EG#(;,1R#? ?R_. _UB6 O^QO!OXCR4<#E=C.1?XC^4-P'\LP>!= MAR6LIPU83@3^8PF&<0>65P'_L8QP&WE61T?',UOAL!"]'O\=:,WIZ(AN/QV] M;J"M/[H],WH=:\V-CX2[@2ZX;SLQ?_N+A#=0Y@>J#TPH%N>D@0FX2JC1WIX! M^)N JR6"SWJ[",95$T$3O;>38%P]$70A]FXE&%=1Q(?P9H)Q-470)=;;03"N MJ@BZQ'K;"<;5%4&N]RXG&%=9I KAA03C:HN@*ZXW3#"NN@@>47JK",;5%T'7 M=6\)P;@*(PL1]A&,JS&"$^K-)QA7901=$+V,8%R=$73-]1[] F%)_QDX?X*W$O\1[B+X2>(_PIT$;R/^([R5 MX&>)_PAO)KB3^(]P!\$[B/\(MQ.\F_B/\'*"_TC\1W@AP5W$?X3#!.\E_B-< M17 W\1_A$H+W$_\1]A'<0_Q'.)_@ \1_A!G!)O$?X:.G$>XC_M/\"3Y*_*?Y M$WR"^$_S)[B?^$_S)_@T\9_F3S!JL\@6FC_!J-4B6VG^!*-VBVRC^1.,6B[2 M2?,G&+5=9#?-GV#4>I$NFC_!J/TBW31_@E$+1GIH_@2C-HR8-'^"42M&CM+\ M"4;M&.FG^?\-8=22$8QQ]/80C-HR@CZ WBZ"46M&\A'N)!BU9Z00X:T$HQ:- M^!#>3#!JTT@QPAT$HU:-E"#<3C!JUT@EPLL)1BT;J4)X(<&H;2,U"(<)1JT; M"2-<13!JWPBZ9GM+"$8M'%F(L(]@U,:1",+Y!*-6CBQ'F!&,VCFR&N&CG]'Z M1[B=YD\P:NO(!IH_P:BU(QTT?X)1>TV4SS)[B=^$_S)W@=\9_F M3_ &XC_-G^#O$/]I_@1W$/]I_@1O)/[3_ %FXN^.V%]C/;'?9^R!_[JBG9GA M63.VH=*BL.O+[=NNLNY_CG96O-J?_7-T!N7]9Q;:5V'S/= &T1V9YA4@%9%V MV$-,)C[9_.G @'DE;(AA,P$?S4=AA78.GV+6W_9GMM'FLXTVGS%#[#T='=N9 M_6_.+%11;/Y#V]\ "R9>Z\^-S_;G)Z*;WQ\8",>GY,979(?G)*(_0S#O^1'A M1'0+?Y()M[_"VQDFRE=T!TSEX&EQ\X#\Y*5/Q4V+_*3T,[S)#9M?Y9_,OPM& M9?U%^S+G6F.:BF.*HI*(L_;58UGKQ8GHD]AI\_6):"?>)**_P\(\W8^MY:CYS?6<;X!PDG!L<.+N=.*L^TW!.$ M76,;YX58H7FR W^V['.-Z'.[WN?EA#/%@>-SXOSY4PTG1#@W.G#Z3HEQUO!Q MKJ%Q?O ICK/=-LZ["7^: __Q4Z+/=M'GC_NU/IL)YR8'SFHGSF7Z.+]..#4. MG&HYSF_I]+P!$!/5_LO"O*VP>7T_#AP?1G?XXBR>_3P&]..3"T*3"U>-:UXT MP_P#-91]^((.VU]\1D'L5*Q_PXB!R062T8#ML[#/;/;-,!,".]>C_O5Z_>MG MF N&J.]L_ZHAZH_7ZX^?87Y^<^W^O-$_0OQ^0142+ 47Q)X! MTO=JJ-:<(R'?22^IF.[@U@\^L:T8^Y*\S5%Y":\,_\^_ZVX0@^U\?:_1UG<3 MG$(2T4=TUM]XBEA_A6+]%"X+$]4'[YZD#TK4!U5$7%_BB>>AH3G-V7DO(+[Y MJ= ],*P/:%A_U/MYDU,J[X79_JMGALV)_4(_;3\I;IZ6-[]!\E3[_6%HXC5L M@M9?&#X*PB>']4:_*7'>.B5N6CER)2)_8NN?:DR#8'B% $VU%A M>*:#SA=](J;[_G%1/_<3KWE''%/9\_$@\U[BJ/S8QV+>U?J\?P*C3+3Z)\V1 MT[SA.)_F,SC-NW'4"UU]SHVK@7TYPO*5Z-Y6R^C7RYM(37K-< M[M3_QVRZ& :WJRH;?3LP;K_J]IL?J_9@G69'KV5Y&SL[>T9LF#(6!K-:'\R_ M'Q=C^!GAL9C/-B[A81)[, MP&P 6&-SS>M(9 I G*KBT>]@[2DH6Y/BT0X!5/LGT03&)Z+/X @B&/]WS.&1 MHYRL4!>(NGH26PNU=U'M]>[:]UBUP^:^C^5F""BO$6R8P(%Q_0! MH7S+C9)Q5,CH*:P!_*V")5@-^@^PYYA?/DH*J(8/=PTT=)F)#7W;W="VCWA# M:_Q%DMJY0.4BH'*!*/.!VD6*VI69FK2N/\IEM-J?%X9_"L-FE%K+-O; $$;$\[\] M<^S)%T>U%>8]CU4DVO^&Q@[OPO60H"$L/4),*["8]K]H'#]TCV.D&GI!/%S4 M/"+OA2G9([%G,-X'NHCSVL>U_&-@#2W#>=L?ZD.729VV!O]R _;Q77U6O_Z( MUJ _\<0OX.-8*^AKF&.K?R+<%HO2)\HBD)")2D)JN(0\_)$F(6?'H0&2DG\] M)J7$ITN)7TA)L;Y0H<8_*P!$<+.2GR(I/[\F&OVKFT;O]$D:%5GR\Q35WN*N M_1NK=MCTZ\*PDU#^S8WR@([RM0\UE+V$\DLWRJTKZ_T.I_^7-/\%- M(GJI7NF;']+^?R6V$ R;HP%$02]5%5XZXK#C7\BQ+-^SFW-FF"/[N 4[UK)? MOX@=)?NU?8U_7 [.I!3[C#SMGLG)0YRH(.BQ78DG)D&]TT^-)F(^"I7NT,>Z MKT_,XR]]M)O[YYBG#N&,4,:5L,+IUVQ72\PA:MO=(V@]Y"EJ.]RUIQW2Y.:I M/I>HO>1&.5M'&758TVY?)ZKL=*/T]"JJA+DLO7V8F[3VZ;SL1GVL5THID*>[ MUT6>#"!/_8?6E$DPN5C6D%C6HK+)=9-NC[NO4*\GZ5YQUSZC5Z/# SH=-A = M]KI1NDT-Y0^]KE7Z:I+YFT++_U 7G9\<0O,-2#D/[?2)K1)58^,AR?- M--\^1/0ML<^YV]W^5-Z^@6JP(SHPYL&OZ(>\EDFU8FD4QH[$CLI#7H_)ETB> M6!]'Q/JXZ?!S'4#\+.2L>TRW$/=>T>?Q.M&@8"?L'0QF,RY,MKL9[DVV9=7% MGZ&1C::1^<>)D5VDCVR:&-DYMO.W')_1N7X &AS][:JQ6T:U96&W&;"F"UC> M^J\/D.( OJP\*(4L;![LY6)J;8/]Q-L#;D*>_D#RUJ_O=\5ROT.S<\%#.W"S M<_B;JK6][]4*;'C4(8U&3\!(Q+[5#')P 3YKSDA@T^;H@S2^B9+-X_%AY)A[ M='>IT4VT1'LBU?[87;O$JATV?VYJ%N7'R4RX> MTZ)?C'E@-_28:Y_^:7=7=[\O5E&=3MD[@'K/XW<)T)A8XZ_JF(L;5T'87'A( M:.95AW#_F V]3ZL/O8A=K*4N\/LN3OX?H"Y"L)UBO>]0O1'N>GL/B*'01C=7 MCN7#@Z++'9SVT9U?Y,5:!HB]COEEN1M]\(!4L' 2_>T!%&"2$_/2@TX[[A%J M(]?=QG4'!K/CY+FIVB:\)+_%FOR>4X;M/JY3^?C[9+L5))[8<4B>GPK(DN=E M;H)L=&&OE7![[>WW7>>GOQV4MEJ^;I;E6N< M:ZV*UZGV.>[:%UBUPV;B?4W$#Q#*N6Z4@^]I*/O^JNT1'Q/*>6Z4)SD*F%(Y ML.D5S#%_3NS,@ T&MKIR:(-B@I&)&>*?.>9WJ6%_Y 1^A/\T-\+)WKR"\]YG M)T.1N\O)[PF1Q-TNM_AADDGO5C<#&VQE^8>-)?R8_W\L-G_22Q"L*P9&(C M04)TUOF1&%QZ-A-!CL=M'HYDXRIS]] F>VC2Z;N,MRP:0<_X6\3&3* A1F1#7=AH&S5:Z6[4 MUZ-/%I?*;-8Z,NK[ AB%Z'-D/Z/?0UF-ZEV? $*5=,9.G7X*S8&/?Q7;?:JK M)CP'=K!U?@P^A\T7<;;K_*BVY?0>HY%,<8_D!^_(D9PFW&_V:&3_+6'=Z,9: M^(YUOK#19>Z[W T&8\&861CF@QO5'/-M&G7B&620/O)$9&".>1;G=AQ/QH,6/MMJGVKN_9SO'9B*AU^UJ@1OOJ>/*](EU9!;3C7:'_2IA,17I#ON"=[C%].LD_OK#/^KH -4]&]9D6)0U MHJP&K3U;:>WE?-T5TR@P@%<=CVY56KE&/UO7BK-U6%?B-?K9&G"?Y$#SG>9C M[^&!%.;;#%S9\"X2 Z.0L6FU,&C*UL"NYYCW]4A-6QW[>/V>MNR=56,S#X_J MZ("2[:PZF\7R=U5A/CG;547Y+HMW5>7[ ,@]BSXK&$4%^8?0TP!3](FR4)0% M,&6_FG(5GW+9.W+*!?J4"_4I%XDI^_0I%^I3+M"G_-MWM2D_TN,YY6^\HS9L MFO(Y-.6S'?OS<.8?/7&8'\)GA\T@"&8SX_?];U*/'>C4H:4ZMKUF[ BC\_ 4 MJ[^2/?@TNCJ3M>:!X*W.OG)U9JQ_?6?>QA?7[6G-)W]056;8+'J+%A&%E&'Y M9F_#17;X.FH;3G%3,D-3LE>-G6EFTBPS#^=+^9R2F?*0\0?:+#9O;=#NQH]X*&/ZU:A6,DZ"IM_Y/VHA3?I M+51E4D$7TF?%;Y&F0N DT!IUSO@^7- +W0NZ;]]@YP'X^$[]XX5RX_1!^_M1 M7-3#=?X>7*D<;1W?\K2'M'78SQBXX2HS+=HW4=M[VZXD\P>W@_?5WRO"1LSGY#H\-.0OE'-\I2'>5=G0A[":4CR?E'1[FZ M6S?O">6[;I3LUP7=_ XO_$"W],*?(;(,>C\[),Q1:X>O2"V_]65'R MSU[C9[FPF=]-=X5AR?U^34"O5%4Z18B(XY\_AUYC99_]?R MYN3>@0%X?@-_ODE^_(]:>_EB7X/)S#!_L9?D8UKOY7(7-$[2=%O\U1U\GF]J M\SSUNJ[LY]:9H]0*8<2J:\^=NKCCDND/LON?E X):\FFQ- M7(1K8IQ:$YE[N7TJEX5N#/.9UIF=KXA97FG?ZZD^>G,UH?>I#;A6_SCLV$,W MRA40[S$)Y0NZE .-^X12JP29P[< MMWMXK*F'O@P]M^+V+H+M-;GMDAO/9I 5-Q9LP7P'_9D]1 _F9S;9F*_@@-3) M\:H]TO_UBG7@Z>3" PV/@89'#][>?FPO[S]W6O&5OX@FOZ8UN4,U.0J:S!RD MO?>=[7U;MG>)U1ZV]=#"W <'K!X$*49#\UEIS%\VOF//?]G\N^3\]PQG_I^Y MYB_;NX3SBB=.:FNC\!(K63*^//>AFES\!J_\9'$\G(^'CKM9W@N?R0^!=@.? MJ]&!V9_K/Y:;'9N2&QG]+<;,!^%9Y-/5 P-FFU8+]3M5S(2*S(YIQFH/JZ+E&K[9SX32*T%:[)^&QFO*H67O!>FU63T0_L\[!7J;STW$3W[B*:H&SD7S?U0FKL S?SX3_#/ M52#39C>,R%SY9_CG-KQ;@O\\BO]\]#+\TXR5W]^#QZ)KCVAJ9BRT)!*/9+9/ MWG]4C0TGGIAQA'*N9ATA=3-?1WKKST*8]LJ;/\B;\7(I//5G;/+[1)41U"0T MMI@WM@R+F>8/)%)"WJR3-V]*<5U!S8C<5=G,-W@S47U,-TO4*GE3(6\>EHU- MH$]\B>C#.F8>KV=TH@@PVU]=[/U9\079\>FY\;K\^-2"\,P9LR+X!3CS$-"= MW_F0 _?^B?8NJ!^?"NNS=138ET#L6-^"[4G:6_]F6]$S>';60EWT]],B_%I/ MURQS_LO2-.R++SBMFN'MA\V- [QM"4_ZBX*;6;RN(#X]?^:,>%UN?'KVS!DF M>@=X$_"<'REQ4FTXJ5C=_OCT@MCTO;%W8L?7_ZYM;6C?_>?'^F/[3K7MCTWM MB[V^:RJMB,/7T'ZZ=C]KRWL:AQ[K,O90G?VQ;G%GQEZ)]4N\Z-I"EK>N&5?C MVJ.[IIX@^["N,#[]:"PG/OU$[);,WNGPT#[_T(*]]U^Y:VH?N3IXQ[R=\;R= MWC%VE+SGZO:V?WQQK*YG_9ZV!L!>D15:NW]5(32!8[QR[?YQ"_9JFUJRIGF%\ZM%81GSJB=CDS-Y?,>?P.I[V8:MU/;&Z _'I/:\T[8W#]/_R MBCEFZEZ"]\?>!O (WO\5B(A/MB-P,-8=^_A4VUZDS"NGH-K.6%UW:-^J46UG MA[ZX/V]@>E]\>O>5;?O' 1^F=VO#:YUX^:EQ"[ICW?'I!U[IP:8^BJWM'M,? MFWKTE<,XY*F%\;JCL?QXW8E8.#,^O2\VO3\.C)AZ.CZU/UYW.M&T&Z1:EQ\P M3Q)U_3-=0O(N:D_"T806Y:LNFZ02")SU=-5M+#MV#H)8B>2]>7SDN7DLNWF$ M>?!W<$(<,#O^9)EQSGB3\_U7LVS?/RCLP"\=Y,1'[J)W?H$2Y%]'Z*6OO:'5 M11\/6-^?N)SY&GW7^YAO$?Y;O 3_Q9=%7'W/LF6-Q9T7>M; M7(\_9NFK7[FR:47KDF5+?0LGK+PLAZ/(MTH &L'BM1( UC2UM"R;Z%NU;$5+ MH^_^)?7\Q9_TI@G9$=WK+2 \6 OXZWKXF@K5 -S*-U8(T$)O6MK:M,('6)'Z M%=<*J#6RHJG)MP3N[VE:L=)7O#*R;$7K1/Q@HJ]EV=)[+K^6Y3#J"W\=$NBR M>,F*E:T^HA9^BM].!V "TJ]DPC*VLFG1LJ6-ZC&1P%9G]835HL%(TVJLUQI9 MLJ*1&I3C6]RRK+X51M:T%(#&96TP%SG<_\O>M0;)55SGWO=JP9(P O2$D4&P M$J-AWCL[ZQ6L]B$M6HU6VD4L"#3,SMS9'32OS+W[$$D4D4"A'[%,RD59.#:@ MQ$GDQ!'*PXD\7+ M;];7WX_I$ZG* M5:,ZCZC$_Y%Q5%/36#^D8CL3OO]V6J2,HA#1.]OK&7ZQN' M,,*]" 6Y49-]LI99\)D'3=3&)ZKX,GER'-D,^3HN#,P9.MLU:!M9J: @1Q'Q M615?M6+Z8F3U!OO91N=H(;Y:GCRM9F39Y+6ZR6MZD5I#?VL-@ZGD- EDR9<%WM^^NS%V@!:9B?4-+S_)">-_'[[-[:4<7 M\579/00=2!V@ #K5>E>K>@75AJZNKS:Z!UQ>;.P2W0]5YGRES$&?#,N /OHR M%DV=Q69#$YAYE)/7AQ,5)("Y!M2O1F.BC4 F<*23[HU4+1^SG2X:91F.!: Q=5)=Y5QP9C/%],BI M:]TG.^,T7Q_<=(8;GZW,%7/E"L6(@-W6&W6+$[S:H52XD?IREK>7L[QO8;E76M8WK%)OG$-RC>N0?E&>ZUOU,Y;I>J&'#;83/DNRS=M\+D) M, A=4G(=%.QL]86$UX80^75C4IB3KED/7YIB0R"\6L(U)4,E:&WW[Z'1SFFPL?H]V79V8SR-U\[1X,%,K\QK%.V0MA_GKWKAY MBVE8-)/R!F-]%XQ2SA1]=,:ZZ;L3$PR_)=]>(KHYQ CO\$D.@>SC)%0F[SN2 M3AKN$>2=A$KK,FAISO,^!-<33;Z]7^?[PZWN>K\Q?\VENHT7G: MOI)1JM0.^HS%K&'DX%)82A\K&PMWJ2CFMA=FKG5%PXP/TO)C+538Q6@W)Y>G M)95^3*OBU-'KW"VB\R+D,N1=R-*5HO-62 "R!9*"[(>4(8<@1R$O0$Y"7H&< M@UR$7(:\"UE*,?<@ <@62 JR'U*&'((0%R$O(*Y!SD(N0RY%W(TK4H#PE MD!2D/V0,N00Y"CD!]##XAVWR?4^[C/' MIK^QXPFQD^(8YZX7G?3D;+4*_NG3T@X9(YF":-RDZJ7G%(I52+'V+C3+N,KT M)WF**_W9%3+&HW6CZ*2X>/1=&XIM2X.[632^FOC_&?%TEVR#XN7Z=HC.VS1, M<6_M&-,4V_.PPCD-SVOX,QK^"PU_4\/TQW ;/Z+A)S3\:0U_4>\QV./9]B+".^?X+Q%L;'&=_+^%2'8]OO:KBUT\']&BYJ^$4- MG]?PZB4.?E##']/P/VCX>XQ?8]S219C_/BNN9[R3\*.-*&ZUQ>[LHWG>QC=:_#.,2?;%95!F7VV@]7&1, MWFZO;PFQO]U9W\:U]6W<6]^\]4U\,.O;'>)X._G;_>WDSR^UD\_OI?AQP*0C M?;57S&B^6M5\M>KYJN>KXH/:B[>Q3PZSWXZU4USU?>RW.]AO,^RW.]II';;7 MV&G-;T]I?GO*\UO/;\4'M<:>:B=_2[&OOLR^^C#[ZLO:&IL0^S1?/:/YZAG/ M5SU?%1^4KQKM=+["+O;5'/OJ ^RKN09?'=-\];SFJ^<]7_5\57Q0OOJ-9O*W MK>RKWV@F7]VF,#VC25_M$XN:K[ZM^>K;GJ]ZOBH^&%^]4[S4].4'Y;IZASC9 M1+Z79E\]V41^FU.8_+8@[Q.:Z!,FD]?>DTWZ/:V^]M+9*[=IV/-G^?+\^>>] M]K[:3/XFU]Y7M;7W56WMS8E#^F?X*>TS_)3GJS;V?-7[#-_[#%^^WN]G^(?% M+_-SRIU== ;I(<8)_FS_U]MIS1GCS^V?Y.>:*?Y,_LEV^GP^QSH?;Z>_<].1 M*C/9;#B0%?<4S&(X?\_LX\5[3'/S0J5VX!X1"!#F,W7K>O26SE9*5?K"0T 4 MRE;2"O770GV;PZ%H3S01B4<3?778TR?XRXM6N+\6[@OVA<)(H:\I^KA@Y'\K M.%O4%>Z[UTNMH;*:'*VNL M(O03ZN O9LIB"1YF)-P33_31__7 M4&6'9-%P# 7YVYA("U-:%*E"?273"K&]$Y3$@ZNGLW%#-$&"IK9H+,H>A6+] M9J)F9(K)D#_HCX3["J7,#' D3,11MILD8\=EFW96O0VR78]LW,YK[ 19*:%Z M,5\IY)#4VQ_J%35C)ITM9DPS.1D.]ANI7>D]P]LFDD'_ -[1F2%Z"_L?$8,$ M(OZM]!;U#PQ)O9A_MP1QJ$R,4F:/?XC?$_[1U-#PE,SN]6\;3@WO&1B3-!2$ M^LAX>G+7>)K;"?G!)H8'=Z6&9$+8/S*V:V!2J4>@/C!F%X[ZQT9W$DX/C@U, M3 PC*>;O$Z5,=I:^?%:JY R,)M1O[-TU.L0LZ-\]RB#DWRX!#6E\0N*(7X&H M?WQ(HIA? 1K7I(0]_ET2)/R[1QCT^K=+P..95*D8S(1"8?^00A'_E$)14E4X MYI\8E"CN'U*HQS^E4((T%>[U#ZHAA(/^07L0(?^@ZGJ8YTAU.ASQ#ZI.AZ/^ M0=7M< PJ6\=V2!+W#\JJPSU (^/#NR6C1G<.3*5W#J"5U'!ZYZZAX62XE^R+ M_+JOA/L-RDGO&4@-[=H) S,;34W"Q QY^MC,3,<']DR.8OI)(R(U!@=A<(EV M[1P?@ZM09LPN82?*BN)^[A1GT*1C-OI$U:KE"OE\FJX.7-)/&(2B8H&N6X(1 M\<#N4>M@E2Z $-Q30?& #:-B2*&X>,"&/6)B1&F&Q9 -(V+*AFBA4LNE[=J& M1DVK-I>U8)4(KNAB9<&^H&<+,[/:!3TT.E6%2DM\'LE>P!.22PG#%/N)=POEHQZQDSA5P]HU"N$(X1 MYJFS,_A5UA4GHFSWQ=+Z8F3%M_Z!<^I8H&3L9":)2 MIQX[RRCGD*4JK*?2U^THN3?NJ,N#!NT<[&9V"9DAV_"'XD%W$=5$J#=LE\ @ MZQ6%PU&G &4H]7 L;JN;F7FGX7"BWO!T)GM@KEK/B82UIKF,JBH2DRU+ZYNT M)$42+!\C]D!8+R=;@^?!HK$:QJ&IKKH:;K^)#R-1FW KWBCK0KE+[Q-7D"/Q3*1FT]0IT;L)]6Y"O9M0 M[R;4NPGU;D+?PTUHXXFRO%71_4-5W9X1KH5CWN[B[2[>[N+M+M[NXNTN/_WN M,I^ORN=\/&3GZ5E?/]\^.4*/V_1D]$2R&J7_:]Y#C+?->-N,M\UXVXRWS?R_ M'F+FC:SW(./M,-X.X^TPW@[C[3 _IQU&/KS$O(<7;VOQMA9O:_&V%F]K>3]; MRURN,)\K1)(C/:*7N+M)=Y>XNTEWE[R'O:2;/&)M)693D[@ M\21C+[ST14K>93 )N4*T<:.I59/5<+Q_$Z75O'W'VW>\?7N+M)=[/XKR?Q7D_B_-^%B<]DK\42K^" MB\34ET++QD)Z-E/.%>%XV^B';[C,]+01I-FXJF'ZU5L::T$^,U=TE4"]8AO6 M5U_WMM0#&WWA0#P0])GE3!5]MWR]T5 P'/D=:Y'D(]&I50I%>KE-Z=(X"1+S= M(?.:E [%3J*H+BU*C\Y=@' <&'>[%,UEB5W?C:CO1HIM(LLN5_51G).MFMZ* M%:(3P@I;)\1W@E?79^AZ*>BEA/!?H]T#2H_Z_7GH01H.T6A5 M[S5-[\^A!^$S,-QZ!X7C!V>@!Q&W=5VM]Z16WQNSHO.-*8HO<[7>,YH>G9?A M>TB(LTV->B2_J<9*>G3VRJ6'Y?RV:GHTKN?4.^D=.2 ZC^P3HKO9J<\>^Z>$ MXSOT(KW#:^4Y'79]-/Z7A..[7'X1;0PXW*[C$ M^%-QM9YM8_MU_BNP(RX8BM+4)YSK8XFKOE-?$^)U;8+U/OVD5XM+JZ6A9>(M M+M[JXFTNWN[B'2[>Z>)+7+S+Q:]S\>M=_$,NOM3%E[GX_P<4_[.(WNO@* M%[_)Q6]V\5M1C_DR MCB366I#GR! GE[RI(,^G(3Z.]S>&1>>Z9O*C+O&HJ[U9 EI["ZI^H1Z M(?GUXA-"K@N2?T@Z\+>;W;[=&YIJ>T]KZ+ M][_6ZF]N(5%S_H MXK_AXA]S\4^"4\Q+FGB:S^.N_#]R\2\TR?6+HJ/= '^DDW7/8M^X4\A]ZC7P M"^#_W4Q\B?@7\$O@<95_"?P4RB]7Y7\(?@7Y6U7^]2A'YWL$A2Q_,_A*<+(C MY6\&[P;?H/3CS7+=%5S?.S^^%SR!_#Z5OPW\#-H[IMI[&'P[\OTJOP(^!?Z0 MXH?!9\'/*_XL^"+X;RG^$KB5^!GX;^X18Y_A^!GP5?J<:_%.D7P&]7]:T"OP2>4/D;P:^ M/]TF>1#\M-;>5O#.5?+ZI/S=X"O![U<\WR)C[OZ0Z^L2)GCW*F=\3X$GP(\H M_ASX=CH73,WWI\&GP'M4_N?!SQ;E.574_FGPV572?A^!?*5%QD3=*&1[%"MQ M4W^_EJKT__UX,\ K$3Y&36_SX-WKW;L M7\WI^S3 M"C]:U-I; GY$*[\2?*4VGKO!NS6^!?P8]/]5^?,P^(G5SGJQ$_PT^(AJ/PM^ M5FOO\3;9'WF]=7'LR@O(_WU5_GGP2^"/J?)_#'Z%SI)3^1? .]? GBK_+>HO M^(LJOQVW! FMO\O NY&_V*'6'_#M6KZ?])'_E%J?Z)P+6@_M]6!WNXR;:OL7 MG7>Q?!3V;Y8\3_6A?%+9HP0^!7Y8]8>B(4YI[7T2?!;Y+ZG\%\$7USCK$<6S MG-7T_X;Z@_SOJ_Z=!3\&GK>O'_ 3X'^BKM=_!Z=8\LN5/L>X3-G^?IWX ?C9 M-7*^:#Z:89<+X E5WQ+P2VL<__L(^)4USO4?!.]<*SICBM\'OG*ML_ZFP+O! M]]K71X<\]V.YLI\%OJB-[YF.1GL?!4^@?%65_YT.9_^F_--47\GA7P;?OM;Q MWZ^"3X%_6XW_Z^"SX*?M]87:7^O8_RUJ'WQ)J]3_-O@QK;Z.3GDVU K5_Y7@ M)Y!_K[V>@)]>Z\QW%/PL^,.*;P>_ +ZL2=8_#GYIK6T/(?:"7P&G>:+\1\'I MC)4^U?\#X"O!>Y6^!=Z]SNG?8?#$.F<_.MHISXWTJ?Y^%OQ(R=G?/P>^'?I_ MK_2_ #ZUSIF_OP.?!7^]1?*SX,%;;?_!W6/]0'/7WQGI!-XT15(*Q(-Q8?6D M^3Q;D%Z;A /Q4%#DZ7,UI1B*T9_9%NCSU'1ZI"BR-G!RUY[TV.C$9#H--M3 .&\X-<0D5TG/%"O3F6):?H+Q'INPJQFZ M=IWRPY&K6TEGLG0P:)H^4TE/5W('TYER+FV@IZ5IXY.S^7'![.&L$)!6'Y>T/'3,^ET3T%F%T5ZW@HD M"A5U1FD$2!CEG GE/3TJU8G.!12*U,\DIH]J"__#WK= V554B59W.DFGT]!- M:)P $4_@1A()X9[[OS&,G:0)C39)DR\(V-POW6VG;]OW-DE<$9+IH+1M:U"6 M.O/\C0O'SZBC#W1$%&)@ O/\\7!\#P<=]0TZ^H(\0 <0D;R]JW;5.57WU/VT M\UFSE@VY=7>=VKMV[=JUZ[/WJ3N8&QEAPX7]V*\C;*COFJT;K[QB,Q3DQ\6< MO!OQ4*:*+#=6*A> D%OTR&"=8T:=8\"$!',&#'P7^.'5T%"<_U;V"+1R!#B! M(O13QVPLDRT S93\E6HHP=E)>S^JS)O+#YCY3^ .L4J42VEH:++L"6D0:R_= M5)@LCI7V&8SDV=[,V%A)4$X6_73E+QT/#7$P-S*90T#Q(]CU8LV,6K=CK9J0 M1E@EP=DKCDV5AST>H-Q0=O+-0YE\'GJ?/_3"#!C_Q7$I=-'@=9Z0;BQ4C"H+ MXS>-3);&\5>#O8!KELF6)BN,?JQ9TN$GB0;7(W@76Z4TAG(:R>9$F;T@/:WE M0ER:UFEGVTQRH4L;N[!(JLB''&=DT*?K/IEH;"$_Q8FI(?SQ[TG@+E_(H;KQ MFC49@#Z#%,J5##07>Y#)WZ^6C<;Q(ANRSLL:T?J^XHK15ID"=Y@W=[8K*0 M*TWF\5VP-M>U'4HUL:6=54P"@D?1K1NB EQ@JWACX% M EL8ITJ-%]78$#\)+Y."9?"WU2LD;VT@"J'[;2P,3?S9=Z\-;&*J(FW38%4# MRX'O80M%*FF*-%3@LY3PO?F; ?5?/K!MT\:!H6U;MNRX;.?0SHV;!BX#]0%+ MRDJYBM+NBNM2*)>"P>B45B M\!U8BL68$ZY/^@__FT(SZ#AL>'2L9KF1XVIULMI!:WW%M^'K'][=UU\" 'Y;!?X[^ MZ5SBA.F_CFO=ZQUREB+&X/9MEV^Z8N<.12&%./F8HS[=I* 0X?@N4(@ !72S M"HS^C3OZ-1XXA4+.D9_15,H)QSB%*%"( 84H4! N6L2 1?*.:ZXT*,226+OX M3!:A8L%###A "C&B4)E$C!T[MX.]-RCD$H@K/I/A@MF*.% @MS!@;+],$R2G MX$:Q=O$9#F< ,46M<$4S$D0"9G4;B9B+)/AG.)SVDXAP$DDB,3%FY2*6X23P M,QS)ISP2:4XAQ?MSI"(P@OK33::@8O$)W1$7DD@(2:!*I(&$8,!.(IMRZ#,< MSX5%APH2R$0&*. &I :%/&>"?T;#Q5@5$UD@@0L..XE8 9'%)X@B5T4B!R3X MI%:#1";GT"?\I02)J&I''M6J#H5LS*%/5#*30@$[E$<+V"EP^?'/<,8M^A43 M*121!\(/II!(%:!PG'\"O;#)@PM6@O3:2B(=01+\,^SF:(3Z2+AB@.$2VN%# M%/>QFF(F,@5 B_-/;WA$ 9U(H)T00P/_MF[S\T DLF@;XOPS'(EHW9%"$F@H M,*C"TA!E[@0): =\SW%SYRHV8D1#V(HJ4Z%HP/A ,;CIN-]DHJEPT5902$=- M-K+I=![EF4Y5D4!;(:-5:G&1S?(!&LY&JDB@K1 !,(@")M-&HIC'7LT6R&I" MDG*B62&-%)?&I"1BY2.7S2*15#YC\+%C&&:MO .[V$G% M.2]C=EX4D6C>QDL.B 0<%NF""2OYQJQTLH*.=C2D-TE1"=N:E,B!?N=&QG4\ MU2UNP8:7#PN))JV=FU=48C8J;@9DX3LOT66@9!DI6KEPA0ST8Q-=595Z1")6 M,A$B,V*7I2+C9JUDHH),=5,4=O@-6+BL)K=K"=J M,+LVQ+IF-^M9%["8-C)U+2;:,<_86<@T8.QR"44G$;/2037T3M,U?-\(M^/7 M,Y8Y;XPFK4+!0KX3<0T_[S>V-OQJ8XMVU#.V%KRZQC;O*BK)A)4*%-*.JG4* M*9^YM5*H9VYQA'GFUD:FKKE%2^J96QL9B[E%2^J96QMR(^8V[U/QG)52@^8V M[^DYF%L;L7KF%BVI9VYM5.J:VWS*;^YL9!HV=[CC!7,7SP:8NW3$6PCDPTFJ MZO57#@[M&-BF5GDPLH*\BWZ>TU&EY'$[(5@.DD=2QU732RQBQ87ME^G%U(EX MZI"P$JFS7DU'O46WE0ANGY1K5,..>0N F!4;AVF@.U4GY:UX[:34C#EF('M& MV]H7*1R@PENKXWJ[A[ 5%RH([F!32T/S2&HV$-[/;^4@C#>GET]&][8MK18>5<(#_ M6Z>CQ!&WJSC,R,(GKJ-Z>X^4%95/P[H?72.2].9BNW+FD8CTO>OHGD;8!T;! M[,V\3L,;'VDK#3 5PL>OHWH&(FM#38.!T*, -!(ISTI8K5T:K$10Y(!.R!-% MSDHH8G;'=KU!WEP3LS>(VPK=CZ@345*)6P6*5DD$,FBH:6]46$O.^5:517W@XA8[IS9Q6DX#2]85@:/C> 4#,7C.:@W7! M]L [$XG8&PWVP CUT&EX \%J"])@"W@8B([IC0,[]V *M- 1C8*W7PH7K13R M5=JK*YZW2X[;QQ*N''APBH[J[2GLJ$5N2&1 BX[OG8]9)\H,6(*J(!B-BK?= M"UNM>L8US9EIT[WCF*35*&; $A0#%BW>WLJU6I$,&(#:@3L(LF5M6U M>O]X>[98P4K$?D25]H[[7*M-RB2,\8$!.CH5SSXDK522PM[KB-X L2.">=#C MC#02WJE)W-ZK:5Q25UE5WX&-7:TR?%Q@I)*.ZRVD[8++$:&HT? .+"+6P90#K=6B M&G4*WA[$.K9SU7L0_7C?=R9H9R,JYDHC'%*GXXT-Z[JCEIO".[*(VQL3QPFW M:L;->"<5KG5;RP_*@^(Q=4K>PM0N#; 250KJ'5+$K3N"')J&2!7WWME$U#I7 MY-)\O6#.9#H=;R%J'9JY#$I!AI/JZ-Y:U,Y&MDJ;]!G".Z6(6HT,.@L"PE8U M.MY!1=PZ1'/\1+-:GMXI1=*N#7A*4=6)WME$W"X", PBI%9']1IN5=]\V&]= M30X^"%F^L4_!.(JS3"[H1,$89$'<:=?D17N$.@=$)6$Q:E _E+>T?X@)*48A05N,E@SO2]&N"E M" \WT2@+B_BU0Q! 2U-[LG7:4YB<[( M-)5&!Z5H3W#ID7$H+!4B':[9$OUX M$O"D-N!Y(<916SM5/TH$3*4.>5YCU*I'\C@7<*0FY'AM3BK14&W(9USR*6H# MF],()JBM*]4B$VL&G7? ;D)V@A!HU%*A]!8!AE245#/#'Z01478CSA$CC6D*C+*(U!2< MP1O'! ,049:#C[-(*MP(YB!H9T3J2T88J[1%TZH.@0!5V9&X4!C+X#;]5X"9 ME/8J*@9A(GC$2O\X8$B%R0@,6P-KG\$!':E#.=Y[;M%*XU3?T"4*I8MU%0QV^X5*$CE MRH@N=A0%Q]ESV<8W^.>6CG!,FJ1T[=+,W:M!4EH$G;D^6UN=' N2!M M/3$#"LH&N?556XL8 EQEC<0B(FZ1;95G U"ECJ0R-<44X*3N@$V[5!G!<])F M!P(+U^RD@9@PHR(DN5Y]"VNSG MA%2S/#4ZT'JG]1TZH$F;E17J$;,%P5.XY$:C354(Z$63D6Q M/K1(N7$?!]"4ZI844U#<,LC,,"_ 5+->O*8 C" !0%2SGE@0V35\2FQ-$LJ MB?$4MVY2I7^H(YR4=BLC-K8VG "_$B!+LY7EEL>U;^$M7AH@H39O@N>D33W6 M^9F6.I7)"\E8]V U'6Q 2-JNM)B)(Y;:?7$0@*3V<33!66O7%ZJ J6R6,/-1 M-3GI"X6RW-PGI>XD382@?94>X0C8:BZ,U[2O/B\T($DEDNO*FMLQ0DI)+0%"ZPG4UD;#/%Y42C+R4,CUJJ5K'8I''!E"E8F2X M6@KU"$ 5[FLHKZ8R+.G"PMY2/D+EU0:-LY8*WMNE*9 -RDM%P.-3A[\F&EP^ M1N65[>"R301O -/DYX+RLM?3O /CP28S34%0'>&T['!TFSJPZ+&53U)Y92DX M_53PA)LFSR>45SMU+OE(++"KT^0IA/*RJY/<(B03@>8Y+2-X 4$=X\1%!;8. M0V1I&M#H"Y.RXV2L*RX*ZB:P2X.NW%'7D $*&JXI^3A:4 =,.GA MS 7%J9/Y>Z(U:PBZ=@/P9:<7HO;J>&R_<1]%AQM6!WL)N2,+GIZ]5RL 21WP M)6KNDT2H&Y17XSU;<]O'([R@..E +!OGS8E8FZ/?#P*8:H.4$*/=8M'QY!M* M2TU(\;$843DB^UVZ[#EW>_"F G);8X0HU:6T7W'@$*Z44L7Q2G MKD&J*E#$A4N HI8.T1J+N[",NNYPY?WC8N,] )N\:<^: M7G('5'G%MJU:4==8_:()AYQB M]8LF'?*#U2^:"%&V#2,EJ+86VY#O>5B;[D-]9:+O>4V MU%LN]I;;4&^YV%MN0[WE8F^99LY2%'O+;:BW7.PMMZ'>RO24&]%L+MZA6)Q/\W%O-:6+Q'];+/F%&I&]=^FKYPYR M"^&FI*]\023&8+RXHUTCZ[F!^%4[5K2(HUUIZWF ^/TZ5K2HH]U]ZWE_ "U5 M&\V[W=;G^O%$$BC]JGMNR>?3;!?$U+HVT5072!]0]5ZL9A=(5Q (I09:Q!"* M] ,!5HV.4ST@L6)53:LK2K'=4ZX@?J^3%=4-ZH68TI9D[5IK7DM,3J$&>S.\ M;H?/$Y0OU!!2V,&;CLGYTPAY=7,Q^7R:Q:F>/^KC-&I+_#C5,TI]G.JII3Y. MHW.,'X=4(I[,YJ%T))X(GBS4Q='DL&FVFNJU0GVSTAO3\)F5 M\L T[X.06^)Y./P3\_;O*3],X]%LRLTR3U^FY8YH.@56.F::=F MF\8=,,IC\P?%-KLJ#+_9 /X_U)W33.B'Y\UI.N!<.7;XW=$8V&:;MJ3C2$X> MC<3C>FZ=YMYQ40Z>>022*D?//.*K776*VECTB!M1ZM%8)(SKQ=S/)W[15:'V MC04LN_+HE'HW<&4N[+;_9V$ 3T7X_&%Q6JZ*LI]'E)JK3E7_[<(!77GB.I_H M4U>>N\X_;,Y54?B-OJ;AJN#[QB)VW*@R//.)"G95P/U\H\#=F-HT-^.1EN>P ML4*DYA+#^&D?0)0GL6EN:.-ND(EV<6>!*QD5B=]8/).K0O";??/(C2D[-,^H M7]<+R&\LCM2-*55I[O5*-Z9TIMG765P5?-]8P)>KXNV;?^/,5='VC07'N2K MONDX0C>N3NIK+"SQX!Q_50&**S5I+$#452'T#09@>%'S\WR3QE6A\TW%<[OS M#9EWO9#Y9MYY<=71;+.O:;KR6'9^X5H)%;#2]+MDKG=*VV!TC#J:GZW-3R@\L8CP"EV;"#US] W: MWLR-!JX*=&_B=7)7';TV]>:AJTY>&PKC3\DUF!"U;EE89K3=>FP*<"[G.'_:%,X> MCO.Z8)RYZ2(7@Y 3SS7Y?!O'W]A4G3,<9U-3.'_.<3;;^/Q4/3[OY_A;FJKS M?W"=MP5 -^AW0$C'\9I^_1ZUG7'L6,_ M:;UMTS)@YC$K,[/O$Z:X??#4HS"R@V6Y+Y@E;@P./J#F^ZNK[,'35;(^&.J; MNZN[E5WB@*\K2%H[S#B@(K%BP!_=L+0["/AI T0/V"W8- Z!VRCM!FFO4-).!4B[Q9!VCQ+P0S#.N9[ M,O]6XI]0]PQH[6 M$DJW)_6/\]*WURQMB/ +'.6]C:)@1QWC*.^K(?7OME:/$NB KD'X6*YRW$>! MA=;9[G=N7_;<\453R[ONPR)^M),/X7B84RP ,SU>I_T?SL<':K'>,SNX8K2U MZ_Y-[0NP9EB\GWJ$][PO>T!D0]?P87CU X>?_!B0V54U!I\Q6P5:$9J[:Q$\ MG:F O88V5D)KX>MJ2AU*5X"&K%4:TA^@(6?. @%#2QR_EH1(2U;[!ZKC!U;X M]6>%U)^N!2BC3]:2T0I/?\[FI3]5L[2A#*_F*)]N!B7&43YCUY]*: "DUCU[ M$'==FU"\)UZZ9RD4^?4GBI^X$T35O9NO?J0B\49TS[Y^8'0!RK;K_HU.R_'M MLQM#IQ[!&0405B/"!J5$&W3QW&UE!2>PZ?/X4JF/+W;>LJ#N9#0W_7:S$"!? MA!1B D1%C]K7\??CG$0KV3-'.[P5[#)O_?KRS--\_7KH8.C<#FS)^WA+OFH7 M*BCZS$-S=WT(RKUTSV(NS#NAT#W6!O%9D5J$.JZ4%7:__M[59?E 4ZKV8/.J M]G>-HB!//^ H)VI*9=#3)5QAZLWY=BTM#19/BRX>H9A"+?NY6@Z@L>FL%MVC M38GN>\W(X1<D 8CA6#/B7SU-2;!J]&]H>? MJ-6W(?]\MUK.=[CLO/[P@SC9&>=-?55S7]&4$%^J'!O8-SOO51^Y;IEY?<_##4V*DW M_Z4:H^A+IF3O6\+$HOY@J/?H'IRX>@S+W'7?3JA]2R9]'*OX$:\"SSN#JTC# M=(KEGN3E6JWE:*+;8YG=NJ=/O-PU,R:ZUVC?0CM1*"L5F.M)P#KN7SF-3BL- MRSI.[IOZ-.7E^KNZ2G\[%U:OW7KF[F),[I]Z^$I>I)USWAH=+%8#^Z=N_TJL MTP+XQ'8QLC/<4ZO)G=ZH2/+29]4L;:AX'T=Y1:,HR--VCO(G5A182G7 I-T<6PHH9*%A?R7"8>CIB] M&'BPM-JO+&NELH2XLJP&93G\Y'4M0>O[N2H=^5JH&TK.' PMG[L[E&H1ND*9 M7PMQC550.T)W<(BZ_$@(A:%ISVCKZ 8\WCH8%3[]==@HGN8-!#A-2B$ZA$%!J'ZK.$_X.-E9,F_4#^WVT8EH1=&#_-P'G M]2?_XNA1,-T[84P.4MI/:1]8[9W*:D]HXV[6.Q#C5KG?O[<>X!SME">T9@D- M=_0Z3G+F!+1WE'J%'FX9 *:'#S$QY/U[@+Z99V]]=*K]1.^RMI.+CAZ%E)WH M/9/-=#_4VX:H#_5R!V3QH=YN!X#.,WA>SR*>\/,A/&F )CJ4+J>T!YH<4DWN M-9O 2&NZ\FMS#FWP6;_*9QOP\G_9/[T0U!0W;24.$>=^A MQJ-XJ,.'ZK)#_.&$ID6/GJ M2/&C3TG*0"]O\5DJ!)X#6:/-^3,^H&^H-?4'[0<@^SI_]@URXG2 _@]17=3# M(Z&?($&!=D1,>;Z'?.K0]Q@XX:IEVO23:\VY]R"LN>YZ#S .*[#EM!);3BNQ MY4K!8PV?O)I9D89S$W_[2)S]7%WZ O*\M.RD[I_-XT!,6=]UC]G?<$W9_V8L_RV M6G/6%ZKGK),,HM]>06\AZ"K]4W[,:$_3Y>#BY-. 4WOLSO.1J?SKK.]RGINW@?'ZP5M.6 M^P?-"M6%>#!'I59<^Z;##^*0>4".GSM8P/I]-@N5<;\,;M<'0H/PO9]27!L, M*CLRIJ_)U<35;EL9>//_')[F#\#D.P"3L4A7U)B$==J6\WI=GGCX@'O_">5> M&@LY1Z=?7M UAT=^NV?!,EXE+9[6S;\LLUY/J5WU 0\X,\>-.;0.^0(F'ZRLTKYQ739<]4P.W0AJ. P M8V>+Y!60S$U_RQ3,W.Q/Q6B)A8_!;C3FWU'<=OS0\1?!@N#@[!]\O W/NT0P M N^3KON>W3TWWK)K;OH%C^JLVL)!F?!5_8.0Q*[:#85.;S?[!);N*]$XO!J? M##]6PXBEL.70^_H)CQ$+5Y'3^RP[U-]YR-\;8"R7P5JPVY _TUWTL/QLYU-P M%!G:':@_^H:G'0@O <*+:]/;@/2Z_O:$)6"@BN0B(-E6@]YEC=!#6H=OZ+S% MJ '(+P;R"_\KM_^-->FIP$E+L.3L1.?A_D[6YN449P>[<=,QQ+KN?U%F@NQ. M_=X+ 8$Q&'JFLWUF4^?PXG^K4X9^_#(NQ M)4\##1@_#U3)HQ+J"1^#4=C=+6Z-B18Y6]2G0I>#Q] MK'6T8Y3Y2DV=-7LYN;8&^UM>W#[;.X"QAK/[!@:]W4O7_5OZ6UX ^L+ME7ZA M\HJYZ7*547BPG:?S_)B;_@N3(@4>R29T?;EWV>#<75]LYS%7=[5S41L9OO!A?G\H[]!Y;!]LS4AEV*OM*_/V>,F04*WLG@)",C,8]<=A= M%W8A7<.P4]\:V3=C:52?O4:)J\E9:O*ZU=-K7>*&;QLT T2@AUX8KQ0F06"YXH(JPY.%@C," MWV\L3):=U>7ATF1E+6:L=<9*XS>N6<\Z&*\+;R\$N11')LL5ATL+<_%U&0!6 MH?S"JTJL7,B5QO/J,1>!5F;_JOU$<+BP'\M5AD2U;AT3^?CR/BO[U*"L]V?9Z.Z5/,,G M?:ZB2,49SI2=TGB!ZZ)3 ?ZP=B@] ?42$Z"A*\T*O'XM:QVY$D%?S66CUTL@ MJ_$*5%GDU:_O$!@> 2D U&NG4G2@T= 1A;T3O,V5HE+\H@\) %^= )E-A?^A MTQRA(2C.TOC8 =%FX*0BI8%CD1>13XC'\<+^"N]>/OR&G4LOA>YC6TO[D.ID M@0:[T"]$!3J3!>0-6R*97^MD)B K#WG0T2MU+E?J3=C"N7##O-(RU\G)S#ZG M?* ,U/B-'TZFB(HCJD%=AX$!?0;,=FR60J8B@,CO5W(J)6>B5';B*'5-?E+H M_#4Q9[*(FC99R'&13RJ13_I1)C5^)[7&E/)YIS!6V.OO:6 /F+T)!@<(=C(/ MR@XR6I=#48XX%SD79BX$<(2#;*56TU%N%'O?TRNYE.]#.A-F+P.])-- M*%8G_ 0F-%973NCJ 2K/UG2PU=>4IIR]F0..>"44>'0R%>RZ"A<;5 $]#WAB M?'A7.:R#OH:O_K$H(%^5W 9(U8=VPVB?P);N/0#?V%0928[P>G@-J$\F?=]X MXX"O!2*#OQ2^>@V2Y== #XT5QAE_@12^Z+D[:90'S$Z.8,:K7C4NF^&5#Y>F MQO+C)7Q5'N2VLJ DCE^K%8IN&5'FK"C-65&8LZ)/;D7=Q!1-&U8T;%C1DTE1 MMT%%W085=7FMU$OCY+LJ#Q-L9OS"BI,M\/?Z02 XI(0=9%S9E"'AML%%O=:S M(CPKD X?FFS5NDCQ(OS &2>V+EKH6#7.!F%0C)2FB 988S<2C<79JHM?L^XU MY571&WVS2H?,O2COSP4B,)>-5USLY6B4K8;I< U?+< T)KZ4YC>(SY&0>^F_UFHO_M%RH8$^*!<;*#A#*>&;, MP3O R\ZKH8-!;U&WE[#5_&W'O72"^GT'P[V%[A&N\A00?AR\?NY"Q M5\+VI;6*?CUX@0&W&?#"*GYU>#$[F[YCW/DRH!_Q/>^&?_T&_$8#'C7@MQHP MAGRC,?_A D'_=N/Y^PWX8P;\-P;\=0,^;L G#/C[!OQS \; J0D0VY(VP=\+ MQO,E+3I\C@%?9, Q ^XUX!T&?)T!CQGPVPSXW0;\40/^H@$?QP@"V&0<(OG_ MO?'\40-^QH 7M^KPV0:\UH W&O . RXBW,G8;Q8)?O8:SP\9\'L-^.,&?*\! M'S/@$P;\;83/!#FUBOK_P7C^A $_:\#^(8?P"H"/G<78>43O N-YPH#[#?@Z M WZ+ 7\4X)_\"6/[%POZ?V4\_[H!?\^ GS#@%PRXLTV'SS?@B %O,> A RX; M\&$#?H\!?]R OVW _V3 3QGP]W #_R&IA+B!^_RX8+^2P[,=B$9"[P&AU7= M,FGDC!BP^3S/Q"6 ?/7 U$WH3+_*D&GWE?)5!2Y!F'[W,#.O]V7>G\Z9=B46TVZ!8=K5*4S[61XF;FQFU;=BLJH; M8UG =>U^-%9]\S]K_#I*9O[@ S/NT&9TM1\3 MM^.F+BDD'D79[* >S29]39*YKM\FM6YRI/Y;K=F],,654.3T?5VC*[U M8D&_G\'\O[?$?/?8,M\=2^/?H6F.^@;^53.R?Y-]7+H,Y[%RYIV)\5X/GY!<1+)

]^5)I)>']/WC]=#!><' MT#N#:^'EX),??.ZI(=X'5 Y M1OPM 80+*8U0>BFEV(ZV98*G-E@K[R9X"%,0T##!;\'T++'G0_@C1/].Y ?6 MK/^=Z-U+Z7%*,9B]#9CXGU0.;^EH.UOLS?#Y_Z/T.4I?HO+X%@26/PW2MG/$ M7@R?7T#I:RC%^&0LGR:XE_"VM @^!Q &_7HC/<]1.DKI!.$?H'*'6P1_[Z;G M'Z#T(Y3>2>4_1^6_1/P=I^??I/112A^C\C\E^!>$]Q3QA_'\"U:(-1P^7TKI M,DJ7MPK\E:VBW!J$7PGZ3,]?1^D62@>H_"XJ?WVKX&^4GI)MK_(:H/]RYM8+P^1_!=",. OX_@!Q&^0.QID,[C M"(<8^QG!3U+Z:Z+_6Z+?OE",NS,6"O@<2B^@])*% B^.\"K8HW)E*G< \V$O,H,I&(/WT?./4OI75.ZSA/\E3%=#^PA^B-)'*/U? M"T6[GR#\7U'Z&TI?7"CDNV"1H'O&(I%_#J4K*;UPD2@7)CA)Y2]=).KI7R3J MV8HP['VN(7@(8=C[#!->B=*;"/\@X6,<+-JM#Q+\:2KW!2KW9KZ+RK^) MT@*E;VX7];V[78S'.RC_OQ'>7Q*]OZ;\AS'_$M!#S \S]DM,83'P'.;#)+< M)LH%4<9>L424/Y_2-91>LD34UT?P(*5[*+V>GH\N$?/!/LJ?IO2=E!ZE M(NSR9RC_RY1^G=('J-RW"'Y\B6C/3S&-@5V@_%.4+NH0:6>'P#N;X$2':'=? MAVCWG@[1[CSFQV&<8PIKAW=1^0]2^E%*/T'TODKP"4J_3>GWZ/E/.D2[?T7Y MOZ64+27^EHIR9RX5[78H?RVE44K35&X3P5BLZB3[2?E7=PJY%3N%W-[6*>3V MSDXAMX]V"KWY+*8IQN[!- W]1?B/4?IC2G_6*>I_D>!%IXGT-$K//$T\=TX3 M)<7^2\I^G]&5* MVTX7>-VG"W@%I1><3N/U=!JOE+Z6THU4KI_*;:7\ZS%=S]@(Y9=.%_/.%,&W MGR[F\2\1_C"W4+J?TIOI^6R7Z)[Y'^3^F].>4/DGE?MLMVK/H#.*3TK,I?=49-%\1?,D9-%^= M(=JW&U/8)!7I^22E!RB]A?#?1WAWGR'TX?]B"IN.IZG<\_3\]T2W9YG0JXN7 MD;XM$WBW+Q/R^L R@?=AA/]_^V;Z&V45Q>&I5D4QAM#.=)F93F=K.VW%QL@2 M(B [M0H56>][Y]Q)VM_C:49OA;M@:W?U?U>* MSH74%-G]*:C7X2OPI6TKTO1^G^(?0O< M"7?C=SA%ZW\*^WEX&5['+RV5<]28/-#J>G09K(#34^4_!_U4JN8Y/U7S7.DX MR-;-<;"M&WY;X2[82IZCZ'9X%EZD_1HZR4O=;TRV/=7-J_X*O6KO P? H5[% MC_;J>99A+_?J>=:@%\!%< EQ^[QZGH>Q'Z?_4_1[SMFMIN[BTSGO\^F<3_AT MSO?RZ7P?[%-=4.HXU.Z#/N6KAK5P@4_]OH9> QMA$^T;?7KN7V _ (_"$_B= M]>FY7\'^;\UHO -V2Y-?V'&8U<78>S@]W,;M.,+NL8[%5I?07@OKX2+RO()> MD:9U>0N]+DU]OY^F=?L(;H:7TK3.5_&_@?\MZ6H?G*[U'9.N]9WI6&+G:[K6 M=['C0W9?3F>=X,=P8[K&MSM=ZW88^TEX&I['[R^GK<;^V]'N%%TS."]@IO'F MA^WY9BAN$"R&HS*4IPQ=D:'Y3">^SG&DG;.TOP$;8"/QNXG[EKA#M!_#?A+[ M37;73A[E\7@SU1Z&>;!'IO+US]1^*,$^'I;#:?C5H.LRU4]]IOI9Y5AJX\S4 MNK0X_8C'LP/_O? 0;"/?!?1UF.07;_-39_K53\CIT59'H0O\JN.'^75.5V!_ MQJ]S^G._]L5>O_9%F]./VO>/7_55AU_[HTM ]977<8SU8TP>:^>&XSC[7G3V M\79?<+K,]DU >;<'E'=O0'G; LI[(:"\'>3M$E3>[D'E#065-QY4WKY!Y7T] MJ'FO#6H]USM.L'WO.-'J-JM)DR?9]X&CG7FU6=IGB[.T7Y9G:?YO9BF^(4O/ M83UZ>Y;R[X'?P1^R.*]#>L_FA61?'M(\UX8TSY:0SJT=(ICZ(JSWOR?V@7 $'(E?>5COR6SL=7 A M?!Z_9>B&L.;QC>/C=@Z'-9]?PIK/N;#F<]UQJJU%1'$^&(31B/(6132??MB+ M82DP=X,/X/;\&M%[X_H^1R):%ZG'6T/W1J5 M_[CC.L7G*T M.GA?3/U^#T_$]'MI>TSS_PW^"3MB.I>\JW.4?K?BB'=E*M^/R%N!_S*LX,>B) MQ%425X6]VG&V[4/T:N(:T4W$M1"W&?L>>#"/\:*O$9^48+P)QIM@O-@#"<:+ M+DXP7O1$XBJ)J\)>G6"\Z-7$-:*;B&LA;D]"ZWR0]G9X];_QY8M!H_MM+1?> MC7TPNA@]"<[!/A>]%+T"_0&Z&7T\7^.XF$\=X-KGV#E2P#YUO^U5V_>\8XW- MNT!^LPJT[VL*-)]YCE;+UCO:6?^<8P^['SGVMOK3<8#5SXY#[-QS?-#C>=OQ M,?N>CR?TN\VQK6+?ENQ[W=V]_LLNAV>A;\3=X4X M3Z%X.^SN:'=N"^Q=WXZ/YV?SL___?D';,+K!0#X @ ^ end From ian@cygnus.com Sat Oct 29 20:43:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Sat, 29 Oct 1994 20:43:00 -0000 Subject: gld in gas-941027 is still broken References: <9410292009.AA21496@titanic.nynexst.com> Message-ID: <9410300343.AA17111@tweedledumb.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Sat, 29 Oct 94 16:10:23 EDT > Could somebody please try to give me a reproducible test case for this > problem? Do you have a Linux system? No. I think I have pinpointed where it went wrong. As I suspected, it looks the old bug I reported earlier. Your fix may be a partial one. Yes, this was enough for me to recreate the problem on Solaris. This patch should fix the problem. Ken, this patch should go into the release. Ian Index: elf32-i386.c =================================================================== RCS file: /rel/cvsfiles/devo/bfd/elf32-i386.c,v retrieving revision 1.32 diff -p -r1.32 elf32-i386.c *** elf32-i386.c 1994/10/27 21:25:29 1.32 --- elf32-i386.c 1994/10/30 03:20:54 *************** elf_i386_adjust_dynamic_symbol (info, h) *** 647,657 **** if (s->_raw_size == 0) s->_raw_size += PLT_ENTRY_SIZE; ! /* If we are not generating a shared library, or if the symbol ! is not defined, set the symbol to this location in the .plt. ! This is required to make function pointers compare as equal ! between the normal executable and the shared library. */ ! if (! info->shared || h->root.type != bfd_link_hash_defined) { h->root.u.def.section = s; h->root.u.def.value = s->_raw_size; --- 647,659 ---- if (s->_raw_size == 0) s->_raw_size += PLT_ENTRY_SIZE; ! /* If this symbol is not defined in a regular file, and we are ! not generating a shared library, then set the symbol to this ! location in the .plt. This is required to make function ! pointers compare as equal between the normal executable and ! the shared library. */ ! if (! info->shared ! && (h->elf_link_hash_flags & ELF_LINK_HASH_DEF_REGULAR) == 0) { h->root.u.def.section = s; h->root.u.def.value = s->_raw_size; Index: elf32-sparc.c =================================================================== RCS file: /rel/cvsfiles/devo/bfd/elf32-sparc.c,v retrieving revision 1.25 diff -p -r1.25 elf32-sparc.c *** elf32-sparc.c 1994/10/27 21:25:31 1.25 --- elf32-sparc.c 1994/10/30 03:20:55 *************** elf32_sparc_adjust_dynamic_symbol (info, *** 619,629 **** return false; } ! /* If we are not generating a shared library, or if the symbol ! is not defined, set the symbol to this location in the .plt. ! This is required to make function pointers compare as equal ! between the normal executable and the shared library. */ ! if (! info->shared || h->root.type != bfd_link_hash_defined) { h->root.u.def.section = s; h->root.u.def.value = s->_raw_size; --- 619,631 ---- return false; } ! /* If this symbol is not defined in a regular file, and we are ! not generating a shared library, then set the symbol to this ! location in the .plt. This is required to make function ! pointers compare as equal between the normal executable and ! the shared library. */ ! if (! info->shared ! && (h->elf_link_hash_flags & ELF_LINK_HASH_DEF_REGULAR) == 0) { h->root.u.def.section = s; h->root.u.def.value = s->_raw_size; From hjl@nynexst.com Sat Oct 29 22:59:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Sat, 29 Oct 1994 22:59:00 -0000 Subject: gld in gas-941027 is still broken References: <9410300343.AA17111@tweedledumb.cygnus.com> Message-ID: <9410300559.AA21853@titanic.nynexst.com> > > From: hjl@nynexst.com (H.J. Lu) > Date: Sat, 29 Oct 94 16:10:23 EDT > > > Could somebody please try to give me a reproducible test case for this > > problem? > > Do you have a Linux system? > > No. > > I think I have pinpointed where it went wrong. As I suspected, it looks > the old bug I reported earlier. Your fix may be a partial one. > > Yes, this was enough for me to recreate the problem on Solaris. This > patch should fix the problem. Ken, this patch should go into the > release. > That does the trick. I was wondering if it was possible to test binutils 2.5.2 under i486-linuxelf before it is released to public. Thanks. H.J. From raeburn@cygnus.com Thu Nov 3 16:30:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Thu, 03 Nov 1994 16:30:00 -0000 Subject: binutils-2.5.2 out Message-ID: <9411040030.AA04244@cujo.cygnus.com> The binutils-2.5.2 release was put on prep yesterday. I've just switched the snapshot script so it'll go back to the main development branch rather than the 2.5.x mostly-bugfixes branch. So tomorrow morning's diffs may be a bit bigger than usual. All the important patches from the release should be incorporated by the time the snapshot is made. (Reminder: ftp.cygnus.com:~ftp/private/gas is the place to look for the snapshots. They're put there daily, if the script runs without errors. The script runs at 7AM Pacific time, the snapshot and diffs should be available around 7:30 or so.) From jrs@world.std.com Tue Nov 8 21:03:00 1994 From: jrs@world.std.com (Rick Sladkey) Date: Tue, 08 Nov 1994 21:03:00 -0000 Subject: ldscripts should be renamed ldscripts.new Message-ID: <941309.000259.jrs@world.std.com> When invoked with an emulation, as in: ld -m elf_i386 the GNU linker will look for and use, for example: ldscripts/elf_i386.x relative to the current directory. Since this may be the case when linking the GNU linker with a previous version of itself, it is possible for the old linker not to understand the new linker's command file syntax. I was bitten by this problem when building ELF versions of binutils 2.5.2 when the default emulation is a.out. This is because the specs file for i486-linuxelf invokes ld as described above. Perhaps the search order for emulations should not include the current directory by default (its too late to change old versions :-). To be entirely safe we should also change the bintutils-x.y.z/ld/ldscripts directory to binutils-x.y.z/ld/ldscripts.new. Untested sample patch follows. ----- Tue Nov 8 23:56:45 1994 Rick Sladkey * Makefile.in, configure.in, genscripts.sh: Use ldscripts.new instead of ldscripts to prevent possible old linker conflicts. * ldmain.c (set_scripts_dir): Don't default to the current directory if we can't determine the pathname of the binary. --- binutils-2.5.2/ld/Makefile.in-dist Wed Oct 19 14:36:47 1994 +++ binutils-2.5.2/ld/Makefile.in Tue Nov 8 23:50:07 1994 @@ -222,7 +222,7 @@ LINTSOURCES = $(CFILES) $(GENERATED_CFILES) e*.c -STAGESTUFF = *.o ldscripts/* e*.c +STAGESTUFF = *.o ldscripts.new/* e*.c info: ld.info .PHONY: info @@ -705,7 +705,7 @@ clean: mostlyclean -rm -f $(LD_PROG) configdoc.texi distclean: - -rm -fr Makefile config.status TAGS sysdep.h ldscripts site.exp site.bak \ + -rm -fr Makefile config.status TAGS sysdep.h ldscripts.new site.exp site.bak \ $(STAGESTUFF) ld.?? ld.??s ld.toc ld.aux ld.log ldlex.[qp] \ $(LD_PROG) ld ld1 ld2 ld3 *.o y.output cdtest cdtest.out \ configdoc.texi tmpdir @@ -733,8 +733,8 @@ install: $(INSTALL_XFORM) ld.new $(bindir)/ld $(INSTALL_XFORM1) $(srcdir)/ld.1 $(man1dir)/ld.1 - for f in ldscripts/*; do \ - $(INSTALL_DATA) $$f $(scriptdir)/$$f ; \ + for f in `(cd ldscripts.new && echo *)`; do \ + $(INSTALL_DATA) $$f $(scriptdir)/ldscripts/$$f ; \ done -n=`t='$(program_transform_name)'; echo ld | sed -e "" $$t`; \ rm -f $(tooldir)/bin/ld; \ --- binutils-2.5.2/ld/configure.in-dist Fri Oct 21 18:19:47 1994 +++ binutils-2.5.2/ld/configure.in Tue Nov 8 23:51:34 1994 @@ -175,4 +175,4 @@ rm -f Makefile.tmp mv Makefile.2 Makefile -mkdir ldscripts 2>/dev/null +mkdir ldscripts.new 2>/dev/null --- binutils-2.5.2/ld/genscripts.sh-dist Mon Sep 26 14:00:13 1994 +++ binutils-2.5.2/ld/genscripts.sh Tue Nov 8 23:48:53 1994 @@ -78,30 +78,30 @@ DATA_ALIGNMENT=${DATA_ALIGNMENT_r} DEFAULT_DATA_ALIGNMENT="ALIGN(${SEGMENT_SIZE})" (. ${srcdir}/scripttempl/${SCRIPT_NAME}.sc) | sed -e '/^ *$/d' > \ - ldscripts/${EMULATION_NAME}.xr + ldscripts.new/${EMULATION_NAME}.xr LD_FLAG=u DATA_ALIGNMENT=${DATA_ALIGNMENT_u} CONSTRUCTING=" " (. ${srcdir}/scripttempl/${SCRIPT_NAME}.sc) | sed -e '/^ *$/d' > \ - ldscripts/${EMULATION_NAME}.xu + ldscripts.new/${EMULATION_NAME}.xu LD_FLAG= DATA_ALIGNMENT=${DATA_ALIGNMENT_} RELOCATING=" " (. ${srcdir}/scripttempl/${SCRIPT_NAME}.sc) | sed -e '/^ *$/d' > \ - ldscripts/${EMULATION_NAME}.x + ldscripts.new/${EMULATION_NAME}.x LD_FLAG=n DATA_ALIGNMENT=${DATA_ALIGNMENT_n} TEXT_START_ADDR=${NONPAGED_TEXT_START_ADDR-${TEXT_START_ADDR}} (. ${srcdir}/scripttempl/${SCRIPT_NAME}.sc) | sed -e '/^ *$/d' > \ - ldscripts/${EMULATION_NAME}.xn + ldscripts.new/${EMULATION_NAME}.xn LD_FLAG=N DATA_ALIGNMENT=${DATA_ALIGNMENT_N} (. ${srcdir}/scripttempl/${SCRIPT_NAME}.sc) | sed -e '/^ *$/d' > \ - ldscripts/${EMULATION_NAME}.xbn + ldscripts.new/${EMULATION_NAME}.xbn if test -n "$GENERATE_SHLIB_SCRIPT"; then LD_FLAG=shared @@ -109,7 +109,7 @@ CREATE_SHLIB=" " # Note that TEXT_START_ADDR is set to NONPAGED_TEXT_START_ADDR. (. ${srcdir}/scripttempl/${SCRIPT_NAME}.sc) | sed -e '/^ *$/d' > \ - ldscripts/${EMULATION_NAME}.xs + ldscripts.new/${EMULATION_NAME}.xs fi test "$DEFAULT_EMULATION" = "$EMULATION_NAME" && COMPILE_IN=true --- binutils-2.5.2/ld/ldmain.c-dist Wed Oct 26 01:23:55 1994 +++ binutils-2.5.2/ld/ldmain.c Tue Nov 8 23:55:51 1994 @@ -451,9 +451,9 @@ } else { - dirlen = 1; - dir = (char *) xmalloc (dirlen + 8); - strcpy (dir, "."); + /* Who knows where we came from. We could look ourselves + in the path as this point but even that is unreliable. */ + return; } if (check_for_scripts_dir (dir)) From hjl@nynexst.com Wed Nov 9 07:20:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 09 Nov 1994 07:20:00 -0000 Subject: 16-bit i386 code support in GAS References: <199411091455.HAA25021@schirf.cs.utah.edu> Message-ID: <9411091519.AA29119@titanic.nynexst.com> > > (Sorry if this isn't the right place to ask this question; > I couldn't find any better address in the GAS documentation...) > > How difficult would it be to add a feature to the i386 version > of GAS to allow it to generate 16-bit i386 code? It seems like > it should be a trivial change - just add a directive that inverts > the decision of whether or not to add size prefixes to each > instruction, right? Such a feature would make it possible to > avoid the icky old inverted-syntax, non-cross-compiling as86 and > ld86 programs for writing boot-related code in Mach (Hurd/Lites) > and Linux. > > So, could someone either add this feature, or point me to the > right parts of gas-i386 so I can do it myself, or tell me why > it isn't so simple? > Please take a look at my CC field. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From erich@uruk.org Wed Nov 9 08:05:00 1994 From: erich@uruk.org (Erich Stefan Boleyn) Date: Wed, 09 Nov 1994 08:05:00 -0000 Subject: traditional Intel & Microsoft formats... Message-ID: <199411091607.IAA20118@uruk.org> Greetings. I'm curious if there is an intention of any on these lists to try to be able to (for the i386 processor series): 1) assemble (GAS) and manipulate (BFD) traditional Intel/Microsoft 16-bit code (OMF/NE formats). 2) assemble (GAS) and manipulate (BFD) traditional Intel/Microsoft 32-bit code (OMF/PE formats). "assemble" is reasonably obvious, but by "manipulate", I mean support in the full sense of the BFD library code, so that you could (if possible) link it via the GNU linker with other object file formats, etc. My interest is mostly as targets, not as hosts, and the 16-bit assembly is less interesting to me (though I saw the message posted about others being interested in 16-bit assembly). The goal behind this is that, well, I'd already announced on the BFD list working on a BFD-based dynamic linker... well, my long-term goal would be a flexible binary emulation system using the BFD to handle format and system-dependent structures and symbols. The idea would be that the HURD (and Linux, FreeBSD, too if others cared to port it, though it is easier on the HURD, I think) could then run MS-Windows 3.1, DOS, NT, and Chicago applications regardless of the host processor, and at native speeds if you have a processor with an "Intel 386 emulation mode" in hardware. Well, all that is far off, but some essential parts are the items mentioned above. The BFD already supports the object file formats of other UNIX-like OS's, so that's mostly work on the side of the emulator piece. Anyway, I'm tossing this out for those who might be interested/ are thinking about working on such support/might be now... Thanks for your time. Erich Boleyn -- Erich Stefan Boleyn \__ E-mail (preferred): Mathematician, Software Engineer \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 From artk@congruent.com Wed Nov 9 08:59:00 1994 From: artk@congruent.com (Arthur Kreitman) Date: Wed, 09 Nov 1994 08:59:00 -0000 Subject: traditional Intel & Microsoft formats... References: <199411091607.IAA20118@uruk.org> Message-ID: <9411091639.AA07216@Congruent.COM> > From: Erich Stefan Boleyn > > Greetings. > > I'm curious if there is an intention of any on these lists to > try to be able to (for the i386 processor series): > > 1) assemble (GAS) and manipulate (BFD) traditional Intel/Microsoft > 16-bit code (OMF/NE formats). > > 2) assemble (GAS) and manipulate (BFD) traditional Intel/Microsoft > 32-bit code (OMF/PE formats). You should be aware that the "microsoft" formats are being dropped by microsoft. All future microsoft 32 bit systems are sort of coff based. As far as gas is concerned, only minor changes are required to support microsoft's coff interperation (we've done it, and will be integrating the changes into the latest gas release, and contributing back the changes to the fsf). ar only makes sense if you have ld. For ld to work with Windows NT and Windows95 require more changes then you can imagine. Its at least several man years of work. There's the further problem that much of it must be done by reverse engineering microsoft executables. If gnu cared about market impact, Windows95 support would take the highest priority. I don't think that the gnu community realizes the potential (and the impact) of every pc being a workstation class device with a sophisticated, multitasking, multithreaded operating system. Remember, the windows install base is 70,000,000. From erich@uruk.org Wed Nov 9 09:41:00 1994 From: erich@uruk.org (Erich Stefan Boleyn) Date: Wed, 09 Nov 1994 09:41:00 -0000 Subject: traditional Intel & Microsoft formats... References: <9411091639.AA07216@Congruent.COM> Message-ID: <199411091739.JAA20381@uruk.org> artk@congruent.com (Arthur Kreitman) writes: > You should be aware that the "microsoft" formats are being dropped > by microsoft. All future microsoft 32 bit systems are sort of > coff based. Yes, the PE format (that used by MS-Windows NT) is much like COFF, particularly with an extra set of identifier fields. The suggestion about the other formats is for the point of view of binary emulation and linking with other libraries. > As far as gas is concerned, only minor changes are required to > support microsoft's coff interperation (we've done it, and will > be integrating the changes into the latest gas release, and contributing > back the changes to the fsf). Cool! > ar only makes sense if you have ld. For ld to work with Windows NT > and Windows95 require more changes then you can imagine. Its at > least several man years of work. There's the further problem that > much of it must be done by reverse engineering microsoft executables. Really? The Developer docs that come with the Microsoft "developer's network" aren't too helpful, but there are a couple of articles about them that have given me explicit layout rules. Is this an estimate for targeting, or hosting? I'd be interested in discussing some of it, though I am certainly less expert than others on this list, just interested ;-). > If gnu cared about market impact, Windows95 support would take the > highest priority. I don't think that the gnu community realizes the > potential (and the impact) of every pc being a workstation class device > with a sophisticated, multitasking, multithreaded operating system. > Remember, the windows install base is 70,000,000. I think some (like myself) are aware and interested in this impact. Particularly the ability of a GNU OS to run more executables than the Microsoft OS's (say, almost a superset), would give a lot more weight to the free software community. Also, with MS-Windows NT & Chicago, there isn't going to be binary emulation of 32-bit apps, only 16-bit i386 apps, so far. This project would be much more aimed at running any app on any hardware architecture (in theory ;-). In short, there is probably 3 or 4 big-ticket projects that together could put the free (GNU, I presume ;-) OS's ahead of the commercial ones, IMHO. Anyway, this topic should be taken off-line, it's not the point of the e-mail lists involved. Erich -- Erich Stefan Boleyn \__ E-mail (preferred): Mathematician, Software Engineer \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 From dj@stealth.ctron.com Wed Nov 9 09:56:00 1994 From: dj@stealth.ctron.com (DJ Delorie) Date: Wed, 09 Nov 1994 09:56:00 -0000 Subject: traditional Intel & Microsoft formats... References: <9411091639.AA07216@Congruent.COM> Message-ID: <9411091756.AA21070@delorie> > ar only makes sense if you have ld. For ld to work with Windows NT > and Windows95 require more changes then you can imagine. Its at > least several man years of work. There's the further problem that > much of it must be done by reverse engineering microsoft executables. NT libraries are the same format as unix libraries. In fact, GNU make built on NT already knows about library timestamps! NT objects appear to be straight COFF objects, perhaps with different reloc types or something, but objdump seems to like them. The NT "pe" executable format is coff-ish, but it's NOT coff. At least, not enough to use our standard tools on it. I've been reverse engineering it and working on determining the feasability of writing an NT linker. As for ld, it's probably almost easier to do this from scratch, as the NT linker needs to know a LOT about dll's and resources. I'm guessing that an NT-specific linker is 2/3 this stuff and 1/3 actual linking. It would be more work merging gld's stuff to the NT extensions than just writing an NT-specific linker from scratch, although you'd still want to use BFD to load objects. From raeburn@cygnus.com Wed Nov 9 09:57:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 09 Nov 1994 09:57:00 -0000 Subject: traditional Intel & Microsoft formats... References: <9411091639.AA07216@Congruent.COM> Message-ID: <9411091757.AA00676@cujo.cygnus.com> Date: Wed, 9 Nov 94 11:39:23 est From: artk@congruent.com (Arthur Kreitman) > From: Erich Stefan Boleyn > > Greetings. > > I'm curious if there is an intention of any on these lists to > try to be able to (for the i386 processor series): > > 1) assemble (GAS) and manipulate (BFD) traditional Intel/Microsoft > 16-bit code (OMF/NE formats). > > 2) assemble (GAS) and manipulate (BFD) traditional Intel/Microsoft > 32-bit code (OMF/PE formats). How much would supporting those Microsoft formats buy us over what DJ Delorie has already done with DJGPP and GO32? (Please excuse my cluelessness, I've never done development on DOS or Windows and know next to nothing about their file formats &c.) As far as gas is concerned, only minor changes are required to support microsoft's coff interperation (we've done it, and will be integrating the changes into the latest gas release, and contributing back the changes to the fsf). Cool. I look forward to merging it in... ar only makes sense if you have ld. For ld to work with Windows NT and Windows95 require more changes then you can imagine. Its at least several man years of work. There's the further problem that much of it must be done by reverse engineering microsoft executables. Hm. I could believe it might be significantly different from the formats we use on other systems, but man-years of work? Is it *that* different? The primary goal would be to produce working executables. Using object and library formats compatible with the native tools would be a plus, but not absolutely necessary, especially if the vendor is anal about releasing information. And given that this vendor is Microsoft, I think we should be especially paranoid about not violating license terms &c, when trying to do any of that reverse engineering... We don't want to make Cygnus or the FSF an easy lawsuit target. If gnu cared about market impact, Windows95 support would take the highest priority. I don't think that the gnu community realizes the potential (and the impact) of every pc being a workstation class device with a sophisticated, multitasking, multithreaded operating system. Remember, the windows install base is 70,000,000. I agree it's a huge market. But I'm always skeptical about any numbers quoted. My laptop is probably counted as one of those 70M systems, because it was shipped to me with Windows, but that doesn't mean I reinstalled it after repartitioning the disk... So call it an install base of 69,999,999; it's still big. :-) From dj@stealth.ctron.com Wed Nov 9 10:33:00 1994 From: dj@stealth.ctron.com (DJ Delorie) Date: Wed, 09 Nov 1994 10:33:00 -0000 Subject: traditional Intel & Microsoft formats... References: <9411091757.AA00676@cujo.cygnus.com> Message-ID: <9411091835.AA22133@delorie> > How much would supporting those Microsoft formats buy us over what > DJ Delorie has already done with DJGPP and GO32? (Please excuse my > cluelessness, I've never done development on DOS or Windows and know > next to nothing about their file formats &c.) It's like having a Unix compiler that can't produce X programs. Djgpp can build text-based programs, but can't build graphics programs (Win32s or NT) because it can't generate the executable (it's different than a command-line executable). > Hm. I could believe it might be significantly different from the > formats we use on other systems, but man-years of work? Is it > *that* different? Well, I think man-months or less, assuming you already know the file formats and basic linking theory. This doesn't include the resource compiler that you'll need to write to go along with the library, which is probably another few man-months. > The primary goal would be to produce working executables. Using > object and library formats compatible with the native tools would be > a plus, but not absolutely necessary, especially if the vendor is > anal about releasing information. The obj and lib is straight unix COFF. It's just the executable that's weird. From raeburn@cygnus.com Wed Nov 9 10:49:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 09 Nov 1994 10:49:00 -0000 Subject: 16-bit i386 code support in GAS References: <9411091519.AA29119@titanic.nynexst.com> Message-ID: <9411091849.AA00797@cujo.cygnus.com> > (Sorry if this isn't the right place to ask this question; > I couldn't find any better address in the GAS documentation...) Probably bug-gnu-utils is the best publicly advertised place. The gas2 list at Cygnus is a less advertised one, intended mainly for developers. > How difficult would it be to add a feature to the i386 version > of GAS to allow it to generate 16-bit i386 code? It seems like > it should be a trivial change - just add a directive that inverts > the decision of whether or not to add size prefixes to each > instruction, right? Such a feature would make it possible to > avoid the icky old inverted-syntax, non-cross-compiling as86 and > ld86 programs for writing boot-related code in Mach (Hurd/Lites) > and Linux. > > So, could someone either add this feature, or point me to the > right parts of gas-i386 so I can do it myself, or tell me why > it isn't so simple? No "decision" is being made, at least at run time. The opcode table has the prefixes already present for the 16-bit versions of instructions that need them and absent for the 32-bit versions. So "addw" would be a two-byte instruction and "addl" a one-byte instruction. One way to approach this might be to make the opcode table indicate which operand size an instruction indicates, independently of the value of the opcode itself, and add the prefix when a larger-than-byte operand size is needed and it doesn't match the "current" mode. Another is to check for 16-bit mode and strip off a size prefix if present, or add one if the instruction would need one, using some kludge to figure out whether an instruction's operands are 8- or 32-bit sized. I'd like to see this work done (but cleanly!), for precisely the reasons you mention. Anyone doing kernel or stand-alone program development currently has to have as86 and ld86 as well as the GNU tools for the 32-bit code. That's just silly. For consistent results, you'd probably want the disassembler to work in 16-bit mode too. Un(?)fortunately, they use separate copies of the opcode table, laid out in different formats. I'd also like to have a general overhaul of the i386 back end done. It's got lots of other problems, especially some dealing with segment registers. I've been thinking about doing some of this work myself, but if you've got a strong overall understanding of the quirks of the i386 instruction set, and a lot of spare time you want to donate, let me know... From artk@congruent.com Wed Nov 9 10:49:00 1994 From: artk@congruent.com (Arthur Kreitman) Date: Wed, 09 Nov 1994 10:49:00 -0000 Subject: traditional Intel & Microsoft formats... References: <9411091757.AA00676@cujo.cygnus.com> Message-ID: <9411091827.AA08130@Congruent.COM> > How much would supporting those Microsoft formats buy us over what DJ > Delorie has already done with DJGPP and GO32? (Please excuse my > cluelessness, I've never done development on DOS or Windows and know next > to nothing about their file formats &c.) This would be for native support. Remember, what go32 does is provide a 32 bit environment. > Hm. I could believe it might be significantly different from the formats > we use on other systems, but man-years of work? Is it *that* different? Its different enough to require two or three people working for six or nine months. That's just the binutils side. That doesn't include MS's special debugging formats, or the gcc changes needed to really fit in to MS's world, or doing gdb. > The primary goal would be to produce working executables. Using object > and library formats compatible with the native tools would be a plus, but > not absolutely necessary, especially if the vendor is anal about releasing > information. You need to link against microsoft libraries to be able to create an executable that runs. > And given that this vendor is Microsoft, I think we should be especially > paranoid about not violating license terms &c, when trying to do any of > that reverse engineering... We don't want to make Cygnus or the FSF an > easy lawsuit target. Reverse engineering isn't a problem. Even Microsoft know's that its not enforcable. However, it is a ton of work. I've been trying to get unencumbered specs (not marked Microsoft Confidential). > I agree it's a huge market. But I'm always skeptical about any numbers Prime didn't believe the impact of workstations. From hjl@nynexst.com Wed Nov 9 10:59:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 09 Nov 1994 10:59:00 -0000 Subject: A serious gas/gld bug References: <199411082146.NAA14605@cygnus.com> Message-ID: <9411091856.AA00287@titanic.nynexst.com> > > >>>>> H J Lu writes: > > >> >>>>> H J Lu writes: > > >> > crtstuff.c is responsible for the .fini section which is registered > >> > via atexit(). The .fini section contains your crtstuff.c messed up > >> > 'i' after the .fini section returns. > > >> I don't understand how this could happen. Can't you step through the call > > > I can guess 'i' is in a register. The weird things we did in crtstuff > > as well as the linker did didn't help much. The rfg's approach is very > > reasonable. It uses a complete function which is combined from > > two parts. > > If 'i' is in a register that is going to be clobbered, it should be > reloaded after the call. My approach is more in line with existing > practice -- crt[in].o provide a function prologue and epilogue, why don't > we use them? > > >> to _fini and see why 'i' is being clobbered? > It is gas/gld who clobbered ebx which is used by 'i'. Here is the test case. Jason, could you please verify gas/gld on x86 UnixWare? I am curious why you didn't see problem on x86 UnixWare. It seems that gas/gld cannot handle .section .fini/.init right. As you can see from objdump --disassemble, fini_dummy: .section .fini call __do_global_dtors_aux becomes call __do_global_dtors_aux+2 At the final linking, a.out.asm, you can see it become call __do_global_dtors_aux+1 Similar thing also happens to __do_global_ctors_aux. That screwed up everything since it skip the very importmant push %ebx H.J. --- begin 644 binutils-bug.tar.gz M'XL( .,9P2X ^U[IQ\>9^.L$V\V MB4PVBAU K*#I1[4]9F9Z--V3]49(!)D#4A3)AQP0XL A!_X"A,1Q)<[\&7M% MXKC(5/6[JKH]8^,9=K/U2>.>ZOI]]?BJOE=[NN17]YWH53!7@KIB&08$$*JF M99(K['3TY)J1 J%AFHJFZKJNX;)E:": QGR'E=(DBITQA.#@L'\FKA>=7?^$ MDIRLOR.'DUAVHL%<^E 5Q=3UQO6W3$O+U[]CF2J&X:L&H#*7T3#TE*^_E"S] M1K(00:^/8!".!TX,43_H:&N]SKHI2=N]R(DB-'#[]V$8P AY<2\<0KDW[,4; MDK*N8%I7X V;W-B$GM/O$YW&]RVDJOB^[8?V?C]TG;[MQ>$XLIW)T75U,VVO7%L^Y/!X+YM;\)1."(#>!EY1SE* M95&X>S@(/TYQT:C],G(+<(<#=UBP4X -#FQ4P-X1!OL%V.+ UB9T?#\%^S2X MRX&[S6"7 [LLN!RSSX'] HPEKU?!#B?@ZZJ"93R)#OJDZ1)8(V.U BSDZV@\ M4*L BU5S^(50RY7 UU?IT:ZSL/7JW"ENLH.+P052Z$WS/??NI(C QX95-O5 M_.HP7)V#:WKC,%Q^E;5N[3!O74JX_?X\7?TFGZZR"KZX2?1Z28LG]SKPWQ47K47GQ^:7KNM?'Y;Z2IE9#0] MW:,1BH/1Q+N7VQ7?Y#E-=I]'HQS-ST'OTOUT$B-G]WNNEYJZG!7QK*B82[*& MV!+J^4(B?EL;';HG!>&>'&SGRDX0O[N-]<;9('ZS&"[51]5D9TP!OR:F0C.I M.L8,G-ZPX.'MGVG4K6/ KX9ITK-6R7ZMSCG@9V&Z%?M>:%'@\4!O$P[#$=&B M',1KO.ES('XM3<2!>(M@!@P(!SWPAA\.457UU8H*J(J1 HC#X/5=5:RL&KN( MPT'2,M-P#NQFP"XW!">K<;@:-ZMQN1HOJV'EIRI^5L,*35505L-*2E6"K(83 MCXIGL>]YFNV%@Q$./'RYQE>H;/C@5\*'JB,@"F;H[2JGV<1)=MU@5!CC@CMG M])L8\;P/$2P70O,:!^?EBZ,&31A.(IK2V%QIM*^1*5;MM:IIC6Q:H5\_K#+H MC0PZ:U *<6I6(Y-%RS,=8<[F-++A/7DX1!5IGC5]:0:)\W9!U1K7DOCZ+-;, ML:@1RVUKK7%556Y9.WA> 3:SJ:DH>Y7DA"0I#92)=NT0XY?%8BZ9B=,GXG0R M<6)0D(."$N3W\1X.$G+=BO1Q\,ULC3+XQCO#1U[NT'-XIPF.W=-AOU@KC#2: MD,:F-!T"PS$9>3(_Y0B[QO6.3P_<;6)V2V;WH(T_.8??Q$%KK878/>1Q6HM; M"YHPS/+BYI3&YIJU%K,U+DVMUF(&O9&!TMIT(P1>J;R8UVKDI90WXPW:U&*P M.NPUZ? 484@SR)_388QO7%E6AS$6-6(1MW"-:\SJL(6(#I-(B=5AHK]-62K1 M^8V,GT1--KG!1%-GN;>SXBB&>_RR"6C)YZM-:Q3L@BB=!('NK4DO^&(TCO(E;JXHJ*^JJ M1 =J&U+R" ;CG'YO?XA7%7^-[X]0"]9NYO;-8#),M$*JK=^06FGDEVA]*[&9 M5VU[>^_.A_;.N[M[))]*S5DKL557E393*[6PB9=W.L60=$G>,3:RMJK6MY7H M7VI86XG5O,JVG1F_%K%LN!7<4H>,D!BF%(BUL&[NI9.O3+B\N2&]M/7!!QB= M68A68B&DE]Z_8R?WDX'5RB=G3(1>X,DH9-^)G+3>Z'PWVXIG*] M^>?M;;NVM^WZWEIRST?#N+5Z^ZVW-N"UV^]_] K49%/&>_G_K7&/%]'V?WVK/WMM[1TZ?MA\W;]_9PQR47TA0>IIMM=.!Y XA MNSO5R42]LYU,MU/LOS7EI:*\A)8!DN5^H-GTJN>_+T&O@&^3O'O_GT% M_SU^G?P%\0LGGRV?_O/XPX-M7BK8!2!P*OC[\S^GI*;Z> M9@38O8VW9G1_$#LNOL;C]'J0?R,6!,ACU,^^$>T'LAM%0!Z&,0+)HXD4D'Y+ M# %(E127PL$ *U2=/*IS7P'_.GV>JEL"WZN4G\%EE:IO@3?P%5;JWZ/JE\%/ MJ?(54"5:\J2\S)17F/*S3/DYILRVWV+*V'Z4CA_07A[4/LL!U#,*4#YN I0I M!M2#$S [$?D2*>0SN8D_/ZC4?RN[DGO5V?QA):U[/N,GDB*SOYZ5 WNN_QY]OUXSOQ4I;A/Z(/UX-CER? 4P%_KP TG59R:XM MICW"%-2T1]I:RF1!KDG[M#H(N@1B__\SCP!@FO_75<[_6ZKP_PNA:?[_;U/\ M_X]W'Y++W=\^(,KY^3$I?#Y:.3Y: ?$W3TY./GL.QP/_6#G>)/' +QZ<4/"[ M#^IC@T=?C=C@-E7? A^1.5;J?TG5+X,A59X6&RP^5JC&.HD?/G?L4)=?SC>B MJ(LGWF#G ?AXXB$6WW?!]'CB4Z:_IGBB"*)/X'9 MXHD_-^#8>.)+,%L\\5/0T'Y MI)ESUN633# K733W_^(KDOM_^13F_C[#EMT6N?^"B/[_[WP"@ OD_[HB?O^S M$)I/_O_H^.C1:27_?W2\>7K^_+^@)S0VH//_*V /T/F_3=4O@P%5GA8;/#'Y MOS9Y3B'=#QG'^>0TDS' M.:3-G?LXAY3M',$'C_#7&R! ^A)9%^&Q;G7+:I$?=BF+8KG=VN*DF[O4&OCS=, M?( ;A$X_"K&01B,TQ,(+ZW_Z*L,](M;(&Z-[R(>3D80^1N/[20NR)+TCOR>+ M-Q,$"1(D2) @08($"1(D2) @08($"1(D2) @08($"1(D2) @08($78S^"WT% &IXH > end From baford@schirf.cs.utah.edu Wed Nov 9 11:06:00 1994 From: baford@schirf.cs.utah.edu (Bryan Ford) Date: Wed, 09 Nov 1994 11:06:00 -0000 Subject: 16-bit i386 code support in GAS References: <9411091849.AA00797@cujo.cygnus.com> Message-ID: <199411091906.MAA25430@schirf.cs.utah.edu> > > (Sorry if this isn't the right place to ask this question; > > I couldn't find any better address in the GAS documentation...) > >Probably bug-gnu-utils is the best publicly advertised place. The gas2 >list at Cygnus is a less advertised one, intended mainly for developers. I've sent messages (including bug _fixes_, not just reports) to bug-gnu-utils several times before, and have never gotten any kind of response whatsoever - my mail just disappears into the void. :-) >[...16 bit support...] >I'd like to see this work done (but cleanly!), for precisely the reasons >you mention. Anyone doing kernel or stand-alone program development >currently has to have as86 and ld86 as well as the GNU tools for the >32-bit code. That's just silly. > >I'd also like to have a general overhaul of the i386 back end done. It's >got lots of other problems, especially some dealing with segment >registers. I've been thinking about doing some of this work myself, but >if you've got a strong overall understanding of the quirks of the i386 >instruction set, and a lot of spare time you want to donate, let me >know... I have a pretty good understanding of the 386 instruction set, but no experience in the GAS source code, and practically no free time. I was thinking of adding the 16-bit support myself if it was fairly trivial, but it sounds as if it isn't. I still might be able to, but not any time soon... Thanks... Bryan From hjl@nynexst.com Wed Nov 9 11:16:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 09 Nov 1994 11:16:00 -0000 Subject: gas/gld cannot handle section switches Message-ID: <9411091915.AA00347@titanic.nynexst.com> As you can see, gas mishandled it. I think gld may have a simliar bug. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com --- # objdump --disassemble foo.o foo.o: file format elf32-i386 Disassembly of section .text: 00000000 call 00000002 00000005 Address 0x6 is out of bounds. Disassembly of section .fini: 00000000 ret 00000001 nop 00000002 nop 00000003 nop 00000004 nop 00000005 nop 00000006 nop 00000007 nop 00000008 nop 00000009 nop 0000000a nop 0000000b nop 0000000c nop 0000000d nop 0000000e nop 0000000f Address 0x10 is out of bounds. --- .section .fini .align 16 .type bar,@function bar: ret .Lfe1: .size bar,.Lfe1-bar .align 16 .type foo,@function .text foo: call bar ret .Lfe2: .size foo,.Lfe2-foo From erich@uruk.org Wed Nov 9 11:56:00 1994 From: erich@uruk.org (Erich Stefan Boleyn) Date: Wed, 09 Nov 1994 11:56:00 -0000 Subject: traditional Intel & Microsoft formats... References: <9411091835.AA22133@delorie> Message-ID: <199411091958.LAA20778@uruk.org> > It's like having a Unix compiler that can't produce X programs. Djgpp > can build text-based programs, but can't build graphics programs > (Win32s or NT) because it can't generate the executable (it's > different than a command-line executable). I personally think this part of Misrosoft's strategy is a pain... I'm glad this is being worked on! (I already saw the "winnt" preliminary configuration for GCC 2.6.1) > Well, I think man-months or less, assuming you already know the file > formats and basic linking theory. This doesn't include the resource > compiler that you'll need to write to go along with the library, which > is probably another few man-months. Much different estimate here! Are you/others already planning this? > The obj and lib is straight unix COFF. It's just the executable > that's weird. That's the impression I received as well from the docs I've read. The object and library formats being straight COFF certainly will simplify things. Erich -- Erich Stefan Boleyn \__ E-mail (preferred): Mathematician, Software Engineer \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 From erich@uruk.org Wed Nov 9 12:02:00 1994 From: erich@uruk.org (Erich Stefan Boleyn) Date: Wed, 09 Nov 1994 12:02:00 -0000 Subject: traditional Intel & Microsoft formats... References: <9411091827.AA08130@Congruent.COM> Message-ID: <199411092004.MAA20794@uruk.org> > > Hm. I could believe it might be significantly different from the formats > > we use on other systems, but man-years of work? Is it *that* different? > Its different enough to require two or three people working for six or > nine months. That's just the binutils side. That doesn't include MS's > special debugging formats, or the gcc changes needed to really fit in > to MS's world, or doing gdb. The debugging format and GDB would certainly add a bunch of extra work, but I really don't know how much. > You need to link against microsoft libraries to be able to create an > executable that runs. They're COFF, so it shouldn't be too much problem there. > > I agree it's a huge market. But I'm always skeptical about any numbers > Prime didn't believe the impact of workstations. ??? We're not workstation vendors (at least not myself, and I doubt that Cygnus and the others on the list are). What does this really matter ? PC's or not don't bother me, and Microsoft hasn't just automatically pushed everything else out. Erich -- Erich Stefan Boleyn \__ E-mail (preferred): Mathematician, Software Engineer \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 From jason@cygnus.com Wed Nov 9 15:07:00 1994 From: jason@cygnus.com (Jason Merrill) Date: Wed, 09 Nov 1994 15:07:00 -0000 Subject: A serious gas/gld bug References: <9411091856.AA00287@titanic.nynexst.com> Message-ID: <199411092307.PAA10720@cygnus.com> >>>>> H J Lu writes: > It is gas/gld who clobbered ebx which is used by 'i'. Here is the test > case. Jason, could you please verify gas/gld on x86 UnixWare? I am > curious why you didn't see problem on x86 UnixWare. They seem to work properly on x86 Unixware. > It seems that gas/gld cannot handle > .section .fini/.init > right. As you can see from objdump --disassemble, > fini_dummy: > .section .fini > call __do_global_dtors_aux > becomes > call __do_global_dtors_aux+2 Hmm. On UnixWare, it becomes Disassembly of section .fini: call 00000001 <__DTOR_LIST__+1> which I assume is a reference to the first relocation entry for .fini: RELOCATION RECORDS FOR [.fini]: OFFSET TYPE VALUE 00000001 R_386_PLT32 __do_global_dtors_aux Are there two relocation entries for .fini under Linux-ELF? > At the final linking, a.out.asm, you can see it become > call __do_global_dtors_aux+1 On UnixWare, the link creating the shared library fixes up the reference to be an actual call to the function. It does not seem to be off by one. objdump -xd libg++.so ... SYMBOL TABLE: ... 000672f4 l .text __do_global_ctors_aux ... 0001eadc l .text __do_global_dtors_aux ... Disassembly of section .init: 0001cc14 <_init> call 000672f4 <__do_global_ctors_aux> 0001cc19 <_init+5> ret $0x0 ... Disassembly of section .fini: 00067350 <_fini> call 0001eadc <__do_global_dtors_aux> 00067355 <_fini+5> ret $0x0 ... > Similar thing also happens to __do_global_ctors_aux. That screwed up > everything since it skip the very importmant > push %ebx Did this happen when you were stepping through at runtime? Jason From hjl@nynexst.com Wed Nov 9 15:10:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 09 Nov 1994 15:10:00 -0000 Subject: A gas bug Message-ID: <9411092309.AA01279@titanic.nynexst.com> Hi, I have verified that it indeed is a gas bug which prevents the ELF support in gcc working properly. As you can see, foo.s is mis-assembled as 00000000 call 00000002 with 0000 e8fdffff ffc3 ...... I patched .o file by hand to 00000000 call 00000001 with 0000 e8fcffff ffc3 ...... It seems ok. I am not very familiar with gas and don't know hard to fix this bug. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com --- foo.o: file format elf32-i386 Disassembly of section .text: 00000000 Address 0x1 is out of bounds. Disassembly of section .fini: 00000000 call 00000002 00000005 Address 0x6 is out of bounds. foo.o: file format elf32-i386 Contents of section .text: 0000 c3 . Contents of section .data: Contents of section .fini: 0000 e8fdffff ffc3 ...... ---- .text .type bar,@function bar: ret .section .fini .type foo,@function foo: call bar ret From hjl@nynexst.com Wed Nov 9 16:36:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 09 Nov 1994 16:36:00 -0000 Subject: A very strange/serious gas/gld bug References: <199411100011.QAA17746@cygnus.com> Message-ID: <9411100035.AA01521@titanic.nynexst.com> > Yes. Here are the assembly file I get, and the object file I get from > compiling it with './as crtstuff.s'. > The bug is very strange :-(. Please try those two files. H.J. ----foo.s--- .text .align 4 .type __do_global_dtors_aux,@function __do_global_dtors_aux: ret .align 4 .type fini_dummy,@function fini_dummy: .section .fini call __do_global_dtors_aux .text ----bar.s--- .text .align 4 .type __do_global_dtors_aux,@function __do_global_dtors_aux: ret .align 4 .type fini_dummy,@function fini_dummy: .section .fini call __do_global_dtors_aux@PLT .text ret From jason@cygnus.com Wed Nov 9 16:45:00 1994 From: jason@cygnus.com (Jason Merrill) Date: Wed, 09 Nov 1994 16:45:00 -0000 Subject: A very strange/serious gas/gld bug References: <9411100035.AA01521@titanic.nynexst.com> Message-ID: <199411100045.QAA21315@cygnus.com> >>>>> H J Lu writes: > The bug is very strange :-(. Please try those two files. > ----foo.s--- > .text > .align 4 > .type __do_global_dtors_aux,@function > __do_global_dtors_aux: > ret > .align 4 > .type fini_dummy,@function > fini_dummy: > .section .fini > call __do_global_dtors_aux > .text This one is compiled incorrectly (call 00000002): begin 664 foo.o M?T5,1@$! 0 $ P ! 0 0 #0 M "@ "0 & ,.0D)#H_?___P N ----bar.s--- > .text > .align 4 > .type __do_global_dtors_aux,@function > __do_global_dtors_aux: > ret > .align 4 > .type fini_dummy,@function > fini_dummy: > .section .fini > call __do_global_dtors_aux@PLT > .text > ret This one is compiled correctly (call 00000001): begin 664 bar.o M?T5,1@$! 0 $ P ! X 0 #0 M "@ "0 & ,.0D)## Z/S___\ +G-Y;71A8@ N0!?1TQ/0D%,7T]&1E-%5%]404),15\ M !L ! M!@ T !0 ! A 0 , M / 0 )P @ # #P M $ "P ! !@ \ !0 M 0 R "0 H ( @ ' M! 0 ( $0 , $$ \ ! M $ " " @ @ ' ! ! M ) P $ #@ $ 0 % 0! end From jrs@world.std.com Wed Nov 9 19:22:00 1994 From: jrs@world.std.com (Rick Sladkey) Date: Wed, 09 Nov 1994 19:22:00 -0000 Subject: 16-bit i386 code support in GAS References: <9411091519.AA29119@titanic.nynexst.com> <9411091849.AA00797@cujo.cygnus.com> Message-ID: <941309.222147.jrs@world.std.com> > From: Ken Raeburn > Subject: Re: 16-bit i386 code support in GAS > Date: Wed, 9 Nov 1994 13:49:07 -0500 > For consistent results, you'd probably want the disassembler to work > in 16-bit mode too. Un(?)fortunately, they use separate copies of > the opcode table, laid out in different formats. Here is i386 16-bit disassembler code which was started by Eric Youngdale and finished by myself. We never got around to submitting it. This code was originally motivated by Wine, the Windows emulator. These changes are relative to an old version of gdb but they patch without problems into the latest sources. ----- Wed Nov 9 22:05:40 1994 Rick Sladkey * bfd/archures.c (bfd_architecture docs): add bfd_mach_i286 and bfd_mach_i386 processors with family. * bfd/bfd-in2.h (bfd_architecture): Likewise. Wed Nov 9 22:05:40 1994 Rick Sladkey * opcodes/i386-dis.c (names_rmw): New vector to decode mod/rm fields unique to 16-bit mode instructions. (machine): New static variable specifying processor. (print_insn_i286_or_i386): Renamed from print_insn_i386. Remove hard-coding of 32-bit code and add special cases for 16-bit mode mod/rm fields. (print_insn_i286, print_insn_i386): New external entry points. * opcodes/disassemble.c (disassembler): Add i286 check. *** gdb-940601/bfd/archures.c-dist Tue Mar 15 10:08:54 1994 --- gdb-940601/bfd/archures.c Sat Jun 4 20:42:25 1994 *************** *** 86,91 **** --- 86,93 ---- . bfd_arch_sparc, {* SPARC *} . bfd_arch_mips, {* MIPS Rxxxx *} . bfd_arch_i386, {* Intel 386 *} + .#define bfd_mach_i286 1 + .#define bfd_mach_i386 2 . bfd_arch_we32k, {* AT&T WE32xxx *} . bfd_arch_tahoe, {* CCI/Harris Tahoe *} . bfd_arch_i860, {* Intel 860 *} *** gdb-940601/bfd/bfd-in2.h-dist Wed Jun 1 17:10:34 1994 --- gdb-940601/bfd/bfd-in2.h Sat Jun 4 20:42:26 1994 *************** *** 959,964 **** --- 959,966 ---- bfd_arch_sparc, /* SPARC */ bfd_arch_mips, /* MIPS Rxxxx */ bfd_arch_i386, /* Intel 386 */ + #define bfd_mach_i286 1 + #define bfd_mach_i386 2 bfd_arch_we32k, /* AT&T WE32xxx */ bfd_arch_tahoe, /* CCI/Harris Tahoe */ bfd_arch_i860, /* Intel 860 */ *** gdb-940601/opcodes/i386-dis.c-dist Wed Mar 30 04:17:53 1994 --- gdb-940601/opcodes/i386-dis.c Sat Jun 4 20:42:26 1994 *************** *** 703,708 **** --- 703,711 ---- static char *names_seg[] = { "%es","%cs","%ss","%ds","%fs","%gs","%?","%?", }; + static char *names_rmw[] = { + "%bx,%si","%bx,%di","%bp,%si","%bp,%di","%si","%di","%bp","%bx", + }; struct dis386 grps[][8] = { /* GRP1b */ *************** *** 950,957 **** } } static int dflag; ! static int aflag; static char op1out[100], op2out[100], op3out[100]; static int op_address[3], op_ad, op_index[3]; --- 953,961 ---- } } + static int machine; static int dflag; ! static int aflag; static char op1out[100], op2out[100], op3out[100]; static int op_address[3], op_ad, op_index[3]; *************** *** 966,974 **** * be used to print the target address if this is a relative jump or call * The function returns the length of this instruction in bytes. */ ! ! int ! print_insn_i386 (pc, info) bfd_vma pc; disassemble_info *info; { --- 970,977 ---- * be used to print the target address if this is a relative jump or call * The function returns the length of this instruction in bytes. */ ! static int ! print_insn_i286_or_i386 (pc, info) bfd_vma pc; disassemble_info *info; { *************** *** 1025,1034 **** return (1); } - /* these would be initialized to 0 if disassembling for 8086 or 286 */ - dflag = 1; - aflag = 1; - if (prefixes & PREFIX_DATA) dflag ^= 1; --- 1028,1033 ---- *************** *** 1140,1145 **** --- 1139,1166 ---- return (codep - inbuf); } + int + print_insn_i286 (pc, info) + bfd_vma pc; + disassemble_info *info; + { + machine = 286; + dflag = 0; + aflag = 0; + return print_insn_i286_or_i386 (pc, info); + } + + int + print_insn_i386 (pc, info) + bfd_vma pc; + disassemble_info *info; + { + machine = 386; + dflag = 1; + aflag = 1; + return print_insn_i286_or_i386 (pc, info, 36); + } + char *float_mem[] = { /* d8 */ "fadds", *************** *** 1539,1544 **** --- 1560,1595 ---- } append_prefix (); + + if (machine == 286) + { + if (mod == 0 && rm == 6) + { + sprintf (scratchbuf, "0x%04.4x", get16 ()); + oappend (scratchbuf); + return 0; + } + + if (mod == 1) + { + FETCH_DATA (the_info, codep + 1); + disp = *(char *)codep++; + } + else if (mod == 2) + disp = get16 (); + else + disp = 0; + if (disp != 0) + { + sprintf (scratchbuf, "0x%x", disp & 0xffff); + oappend (scratchbuf); + } + + sprintf (scratchbuf, "(%s)", names_rmw[rm]); + oappend (scratchbuf); + return 0; + } + if (rm == 4) { havesib = 1; *** gdb-940601/opcodes/disassemble.c-dist Thu Apr 28 19:02:53 1994 --- gdb-940601/opcodes/disassemble.c Sat Jun 4 20:42:26 1994 *************** *** 78,84 **** #endif #ifdef ARCH_i386 case bfd_arch_i386: ! disassemble = print_insn_i386; break; #endif #ifdef ARCH_i960 --- 78,87 ---- #endif #ifdef ARCH_i386 case bfd_arch_i386: ! if (bfd_get_mach(abfd) == bfd_mach_i286) ! disassemble = print_insn_i286; ! else ! disassemble = print_insn_i386; break; #endif #ifdef ARCH_i960 *** gdb-940601/include/dis-asm.h-dist Thu Apr 28 19:07:33 1994 --- gdb-940601/include/dis-asm.h Sat Jun 4 20:42:26 1994 *************** *** 96,101 **** --- 96,102 ---- extern int print_insn_big_mips PARAMS ((bfd_vma, disassemble_info*)); extern int print_insn_little_mips PARAMS ((bfd_vma, disassemble_info*)); + extern int print_insn_i286 PARAMS ((bfd_vma, disassemble_info*)); extern int print_insn_i386 PARAMS ((bfd_vma, disassemble_info*)); extern int print_insn_m68k PARAMS ((bfd_vma, disassemble_info*)); extern int print_insn_z8001 PARAMS ((bfd_vma, disassemble_info*)); From raeburn@cygnus.com Wed Nov 9 23:35:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Wed, 09 Nov 1994 23:35:00 -0000 Subject: 16-bit i386 code support in GAS References: <199411091906.MAA25430@schirf.cs.utah.edu> Message-ID: <9411100735.AA24627@cujo.cygnus.com> Date: Wed, 09 Nov 94 12:06:51 MST From: Bryan Ford I've sent messages (including bug _fixes_, not just reports) to bug-gnu-utils several times before, and have never gotten any kind of response whatsoever - my mail just disappears into the void. :-) Yeah, I've been known to not respond very quickly, or sometimes at all, depending on (among other things) the severity of the problem, whether it's been reported before, whether I've responded to another posting of the same bug on bug-gnu-utils already, whether I've got a fix, how hard it looks to fix, how informative the bug report is, how swamped I feel with work I'm doing for Cygnus customers, what I had for breakfast, ... I'm not especially organized or disciplined when it comes to dealing with mail. But I'll usually keep the message around unless I've got some reason for thinking I won't need it -- for example, it describes a problem I think is already fixed, or something -- and I don't see your message among my saved mail. How long ago was it? Is the problem fixed in binutils-2.5.2? If it isn't, please resend it to me personally. From baford@schirf.cs.utah.edu Thu Nov 10 06:57:00 1994 From: baford@schirf.cs.utah.edu (Bryan Ford) Date: Thu, 10 Nov 1994 06:57:00 -0000 Subject: 16-bit i386 code support in GAS References: <9411100735.AA24627@cujo.cygnus.com> Message-ID: <199411101457.HAA00479@schirf.cs.utah.edu> > Date: Wed, 09 Nov 94 12:06:51 MST > From: Bryan Ford > > > I've sent messages (including bug _fixes_, not just reports) > to bug-gnu-utils several times before, and have never gotten any > kind of response whatsoever - my mail just disappears into the void. :-) > >Yeah, I've been known to not respond very quickly, or sometimes at >all, depending on (among other things) the severity of the problem, >whether it's been reported before, whether I've responded to another >posting of the same bug on bug-gnu-utils already, whether I've got a >fix, how hard it looks to fix, how informative the bug report is, how >swamped I feel with work I'm doing for Cygnus customers, what I had >for breakfast, ... I'm not especially organized or disciplined when >it comes to dealing with mail. > >But I'll usually keep the message around unless I've got some reason >for thinking I won't need it -- for example, it describes a problem I >think is already fixed, or something -- and I don't see your message >among my saved mail. How long ago was it? Is the problem fixed in >binutils-2.5.2? If it isn't, please resend it to me personally. Actually, the messages I'm referring to weren't about GAS; they concerned other GNU utilities whose maintainers also supposedly live on the bug-gnu-utils list. In particular, a while ago I sent in a patch to the 'patch' program that makes it work with binary files and binary diffs (diff -a). Also, I sent in a patch to autoconf-1.11 around the time when that was the most recent version, to add a couple new features needed by the new Mach build environment. Neither of these were bug "reports" needing hunting down and fixing; they were actual patches that should only need a brief look-through and a merge. But as I said I never got any response to either. Anyway, I expect neither of those are your problems; but it would be helpful if _somebody_ was handling those other utilities. :-) Bryan From rms@gnu.ai.mit.edu Thu Nov 10 08:11:00 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) Date: Thu, 10 Nov 1994 08:11:00 -0000 Subject: traditional Intel & Microsoft formats... References: <9411091639.AA07216@Congruent.COM> Message-ID: <9411101611.AA17161@mole.gnu.ai.mit.edu> The main purpose of GNU is to make a free operating system--not to enhance proprietary ones. If everyone in the world ran GNU software on Windows, that would perhaps please some users, but fundamentally the project would have gone astray. If a community, whether large or small, can be viable using entirely free software, that is success. We do support non-GNU-like operating systems, when it is not a lot of trouble and someone writes the code. From rms@gnu.ai.mit.edu Thu Nov 10 08:22:00 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) Date: Thu, 10 Nov 1994 08:22:00 -0000 Subject: traditional Intel & Microsoft formats... References: <9411091757.AA00676@cujo.cygnus.com> Message-ID: <9411101622.AA17219@mole.gnu.ai.mit.edu> There are certain states in which courts have ruled that shrink-wrap licenses are not valid, and perhaps you can count on this now in all states. Meanwhile, there are states in which the Federal courts have ruled that disassembly is lawful. Also, in the EC, a law was passed that explicitly makes disassembly lawful, when used for the purposes of finding out the information necessary to make something that can interoperate. If you buy a copy in a state where shrink-wrap licenses have been ruled not valid, you can then lawfully take it to the EC (assuming this is not export-restricted), and there lawfully disassemble it and use the information. From erich@uruk.org Thu Nov 10 09:35:00 1994 From: erich@uruk.org (Erich Stefan Boleyn) Date: Thu, 10 Nov 1994 09:35:00 -0000 Subject: traditional Intel & Microsoft formats... References: <9411101611.AA17161@mole.gnu.ai.mit.edu> Message-ID: <199411101738.JAA23235@uruk.org> > The main purpose of GNU is to make a free operating system--not to > enhance proprietary ones. If everyone in the world ran GNU software > on Windows, that would perhaps please some users, but fundamentally > the project would have gone astray. If a community, whether large or > small, can be viable using entirely free software, that is success. Hmmm... I think you're responding to 's comment about going with Windows-NT, but it sounds enough like you're responding to my comment on emulation that I'm sending this. My reasoning for interest in a flexible binary emulator that is free and runs on a free OS, but can run proprietary executables is that it opens the doors for those who would like to use a non-proprietary OS, but are required to use proprietary software. The biggest argument is always the existence argument. We need to do , and the only software available to really help with is running on on , and each one is proprietary, and possibly incompatible with other things they have. In the long run, in theory, binary emulation for systems that don't have process migration may be useless, but I don't foresee the free software world taking over that completely for a very long time, even given that people will go that route without a lot of persuasion. To get poeple to use a free OS on a lot of machines willingly, the only way I see to do it is at least OS-emulation (running executables form different OS's on the same hardware), and binary emulation is the logical conclusion which makes it just that much better. For example, (I hope you don't hate me for saying this, Richard :-/, I think that a PPC/68K Mac emulation system would be a very good addition. The reason is that it would encourage people who are stuck using Mac applications to run on a HURD OS supported machine. They wouldn't have to buy from Apple, then. My girlfriend, for example, has to use Mac application for her job, and will have to for some time. > We do support non-GNU-like operating systems, when it is not a lot of > trouble and someone writes the code. I think at least supporting the formats is a Good Thing, as long as someone wants to use a free OS for some proprietary thing they need to work on. In case you're interested, I really do believe in the GNU idea, and liked the manifesto, but I really want to get it used widely. Erich -- Erich Stefan Boleyn \__ E-mail (preferred): Mathematician, Software Engineer \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 From raeburn@cygnus.com Thu Nov 10 11:51:00 1994 From: raeburn@cygnus.com (Ken Raeburn) Date: Thu, 10 Nov 1994 11:51:00 -0000 Subject: 16-bit i386 code support in GAS References: <199411101457.HAA00479@schirf.cs.utah.edu> Message-ID: <9411101951.AA25868@cujo.cygnus.com> Ah, okay. No, diff and autoconf and the like aren't my problem... From gnu@cygnus.com Thu Nov 10 22:53:00 1994 From: gnu@cygnus.com (John Gilmore) Date: Thu, 10 Nov 1994 22:53:00 -0000 Subject: traditional Intel & Microsoft formats... References: <199411091607.IAA20118@uruk.org> Message-ID: <199411110653.WAA01871@cygnus.com> I applaud your effort to support more file formats in the hope of making it possible to run (proprietary or free) programs from the PC world on GNU systems. Have you examined the Wine emulator for Windows programs? And the "sim" directory of instruction-set simulators in the GDB releases? Some of us have similar dreams... Specs for some of the formats you are interested in *are* available and don't have to be reverse-engineered. (Some other info, such as debug sections, may require more work -- I haven't checked into all the details.) There's an organization of OS and tool companies called the Tool Interface Standards committee. It publishes specs and talks about new formats and revisions. Cygnus asked how we could join one time, but never got a response. Here are my old notes about this: Subject: [Intel x86] Tool Interface Standards committee Announced in Open Systems Today, March 1, 1993. Committee is Borland, IBM, Intel, Lotus, MetaWare, Microsoft, SCO, Watcom. Contact: David Bernstein, director of technology at SCO. Volume 1: Portable executable format (from Windows NT) and STI (symbol and type information). Volume 2: ELF, DWARF, and OMF. Version 1.0 of the standard is free of charge (in hard copy) on request. Available from Intel. +1 800 548 4725 Order # 241-597 Takes 7-10 working days. Arrived from: Tool Interface Standards c/o Intel Corporation RN6-30 2200 Mission College Blvd. Santa Clara, CA 95052 signature space left for "Secretary, TIS Committee", but not signed. "The TIS Committee is an open forum in which corporations can provide leadership for advancing the PC software market. The Committee welcomes participation by new company members. Interested companies can learn more about TIS by using Intel ACCESS on CompuServe." John The Tool Interface Standards ad-hoc committee has produced two documents, describing ELF, DWARF (almost 2.0), OMF, PE, and STI object formats. The intent is that every vendor's tools can interoperate, at least on Intel x86 platforms. Some of the formats describe other CPUs as well. The committee is currently Borland, IBM, Intel, Lotus, Metaware, Microsoft, SCO, and Watcom, with help from PharLap and Symantec. The standards haven't been jiggered -- e.g. ELF is the real thing. ELF is the only one that we currently support. Our DWARF support is for a previous rev, and we don't do OMF (which is used for DOS and OS/2 relocatable files), PE (Windows NT executable, basically COFF), and STI (Windows NT debug info). But now we can if we want to. --- By the way, it looks to me like Windows DLL linking is remarkably like dynamic linking on SVR4 or SunOS. Since the GNU Linker now supports dynamic linking (which was, indeed, a fair bit of work), making it handle DLL's is probably not as big a job as you think. The way to support any of these formats is to write a new BFD back-end. It's really pretty easy. Look at one of the simple ones that isn't full of macros -- say, binary.c or tekhex.c or srec.c or oasys.c. (The macro-ized bfd target code is to support seventeen variants of a.out or COFF on seventeen Unix machines.) To read a new file format, you only need to write a dozen functions (check file format, get section info, get section contents, get symbol table size, get symbol table, etc). Once you get this simple stuff into a BFD target, you get immense leverage from the already-99%-working code in the assembler, linker, binutils, and GDB that calls BFD. John Gilmore Cygnus Support From gnu@cygnus.com Thu Nov 10 23:25:00 1994 From: gnu@cygnus.com (John Gilmore) Date: Thu, 10 Nov 1994 23:25:00 -0000 Subject: traditional Intel & Microsoft formats... References: <199411110653.WAA01871@cygnus.com> Message-ID: <199411110725.XAA02165@cygnus.com> Ah, it's gradually coming back to me! There *are* online versions of the specs for most of these file formats, available from Intel. Look at: ftp://ftp.intel.com/pub/tis or ftp://ftp.intel.com/pub/IAL/TIS Note that any ".gps" files there seem to really be ".zip" files. Here's the overview of what's there, from the /pub/IAL/libdir.txt file: SYM10H.ZIP/Bin Bytes: 189258, Count: 26, 05-Nov-93 Last:10-May-94 Title: Microsoft Symbol and Type Information Spec., V1. Keywords: SYMBOL TYPE MS TIS The Microsoft Symbol and Type Information Spec., V1.0 is a chapter in the Formats Specification for Windows, V1.0 (which is also posted in this forum in its entirety.) It may also be ordered from Intel Corporate Literature at 1-800-548-4725. This specification is posted royalty-free for you to use to make your software TIS-compliant. FORMAT; Pkzipped file extracts to a H/P postscript file. Copy to your H/P PS printer to print (tested on an HPIIISi PS printer.) SYM10G.ZIP/Bin Bytes: 187651, Count: 15, 05-Nov-93 Last:10-May-94 Title: Microsoft Symbol and Type Information Spec., V1. Keywords: MS SYMBOL TYPE SPEC. The Microsoft Symbol and Type Information Spec., V1.0 is a chapter in the Fomats Specification for Windows, V1.0 (which is also posted in this forum in its entirety). It may also be ordered through Intel Corporate Literature at 1-800-548-4725. OMF11H.ZIP/Bin Bytes: 113929, Count: 35, 05-Nov-93 Last:30-May-94 Title: Relocatable Object Module Format (OMF), V1.1 Keywords: OMF RELOCATABLE OBJECT TIS PE The Relocatable Object Module Format (OMF) V1.1 is a chapter of the Portable Formats Specification, V1.1 (which is also posted on this forum in its entirety). This spec. may also be ordered from Intel Corporate Literature, at 1-800-548-4725. OMF11G.ZIP/Bin Bytes: 112573, Count: 26, 05-Nov-93 Last:10-May-94 Title: Relocatable Object Module Format (OMF) , V1.1 Keywords: OMF OBJECT RELOCATABLE TIS PE The Relocatable Object Module Format (OMF), V1.1 is a chapter in the Portable Formats Specification, V1.1 (which is also posted in its entirety in this forum). ELF11H.ZIP/Bin Bytes: 76717, Count: 36, 05-Nov-93 Last:10-May-94 Title: Executable and Linkable Format (ELF) V1.1 Keywords: ELF EXECUTABLE FORMAT TIS The Executable and Linkable Format Specification, V1.1, is part of the TIS standard Portable Formats Specification, V1.1, (which is also posted in this forum in its entirety). This standard may also be ordered by calling the Intel Lit. Ctr. at 1-800-548-4725. ELF11G.ZIP/Bin Bytes: 76670, Count: 22, 05-Nov-93 Last:10-May-94 Title: Executable and Linkable Format (ELF) V1.1 Keywords: ELF EXECUTABLE LINKABLE TIS Part of the Portable Formats Specification (also posted in this forum), V1.1, ELF is the Executable and Linkable Format. DWF11.ZIP/Bin Bytes: 120951, Count: 31, 04-Nov-93 Last:29-Apr-94 Title: DWARF Debug Information Format, V1.1 Keywords: DEBUG DWARF TIS OBJECT This document, prepared in cooperation with the TIS committee, defines the format for the information generated by compilers, assemblers, and linkage editors that is necessary for symbolic, source-level debugging. WINFMH.ZIP/Bin Bytes: 262359, Count: 38, 04-Nov-93 Last:10-May-94 Title: Format Specification for Windows, Version 1.0 Keywords: PE PORTABLE EXECUTABLE SYMBOL SYM Format Specification for Windows, Version 1.0. This spec. contains the portable executable (PE) format, and the Microsoft Symbol and Type Information. PF11H.ZIP/Bin Bytes: 377691, Count: 38, 04-Nov-93 Last:10-May-94 Title: Portable Formats Specification, Version 1.1 Keywords: OMF ELF DWARD PORTABLE OBJECT RELOCATABLE This zip file contains the Portable Formats Specification, V1.1. It is composed of chapters on DWARF (debugging information format), ELF (executable and linkable format), and OMF (relocatable object module format). MEMAPP.DOC/Bin Bytes: 5382, Count: 23, 06-Oct-93 Last:02-Jun-94 Title: TIS Committee Application Form and Membership Ru Keywords: TIS APPLICATION Tools Interface Standards Committee membership rules and membership application form. FORMAT: Word for Windows BYLAWS.DOC/Bin Bytes: 19550, Count: 21, 06-Oct-93 Last:23-Apr-94 Title: TIS Committee Bylaws, V1.0 Keywords: TIS TOOLS BYLAWS The Tools Interface Standards Committee Bylaws, V1.0, January 21, 1993, define the committee role and purposes. FORMAT: Word for Windows. TISGLS.TXT/Text Bytes: 3231, Count: 119, 03-Mar-93 Last:04-Jun-94 Title: TIS Glossary Keywords: TIS GLOSSARY APPLICATIONS SOFTWARE DEVELOPMENT TOOL This file contains the TIS (Tool Interface Standards) Glossary which defines some typical TIS lingo. TISFQA.TXT/Text Bytes: 3622, Count: 96, 03-Mar-93 Last:02-Jun-94 Title: TIS Questions and Answers Keywords: TIS QUESTIONS ANSWERS This file contains commonly asked questions and answers in regards to TIS (Tool Interface Standards) and additional information on TIS Standards. TISFPR.TXT/Text Bytes: 4141, Count: 102, 03-Mar-93 Last:02-Jun-94 Title: TIS Press Release March 93 Keywords: TIS PRESS RELEASE This file contains the TIS (Tool Interface Standards) Press Release dated Feb. 23, 1993. It describes the standards committee to expedite 32-bit PC applications development, endorses open, compatible, cross-OS tool interface. From artk@congruent.com Fri Nov 11 05:34:00 1994 From: artk@congruent.com (Arthur Kreitman) Date: Fri, 11 Nov 1994 05:34:00 -0000 Subject: traditional Intel & Microsoft formats... References: <199411110653.WAA01871@cygnus.com> Message-ID: <9411111311.AA12300@Congruent.COM> > Specs for some of the formats you are interested in *are* available > and don't have to be reverse-engineered. (Some other info, such as > debug sections, may require more work -- I haven't checked into all the > details.) There's an organization of OS and tool companies called the As far as what Microsoft is calling their PE format (the one that's being used for NT and will be used for Windows95, none of those documents you listed are either complete or valid. > Tool Interface Standards committee. It publishes specs and talks > about new formats and revisions. Cygnus asked how we could join one > time, but never got a response. Here are my old notes about this: I think the reason you never got a response it that the effort was stillborn. It was announced about the same time as NT was announced. They advertised that DWARF was the answer to all your problems, and ignored Microsoft. They then disappeared. I don't know if they exist or not, but I'm certain that Microsoft has continued to enhance aspects of their object format without asking their permission. > By the way, it looks to me like Windows DLL linking is remarkably like > dynamic linking on SVR4 or SunOS. Since the GNU Linker now supports > dynamic linking (which was, indeed, a fair bit of work), making it > handle DLL's is probably not as big a job as you think. I don't think that the mechanism used to support dll's is similar to sunos shared library support in any way. Their capabilities differ significantly. > The way to support any of these formats is to write a new BFD > back-end. It's really pretty easy. Look at one of the simple ones That's the easiest part of supporting the Microsoft formats. There are new section types that have to be generated, import tables, export tables, resources. BFD get you alot closer, but I would guess that it will that more resources to get the current BFD to completely support MS executables then it took to add sunos dynamic linking. As an aside, do you know how much work was required to add sun dymanic linking. From dj@stealth.ctron.com Fri Nov 11 06:11:00 1994 From: dj@stealth.ctron.com (DJ Delorie) Date: Fri, 11 Nov 1994 06:11:00 -0000 Subject: [masaki@eie.monolta.co.jp: GAS bug and etc] Message-ID: <9411111413.AA08124@delorie> Return-Path: Date: Fri, 11 Nov 1994 14:27:09 +0900 To: djgpp@sun.soe.clarkson.edu From: masaki@eie.monolta.co.jp (Kenji Masaki) X-Sender: masaki@vivid.eie.minolta.co.jp Subject: GAS bug and etc Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-Mailer: Eudora-J(1.3.7-J12) DJ-Mail-Sort: djgpp@, djgpp Hello.$B!!(BDJ and evrybody We (members of FETX at Niftyserve in JAPAN) found a bug of GAS 2.3 , 2.5.1 and 2.5.2 ,and FIX it as follows. By the way, it seems that treatment of long-filename lacks unity in djgpp. i.e. _fixpath is called in stat(), while DPMI(DOS) function [is] called directry in access.c. Shouldn't it be standardized? diff --context=2 -r c:/binutils.2/include/opcode/i386.h d:/binutils.2/include/opcode/i386.h *** c:/binutils.2/include/opcode/i386.h Thu Mar 31 16:35:32 1994 --- d:/binutils.2/include/opcode/i386.h Wed Nov 9 15:44:48 1994 *************** *** 324,332 **** /* these turn into pseudo operations when disp is larger than 8 bits */ #define IS_JUMP_ON_CX_ZERO(o) \ ! (o == 0x66e3) #define IS_JUMP_ON_ECX_ZERO(o) \ (o == 0xe3) ! {"jcxz", 1, 0x66e3, _, JumpByte, { Disp, 0, 0} }, {"jecxz", 1, 0xe3, _, JumpByte, { Disp, 0, 0} }, --- 324,332 ---- /* these turn into pseudo operations when disp is larger than 8 bits */ #define IS_JUMP_ON_CX_ZERO(o) \ ! (o == 0x67e3) /* by members of FEXT niftyserve */ #define IS_JUMP_ON_ECX_ZERO(o) \ (o == 0xe3) ! {"jcxz", 1, 0x67e3, _, JumpByte, { Disp, 0, 0} }, /* by members of FEXT niftyserve */ {"jecxz", 1, 0xe3, _, JumpByte, { Disp, 0, 0} }, ---------- Kenji Masaki ------------------------------ Kenji Masaki$B!!(B $B!!(B Image Infomation Engineering Division MINOLTA Co. Ltd. , JAPAN ------------------------------ From hjl@nynexst.com Fri Nov 11 06:28:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Fri, 11 Nov 1994 06:28:00 -0000 Subject: [masaki@eie.monolta.co.jp: GAS bug and etc] References: <9411111413.AA08124@delorie> Message-ID: <9411111426.AA05475@titanic.nynexst.com> Your patch jusr reversed what I did. Could you please tell me why I was wrong and you were right? I thought I checked the Intel x86 manual when I fixed that bug. Thanks. H.J. ----- Thu Mar 31 19:34:08 1994 Ken Raeburn (raeburn@cujo.cygnus.com) * i386.h (IS_JUMP_ON_ECX_ZERO, "jcxz" pattern): Operand size prefix is 0x66, not 0x67. Patch from H.J. Lu (hlu@nynexst.com). ------ > > > Return-Path: > Date: Fri, 11 Nov 1994 14:27:09 +0900 > To: djgpp@sun.soe.clarkson.edu > From: masaki@eie.monolta.co.jp (Kenji Masaki) > X-Sender: masaki@vivid.eie.minolta.co.jp > Subject: GAS bug and etc > Mime-Version: 1.0 > Content-Type: text/plain; charset=iso-2022-jp > X-Mailer: Eudora-J(1.3.7-J12) > DJ-Mail-Sort: djgpp@, djgpp > > Hello.$B!!(BDJ and evrybody > > We (members of FETX at Niftyserve in JAPAN) found a bug of GAS 2.3 , 2.5.1 > and 2.5.2 ,and FIX it as follows. > > By the way, it seems that treatment of long-filename lacks unity in djgpp. > i.e. _fixpath is called in stat(), while DPMI(DOS) function [is] called > directry in access.c. Shouldn't it be standardized? > > > diff --context=2 -r c:/binutils.2/include/opcode/i386.h > d:/binutils.2/include/opcode/i386.h > *** c:/binutils.2/include/opcode/i386.h Thu Mar 31 16:35:32 1994 > --- d:/binutils.2/include/opcode/i386.h Wed Nov 9 15:44:48 1994 > *************** > *** 324,332 **** > /* these turn into pseudo operations when disp is larger than 8 bits */ > #define IS_JUMP_ON_CX_ZERO(o) \ > ! (o == 0x66e3) > #define IS_JUMP_ON_ECX_ZERO(o) \ > (o == 0xe3) > > ! {"jcxz", 1, 0x66e3, _, JumpByte, { Disp, 0, 0} }, > {"jecxz", 1, 0xe3, _, JumpByte, { Disp, 0, 0} }, > --- 324,332 ---- > /* these turn into pseudo operations when disp is larger than 8 bits */ > #define IS_JUMP_ON_CX_ZERO(o) \ > ! (o == 0x67e3) /* by members of FEXT niftyserve */ > #define IS_JUMP_ON_ECX_ZERO(o) \ > (o == 0xe3) > > ! {"jcxz", 1, 0x67e3, _, JumpByte, { Disp, 0, 0} }, /* by members of FEXT > niftyserve */ > {"jecxz", 1, 0xe3, _, JumpByte, { Disp, 0, 0} }, > > ---------- Kenji Masaki > ------------------------------ > Kenji Masaki$B!!(B > $B!!(B Image Infomation Engineering > Division > MINOLTA Co. Ltd. , JAPAN > ------------------------------ From dj@stealth.ctron.com Fri Nov 11 06:37:00 1994 From: dj@stealth.ctron.com (DJ Delorie) Date: Fri, 11 Nov 1994 06:37:00 -0000 Subject: [masaki@eie.monolta.co.jp: GAS bug and etc] References: <9411111426.AA05475@titanic.nynexst.com> Message-ID: <9411111438.AA11089@delorie> > Your patch jusr reversed what I did. Could you please tell > me why I was wrong and you were right? I thought I checked > the Intel x86 manual when I fixed that bug. I didn't try to validate the patch; it was more of an FYI, which is why I included the header info. If it's wrong, or you need more info, the original sender is the one to talk with (cc'd in both mails). Sorry if my intention wasn't clear. Original sender: > From: masaki@eie.monolta.co.jp (Kenji Masaki) Note that the "jcxz" opcode in the gas that djgpp's libc was built with doesn't work as expected - jecxz does. This might have confused people into thinking that there was a bug, or maybe there really is one. jcxz is the 16-bit version (or pretends to be). Since jcxz uses both a register (opsize?) and an address (addrsize?), there may be a need for both prefixes. DJ From hjl@nynexst.com Fri Nov 11 06:45:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Fri, 11 Nov 1994 06:45:00 -0000 Subject: [masaki@eie.monolta.co.jp: GAS bug and etc] References: <9411111438.AA11089@delorie> Message-ID: <9411111444.AA05506@titanic.nynexst.com> > > > Your patch jusr reversed what I did. Could you please tell > > me why I was wrong and you were right? I thought I checked > > the Intel x86 manual when I fixed that bug. > > I didn't try to validate the patch; it was more of an FYI, which is > why I included the header info. If it's wrong, or you need more info, > the original sender is the one to talk with (cc'd in both mails). > Sorry if my intention wasn't clear. I just hate that, especially when people say my patch is wrong without doing their homework first :-). > > Original sender: > > From: masaki@eie.monolta.co.jp (Kenji Masaki) > > Note that the "jcxz" opcode in the gas that djgpp's libc was built > with doesn't work as expected - jecxz does. This might have confused > people into thinking that there was a bug, or maybe there really is > one. jcxz is the 16-bit version (or pretends to be). > jcxz and jecxz are totally different. One checks cx, the other checks ecx. You have to decide what you want to use. > Since jcxz uses both a register (opsize?) and an address (addrsize?), > there may be a need for both prefixes. I think gas will add a right address prefix automatically when it sees a large offset. Ken? -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From dj@stealth.ctron.com Fri Nov 11 06:49:00 1994 From: dj@stealth.ctron.com (DJ Delorie) Date: Fri, 11 Nov 1994 06:49:00 -0000 Subject: [masaki@eie.monolta.co.jp: GAS bug and etc] References: <9411111444.AA05506@titanic.nynexst.com> Message-ID: <9411111450.AA12152@delorie> > I think gas will add a right address prefix automatically when it sees > a large offset. Ken? The problem with using the 16-bit jcxz is that, even if the offset is small, if the target isn't in the first 64K of memory, the program is toast. The reason is that %eip is masked to 0x0000ffff AFTER adding the offset. The 32-bit version doesn't do this. I can't see this behavior being of *any* use in a 32-bit program, unless you *really* know what you're doing. From hjl@nynexst.com Fri Nov 11 07:06:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Fri, 11 Nov 1994 07:06:00 -0000 Subject: [masaki@eie.monolta.co.jp: GAS bug and etc] References: <9411111450.AA12152@delorie> Message-ID: <9411111506.AA05546@titanic.nynexst.com> > > > I think gas will add a right address prefix automatically when it sees > > a large offset. Ken? > > The problem with using the 16-bit jcxz is that, even if the offset is > small, if the target isn't in the first 64K of memory, the program is How big is your offset? I need to know the exact number. FYI, jcxz/jecxz can only take a signed byte disp. But gas treats the disp as unsigned byte. > toast. The reason is that %eip is masked to 0x0000ffff AFTER adding > the offset. The 32-bit version doesn't do this. I can't see this > behavior being of *any* use in a 32-bit program, unless you *really* > know what you're doing. > Ken, Ian, I have sent you guys a patch for that. You don't like it. It may bit them now. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From ian@cygnus.com Fri Nov 11 08:31:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Fri, 11 Nov 1994 08:31:00 -0000 Subject: traditional Intel & Microsoft formats... References: <9411111311.AA12300@Congruent.COM> Message-ID: <199411111631.LAA06035@sanguine.cygnus.com> Date: Fri, 11 Nov 94 08:11:00 est From: artk@congruent.com (Arthur Kreitman) > By the way, it looks to me like Windows DLL linking is remarkably like > dynamic linking on SVR4 or SunOS. Since the GNU Linker now supports > dynamic linking (which was, indeed, a fair bit of work), making it > handle DLL's is probably not as big a job as you think. I don't think that the mechanism used to support dll's is similar to sunos shared library support in any way. Their capabilities differ significantly. I don't know that much about dll's. Could you give a brief summary of why they are so much more difficult than, say, ELF dynamic libraries? The GNU linker currently has full support for ELF dynamic libraries. > The way to support any of these formats is to write a new BFD > back-end. It's really pretty easy. Look at one of the simple ones That's the easiest part of supporting the Microsoft formats. There are new section types that have to be generated, import tables, export tables, resources. BFD get you alot closer, but I would guess that it will that more resources to get the current BFD to completely support MS executables then it took to add sunos dynamic linking. It's true that the BFD paradigm does not represent certain things well. For example, MIPS ELF uses an unusual debugging format (ECOFF) which requires linker support, as well as recording information like how much an object file would be changed by compiling with different values of the -G switch. BFD can not represent this information publically, but that does not mean that BFD does not help enormously when writing a linker. It just means that special routines are required in that BFD backend. As an aside, do you know how much work was required to add sun dymanic linking. I did all the work to support SunOS dynamic linking. I did it mostly on my own time, since Cygnus did not have a customer for it. The hardest part was reverse engineering the largely undocumented format. I don't want to pass over that too lightly, because it was quite difficult. On the other hand I am assured by friends at Microsoft that the object file format is reasonably well described on some CD or set of CD's which is available for $195. Once I understood the format, it probably took me about a week all told to write the linker support. The ELF dynamic linking code had already been written, largely by Eric Youngdale, so I was able to use that as a guide. You could add in a couple of days I spent early in the process to add some calls to BFD to read the dynamic symbol table and the dynamic relocs, so that I could examine them with objdump while I tried to figure out what the runtime linker did with them. Ian From meissner@osf.org Fri Nov 11 08:39:00 1994 From: meissner@osf.org (Michael Meissner) Date: Fri, 11 Nov 1994 08:39:00 -0000 Subject: Elfdump Message-ID: <9411111638.AA06307@pasta.osf.org> I wrote the following ELF dumper in order to learn ELF, and thought others might find it useful. It is more specific than objdump (and it especially helped when the BFD support for ELF was weak). /* * COPYRIGHT NOTICE * * Copyright (c) 1990, 1991, 1992, 1993 Open Software Foundation, Inc. * * Permission is hereby granted to use, copy, modify and freely distribute * the software in this file and its documentation for any purpose without * fee, provided that the above copyright notice appears in all copies and * that both the copyright notice and this permission notice appear in * supporting documentation. Further, provided that the name of Open * Software Foundation, Inc. ("OSF") not be used in advertising or * publicity pertaining to distribution of the software without prior * written permission from OSF. OSF makes no representations about the * suitability of this software for any purpose. It is provided "as is" * without express or implied warranty. */ /* * ELF object file dumper. */ /* * HISTORY * $Log: elfdump.c,v $ * Revision 1.1.2.32 1994/04/08 17:10:34 meissner * Correctly print out .lprofil sections when a double word count is used. * [1994/04/08 17:10:25 meissner] * * Revision 1.1.2.31 1994/04/07 13:56:54 meissner * Range check section section index in get_section_name. * Add program header regions to vm/file map printout. * [1994/04/07 13:56:44 meissner] * * Revision 1.1.2.30 1994/03/17 13:28:57 meissner * Cut down on more spaces in output. * Print section name instead of number in symbol. * If -e, add linker generated symbols in vm layout. * Indicate where there are holes in the file/vm layout. * Don't print profil buckets that are 0. * [1994/03/17 13:28:49 meissner] * * Revision 1.1.2.29 1994/03/16 22:27:11 meissner * Print out layout information for the ELF file and virtual memory. * Check layouts printed for overlaps. * Print out end offsets in the program headers. * Lowercase section flags. * Cut down on symbol line length. * [1994/03/16 22:27:02 meissner] * * Revision 1.1.2.28 1994/03/16 18:25:24 meissner * Align summary fields of section headers. * Print out end+1 offset in section headers. * Always print all section header fields. * Skip profiling sections if -p. * [1994/03/16 18:25:14 meissner] * * Revision 1.1.2.27 1994/03/11 22:35:01 chasb * Expand Copyrights * [1994/03/09 19:43:03 chasb] * * Revision 1.1.2.26 1994/02/28 21:36:34 meissner * Correctly print out profil lowpc. * [1994/02/28 21:36:24 meissner] * * Revision 1.1.2.25 1994/02/25 16:55:19 meissner * Add support for printing profile stats on OSF/1. * Allow unsigned long in addition to int for profil sizes. * [1994/02/25 16:55:11 meissner] * * Revision 1.1.2.24 1993/12/23 01:18:10 meissner * On OSF/1 print the uarea for profiling ELF files. * [1993/12/23 01:18:03 meissner] * * Revision 1.1.2.23 1993/11/22 21:14:23 meissner * Add -v option to print the version string. * [1993/11/22 21:14:16 meissner] * * Revision 1.1.2.22 1993/11/22 21:00:50 meissner * Don't print section name for reloc to defined symbol, print symbol name. * [1993/11/22 21:00:42 meissner] * * Revision 1.1.2.21 1993/11/11 21:40:27 meissner * Correctly align gprof/prof output. * Don't print profil ticks in hex. * [1993/11/11 21:40:12 meissner] * * Revision 1.1.2.20 1993/11/11 21:29:19 meissner * CR 77 - Add profile output support. * [1993/11/11 21:29:06 meissner] * * Revision 1.1.2.19 1993/10/15 18:55:56 meissner * Fix mmap call to set the MAP_PRIVATE flag. * [1993/10/15 18:55:44 meissner] * * Revision 1.1.2.18 1993/09/23 21:52:22 meissner * Treat .debug_sfnames as a string section. * [1993/09/23 21:52:09 meissner] * * Revision 1.1.2.17 1993/09/23 21:29:12 meissner * Skip printing null bytes in string sections, except for the first byte. * [1993/09/23 21:28:58 meissner] * * Revision 1.1.2.16 1993/09/23 21:21:20 meissner * Print .stabstr section as strings. * Know about .stab section special format. * [1993/09/23 21:21:07 meissner] * * Revision 1.1.2.15 1993/09/08 22:32:47 meissner * CR 62: Add -t {d,o,x} to specify output formats. * [1993/09/08 22:32:35 meissner] * * Revision 1.1.2.14 1993/07/27 20:37:07 meissner * Print 386 relocations in symbolic format. * [1993/07/27 20:36:52 meissner] * * Revision 1.1.2.13 1993/07/23 15:07:30 meissner * Add definition of STT_STABS if not provided in elf.h. * Remove ifdefs of STT_STABS elsewhere. * If -d, invoke objdump -d -j

to disassemble executable sections. * [1993/07/23 15:07:12 meissner] * * Revision 1.1.2.12 1993/07/21 01:33:23 meissner * Print stabs type symbolically, not numerically. * Rename ELF32_STABS_UNUSED -> ELF32_STABS_OTHER. * [1993/07/21 01:33:05 meissner] * * Left align size field, instead of right align. * [1993/07/18 17:18:12 meissner] * * Add appropriate casts and/or 'l' specifiers to *printf formats. * Add STABS in symbol support. * [1993/07/18 15:07:36 meissner] * * Revision 1.1.2.11 1993/06/14 02:15:26 meissner * Print hash tables again after last change. * Print interp section in string form, even if -p. * [1993/06/14 02:15:12 meissner] * * Revision 1.1.2.10 1993/06/14 02:02:20 meissner * CR 52: * Add -n switch to print a specific section. * Add -p switch to not print the contents of a progbits section. * Add -s switch to print header summary only. * Add -x switch to assume the string table is corrupt. * [1993/06/14 02:02:04 meissner] * * Revision 1.1.2.9 1993/05/27 18:56:26 meissner * Remove 386 hack which was caused by a buggy compiler. * [1993/05/27 18:56:11 meissner] * * Revision 1.1.2.8 1993/05/24 11:46:12 meissner * Hack around i386 problem with case SHN_ABS/SHN_COMMON. * [1993/05/24 11:45:53 meissner] * * Revision 1.1.2.7 1993/05/13 17:38:41 meissner * Add DT_RELAENT. * [1993/05/13 17:38:24 meissner] * * Revision 1.1.2.6 1993/05/12 19:40:17 meissner * Fix printing of implicit addend in relocation to get full word, not byte. * Print section being referenced in relocations, symbol tables and hash tables. * Print name of relocated symbol or section. * Don't assume REL implicit addend is word aligned. * Print the dynamic section in a friendly fashion. * [1993/05/12 19:39:57 meissner] * * Revision 1.1.2.5 1993/05/10 21:01:48 meissner * Fixup so it compiles cleanly on V.4. * Don't abort if implicit addend too large. * Fix GCC warnings. * Relocations for executables have virtual address in r_offset, not section offset. * Split sym/type in relocations. * [1993/05/10 21:01:28 meissner] * * Revision 1.1.2.4 1993/05/10 15:21:18 meissner * Print REL implicit addend. * [1993/05/10 15:20:59 meissner] * * Revision 1.1.2.3 1993/05/10 13:38:56 meissner * Change copyright to OSF_FREE_COPYRIGHT. * Deal with MAP_VARIABLE not being defined. * Add hash table support. * [1993/05/10 13:38:32 meissner] * * Revision 1.1.2.2 1993/05/07 19:44:44 meissner * Initial version. * [1993/05/07 19:44:20 meissner] * * $EndLog$ */ const char elfdump_what_string[] = "@(#)elfdump.c\t$Revision: 1.1.2.32 $ $Date: 1994/04/08 17:10:34 $ $Locker: $"; #include #include #include #include #include #include #include #include #include #include #include #include #ifdef __OSF1__ #include #include #include #endif #ifdef NEW_PROFILE #include static struct profile_profil profhdr; static int profhdr_p; #endif #ifndef DIGIT_OUTPUT_SIZE #define DIGIT_OUTPUT_SIZE 64 /* buffer size needed to format integers, includes prefix/suffix */ #endif extern int getopt (int, char * const [], const char *); extern char *optarg; extern int optind; extern int optopt; extern int opterr; #ifndef MAP_VARIABLE #define MAP_VARIABLE MAP_SHARED #endif #ifndef EM_MIPS #define EM_MIPS 8 #endif #ifndef DT_NULL /* dynamic structure - page 5-15, figure 5-9 */ typedef struct { Elf32_Sword d_tag; union { Elf32_Word d_val; Elf32_Addr d_ptr; } d_un; } Elf32_Dyn; /* Dynamic array tags - page 5-16, figure 5-10. */ #define DT_NULL 0 #define DT_NEEDED 1 #define DT_PLTRELSZ 2 #define DT_PLTGOT 3 #define DT_HASH 4 #define DT_STRTAB 5 #define DT_SYMTAB 6 #define DT_RELA 7 #define DT_RELASZ 8 #define DT_RELAENT 9 #define DT_STRSZ 10 #define DT_SYMENT 11 #define DT_INIT 12 #define DT_FINI 13 #define DT_SONAME 14 #define DT_RPATH 15 #define DT_SYMBOLIC 16 #define DT_REL 17 #define DT_RELSZ 18 #define DT_RELENT 19 #define DT_PLTREL 20 #define DT_DEBUG 21 #define DT_TEXTREL 22 #define DT_JMPREL 23 #endif #ifndef STT_STABS /* GNU extension to encode stabs in elf symbols. The size field is used to encode the unused, type, and desc fields. */ #define STT_STABS STT_HIPROC #define ELF32_STABS_OTHER(s) ((s) >> 24) #define ELF32_STABS_TYPE(s) (((s) >> 16) & 0xff) #define ELF32_STABS_DESC(s) ((short) s) #define ELF32_STABS_SIZE(u,t,d) (((u) << 24) | (((t) & 0xff) << 16) | ((d) & 0xffff)) #endif #ifndef ET_PROF /* OSF extension to encode profiling output as an ELF file. */ #define ET_PROF 0xffff #endif struct sec_list { struct sec_list *next; const char *section; }; typedef struct elf_stab { unsigned int soffset; /* offset to string in .stabstr */ unsigned char type; /* stab type */ unsigned char other; /* stab other field */ unsigned short desc; /* stab desc field */ int value; /* stab value field */ } elf_stab_t; static char *file; /* current file being processed */ static uchar_t *file_bytes = (uchar_t *)-1; /* pointer to current object file data */ static struct stat file_stat; /* file status information */ static int file_fd = -1; /* file descriptor file is openned on */ static Elf32_Ehdr ehdr; /* global header */ static struct sec_list *sections; /* sections to print out */ static int ignore_string = 0; /* ignore the string table */ static int objdump = 0; /* invoke objdump -d to disassemble text */ static int no_progbits = 0; /* skip printing progbits section */ static int no_layout = 0; /* skip printing file/vm layout information */ static int summary = 0; /* print just summary */ static int linker_symbols = 0; /* put etext/edata/end into layout */ static int print_vers = 0; /* print version string */ static int errors = 0; /* # errors found */ static char format = '\0'; /* default format to use */ static int sh_name_width = 0; /* width of section names */ static int sh_type_width = 0; /* width of section types */ static int sh_start_width = 0; /* width of section offset start */ static int sh_end_width = 0; /* width of section offset end */ static int sh_size_width = 0; /* width of section size */ static int sh_addr_width = 0; /* width of section address */ static int sh_align_width = 0; /* width of section alignment */ static int sh_flags_width = 0; /* width of section flag bits */ static int sh_index_width = 0; /* width of section index */ static int sh_info_width = 0; /* width of section info field */ static int sh_link_width = 0; /* width of section link field */ static int sh_esize_width = 0; /* width of section entsize field */ #define SEC_PTR(index) (((Elf32_Shdr *)(file_bytes + ehdr.e_shoff)) + index) #define PROGHDR_PTR(index) (((Elf32_Phdr *)(file_bytes + ehdr.e_phoff)) + index) static const char *const dyn_tag[] = { "null", "needed", "pltrelsz", "pltgot", "hash", "strtab", "symtab", "rela", "relasz", "relaent", "strsz", "syment", "init", "fini", "soname", "rpath", "symbolic", "rel", "relsz", "relent", "pltrel", "debug", "textrel", "jmprel", }; /* Enum that says to free name in layout chain */ typedef enum layout_free { layout_free_no = 0, /* do not free name field */ layout_free_yes = 1 /* free name field */ } layout_free_t; /* Structure that records the information about file/virtual layout */ typedef struct layout { struct layout *next; /* next layout element */ const char *name; /* element name */ unsigned long start; /* start address */ unsigned long size; /* size of region */ layout_free_t free_p; /* whether to free name or not */ } layout_t; static layout_t *file_layout = (layout_t *)0; static layout_t *vm_layout = (layout_t *)0; static const char *get_section_name (Elf32_Word); /* Allocate memory, abort if no memory is available. */ static void * xmalloc (size_t len) { void *p = malloc (len); if (!p) { perror ("malloc"); exit (1); } return p; } /* Convert a number to a string using a format specified by -t or a default one. */ #define MAX_STRINGIFY 32 /* if more concurrent calls are made this needs to be bumped */ static const char * stringify (unsigned long number, int width, int def_format, int skip_lead, const char *prefix, const char *suffix) { static unsigned next_buffer; static char def_buffer[MAX_STRINGIFY][DIGIT_OUTPUT_SIZE]; int use_format = (format) ? format : def_format; char *buffer = &def_buffer[ (next_buffer++) % MAX_STRINGIFY ][0]; switch (use_format) { default: sprintf (buffer, "%s%*ld%s", prefix, width, (long) number, suffix); break; case 'x': sprintf (buffer, "%s%s%0*lx%s", prefix, (skip_lead) ? "" : "0x", width, number, suffix); break; case 'o': sprintf (buffer, "%s%s%0*lo%s", prefix, (skip_lead) ? "" : "0", width, number, suffix); break; case 'u': sprintf (buffer, "%s%*lu%s", prefix, width, number, suffix); break; } return buffer; } /* Return the length of converting a number to a string via stringify. */ static int stringify_len (unsigned long number, int def_format, int skip_lead) { return strlen (stringify (number, 0, def_format, skip_lead, "", "")); } /* Silence -Wconversion */ #define stringify(n, w, d, l, p, s) (stringify)((unsigned long)(n), w, d, l, p, s) #define stringify_len(n, d, l) (stringify_len)((unsigned long)(n), d, l) /* Add an element to the layout linked list. */ static void add_layout (layout_t **head_ptr, const char *name, unsigned long start, unsigned long size, layout_free_t free_p) { layout_t *ptr = xmalloc (sizeof (layout_t)); ptr->next = *head_ptr; ptr->name = name; ptr->start = start; ptr->size = size; ptr->free_p = free_p; *head_ptr = ptr; } /* Silence -Wconversion */ #define add_layout(head_ptr, name, start, size, free_p) \ add_layout (head_ptr, name, (unsigned long)start, (unsigned long)size, free_p) /* * Delete a layout chain */ static void free_layout (layout_t **head_ptr) { layout_t *ptr = *head_ptr; layout_t *next; *head_ptr = (layout_t *)0; while (ptr) { next = ptr->next; if (ptr->free_p) free ((void *)ptr->name); free ((void *)ptr); ptr = next; } } /* Compare two layout pointers, sorting by start address. */ static int compare_layout (const void *a, const void *b) { const layout_t *ptr_a = *(const layout_t **)a; const layout_t *ptr_b = *(const layout_t **)b; return (ptr_a->start != ptr_b->start) ? ptr_a->start - ptr_b->start : ptr_a->size - ptr_b->size; } /* Sort and print a layout linked list */ static void print_layout (layout_t *head, const char *desc) { size_t num_ptrs; size_t i; size_t len; layout_t *ptr; layout_t **ptr_array; int width_start = 0; int width_end = 0; int width_size = 0; unsigned long oend; if (!head) { printf ("\nLayout for %s was empty\n", desc); return; } /* Count the number of pointers */ num_ptrs = 0; for (ptr = head; ptr != (layout_t *)0; ptr = ptr->next) num_ptrs++; /* Sort the layout pointers */ ptr_array = (layout_t **) xmalloc (num_ptrs * sizeof (layout_t *)); i = 0; for (ptr = head; ptr != (layout_t *)0; ptr = ptr->next) ptr_array[i++] = ptr; qsort ((void *)ptr_array, num_ptrs, sizeof (layout_t *), compare_layout); /* Size start, end */ for (i = 0; i < num_ptrs; i++) { ptr = ptr_array[i]; len = stringify_len (ptr->start, 'x', 1); if (len > width_start) width_start = len; len = stringify_len (ptr->start + ptr->size, 'x', 1); if (len > width_end) width_end = len; len = stringify_len (ptr->size, 'd', 1); if (len > width_size) width_size = len; } /* Print out the layout now */ printf ("\nLayout for %s:\n", desc); oend = 0; for (i = 0; i < num_ptrs; i++) { ptr = ptr_array[i]; if (i > 0 && ptr->start > oend) printf (" start= %s, end= %s, size= %s, name= %s", stringify (oend, width_start, 'x', 0, "", ""), stringify (ptr->start, width_end, 'x', 0, "", ""), stringify (ptr->start - oend, width_size, 'd', 0, "", ""), "\n"); printf (" start= %s, end= %s, size= %s, name= %s", stringify (ptr->start, width_start, 'x', 0, "", ""), stringify (ptr->start + ptr->size, width_end, 'x', 0, "", ""), stringify (ptr->size, width_size, 'd', 0, "", ""), ptr->name); if (i > 0 && ptr->start < oend) printf ("%*s**** Overlap!!", (int)strlen (ptr->name) - 32, ""); putchar ('\n'); oend = ptr->start + ptr->size; } free (ptr_array); } /* Convert an elf string reference into a real string. */ static const char * elf_string (Elf32_Word sec_index, Elf32_Word byte_off) { static char bad_string[] = "???"; Elf32_Shdr *sec_hdr = SEC_PTR (sec_index); if (ignore_string) return bad_string; if (sec_index <= 0 || sec_index > (int)ehdr.e_shnum || file_bytes == (uchar_t *)-1 || (sec_hdr->sh_type != SHT_STRTAB && strcmp (get_section_name (sec_index), ".stabstr") != 0)) { fprintf (stderr, "%s section %s is not a string table.\n", file, stringify (sec_index, 0, 'd', 0, "", "")); return bad_string; } if (byte_off > sec_hdr->sh_size) { fprintf (stderr, "%s string offset %s too big for section %s\n", file, stringify (byte_off, 0, 'd', 0, "", ""), stringify (sec_index, 0, 'd', 0, "", "")); return bad_string; } return (char *)(file_bytes + sec_hdr->sh_offset + byte_off); } /* Convert 1..4 bytes into printable notation. */ static char * printable_string (uchar_t *ptr, int num) { static char print_buffer[40]; int i; int ch; char *buffer_ptr = print_buffer; *buffer_ptr++ = '"'; for (i = 0; i < num; i++) { ch = *ptr++; switch (ch) { default: if (isprint (ch)) *buffer_ptr++ = ch; else { sprintf (buffer_ptr, "\\%03o", ch); buffer_ptr += 4; } break; case '\b': *buffer_ptr++ = '\\'; *buffer_ptr++ = 'b'; break; case '\f': *buffer_ptr++ = '\\'; *buffer_ptr++ = 'f'; break; case '\n': *buffer_ptr++ = '\\'; *buffer_ptr++ = 'n'; break; case '\r': *buffer_ptr++ = '\\'; *buffer_ptr++ = 'r'; break; case '\t': *buffer_ptr++ = '\\'; *buffer_ptr++ = 't'; break; case '\v': *buffer_ptr++ = '\\'; *buffer_ptr++ = 'v'; break; case '\"': *buffer_ptr++ = '\\'; *buffer_ptr++ = '"'; break; case '\'': *buffer_ptr++ = '\\'; *buffer_ptr++ = '\''; break; case '\\': *buffer_ptr++ = '\\'; *buffer_ptr++ = '\\'; break; } } *buffer_ptr++ = '"'; *buffer_ptr = '\0'; return print_buffer; } /* Convert a stab type into a string. */ static const char * printable_stab_type (int type) { switch (type) { case 0x20: return "GSYM, "; /* global symbol: name,,0,type,0 */ case 0x22: return "FNAME, "; /* procedure name (f77 kludge): name,,0 */ case 0x24: return "FUN, "; /* procedure: name,,0,linenumber,address */ case 0x26: return "STSYM, "; /* static symbol: name,,0,type,address */ case 0x28: return "LCSYM, "; /* .lcomm symbol: name,,0,type,address */ case 0x2a: return "MAIN, "; /* Name of main routine, not used in C */ case 0x30: return "PC, "; /* global pascal symbol: name,,0,subtype,line */ case 0x40: return "RSYM, "; /* register sym: name,,0,type,register */ case 0x44: return "SLINE, "; /* src line: 0,,0,linenumber,address */ case 0x46: return "DSLINE,"; /* like N_SLINE, except in data segment */ case 0x48: return "BROWS, "; /* source code browser stabs */ case 0x54: return "CATCH, "; /* GNU G++ catch clause */ case 0x60: return "SSYM, "; /* structure elt: name,,0,type,struct_offset */ case 0x64: return "SO, "; /* source file name: name,,0,0,address */ case 0x80: return "LSYM, "; /* local sym: name,,0,type,offset */ case 0x82: return "BINCL, "; /* aux beginning of include file */ case 0x84: return "SOL, "; /* #included file name: name,,0,0,address */ case 0xa0: return "PSYM, "; /* parameter: name,,0,type,offset */ case 0xa2: return "EINCL, "; /* aux end of include file */ case 0xa4: return "ENTRY, "; /* alternate entry: name,linenumber,address */ case 0xc0: return "LBRAC, "; /* left bracket: 0,,0,nesting level,address */ case 0xc2: return "EXCL, "; /* placeholder for deleted include file */ case 0xe0: return "RBRAC, "; /* right bracket: 0,,0,nesting level,address */ case 0xe2: return "BCOMM, "; /* begin common: name,, */ case 0xe4: return "ECOMM, "; /* end common: name,, */ case 0xe8: return "ECOML, "; /* end common (local name): ,,address */ case 0xfe: return "LENG, "; /* second stab entry with length information */ } return stringify (type, 2, 'x', 0, "", ","); } /* Return a section's name. */ static const char * get_section_name (Elf32_Word sec_index) { Elf32_Shdr *sec_hdr; if (sec_index == 0) return ""; if (sec_index >= ehdr.e_shnum || ignore_string) return stringify (sec_index, 0, 'd', 0, "", ""); sec_hdr = SEC_PTR (sec_index); return elf_string ((Elf32_Word)ehdr.e_shstrndx, sec_hdr->sh_name); } /* Print the section body by invoking objdump -d on it. */ static void print_section_objdump (Elf32_Shdr *sec_hdr) { pid_t pid; fflush ((FILE *)0); pid = fork (); if (pid == -1) /* error, no fork */ perror ("fork"); else if (pid == 0) /* child context */ { const char *argv[6]; argv[0] = "objdump"; argv[1] = "-d"; argv[2] = "-j"; argv[3] = elf_string ((Elf32_Word)ehdr.e_shstrndx, sec_hdr->sh_name); argv[4] = file; argv[5] = (char *)0; execvp ("objdump", (char *const *) argv); execv ("/usr/ccs/gcc/objdump", (char *const *) argv); execv ("/usr/ccs/gcc-elf/objdump", (char *const *) argv); perror ("objdump"); fflush (stderr); _exit (1); } else /* parent context */ { int status = 0; void (*sigint)(int) = signal (SIGINT, SIG_IGN); void (*sigquit)(int) = signal (SIGQUIT, SIG_IGN); if (waitpid (pid, &status, 0) < 0) perror ("waitpid"); signal (SIGINT, sigint); signal (SIGQUIT, sigquit); if (status) { if (WIFSIGNALED (status)) fprintf (stderr, "objdump exited with signal %s\n", stringify (WTERMSIG (status), 0, 'd', 0, "", "")); else fprintf (stderr, "objdump exited with %s\n", stringify (WEXITSTATUS (status), 0, 'd', 0, "", "")); } } } /* Print the section body just as a series of integers. */ static void print_section_raw (Elf32_Shdr *sec_hdr) { Elf32_Word size = sec_hdr->sh_size; uchar_t *ptr = file_bytes + sec_hdr->sh_offset; int sec_off = 0; int width_off = stringify_len (size-1, 'd', 1); Elf32_Word value; union { Elf32_Word i; char c[4]; } u; if (objdump && (sec_hdr->sh_flags & SHF_EXECINSTR)) { print_section_objdump (sec_hdr); return; } while (size > 0) { if (size >= 4) { if ((((unsigned long)ptr) & ~3u) == 0) value = *(Elf32_Word *)ptr; else { memcpy (u.c, ptr, 4); value = u.i; } printf (" Offset %s: 0x%.8lx %11ld %s\n", stringify (sec_off, width_off, 'd', 0, "", ""), (long)value, (long)value, printable_string (ptr, 4)); sec_off += 4; ptr += 4; size -= 4; } else { value = *ptr; printf (" Offset %s: 0x%.2x %11d %s\n", stringify (sec_off, 5, 'd', 0, "", ""), (int)value, (int)value, printable_string (ptr, 1)); sec_off++; ptr++; size--; } } } /* Print the special .stab section. */ static void print_section_stab (Elf32_Shdr *sec_hdr) { Elf32_Word size = sec_hdr->sh_size; elf_stab_t *ptr = (elf_stab_t *)(file_bytes + sec_hdr->sh_offset); elf_stab_t *endptr = (elf_stab_t *)((char *)ptr + size); int width_soffset = 0; int width_type = 0; int width_other = 0; int width_desc = 0; int width_value = 0; int width_stab_num = stringify_len (endptr - ptr, 'd', 1); int stab_num = 0; Elf32_Word string_sect = 0; int len; Elf32_Word i; /* Look for .stabstr section */ for (i = 0; i < ehdr.e_shnum; i++) { if (strcmp (get_section_name (i), ".stabstr") == 0) { string_sect = i; break; } } /* Find lengths for everything. */ while (ptr < endptr) { len = stringify_len (ptr->soffset, 'd', 1); if (len > width_soffset) width_soffset = len; len = strlen (printable_stab_type (ptr->type)); if (len > width_type) width_type = len; len = stringify_len (ptr->desc, 'd', 1); if (len > width_desc) width_desc = len; len = stringify_len (ptr->value, 'd', 1); if (len > width_value) width_value = len; if (ptr->other) { len = stringify_len (ptr->other, 'd', 1); if (len > width_other) width_other = len; } ptr++; } /* Print fields out. */ ptr = (elf_stab_t *)(file_bytes + sec_hdr->sh_offset); while (ptr < endptr) { if (width_other) printf (" Stab #%s: type= %*s other= %s, desc= %s, value= %s, str offset= %s", stringify (++stab_num, width_stab_num, 'd', 0, "", ""), width_type, printable_stab_type (ptr->type), stringify (ptr->other, width_other, 'd', 0, "", ""), stringify (ptr->desc, width_desc, 'd', 0, "", ""), stringify (ptr->value, width_value, 'd', 0, "", ""), stringify (ptr->soffset, width_soffset, 'd', 0, "", "")); else printf (" Stab #%s: type= %*s desc= %s, value= %s, str offset= %s", stringify (++stab_num, width_stab_num, 'd', 0, "", ""), width_type, printable_stab_type (ptr->type), stringify (ptr->desc, width_desc, 'd', 0, "", ""), stringify (ptr->value, width_value, 'd', 0, "", ""), stringify (ptr->soffset, width_soffset, 'd', 0, "", "")); if (string_sect) printf (", str= %s\n", elf_string (string_sect, ptr->soffset)); else printf ("\n"); ptr++; } } /* Print the symbol table entries. */ static void print_section_symtab (Elf32_Shdr *sec_hdr) { Elf32_Word size = sec_hdr->sh_size; Elf32_Sym *ptr = (Elf32_Sym *)(file_bytes + sec_hdr->sh_offset); Elf32_Sym *endptr = (Elf32_Sym *)((char *)ptr + size); int sym_num = 0; int width_value = 0; int width_size = 0; int width_shndx = 0; int width_sym_num; int len; const char *type; const char *bind; const char *shndx; char width_buf[DIGIT_OUTPUT_SIZE + 20]; char size_buf[DIGIT_OUTPUT_SIZE + 20]; printf (" String table = \"%s\"\n\n", get_section_name (sec_hdr->sh_link)); /* Calculate minimum lengths */ width_sym_num = stringify_len (endptr - ptr, 'd', 1); while (ptr < endptr) { len = stringify_len (ptr->st_value, 'x', 1); if (width_value < len) width_value = len; if (ELF32_ST_TYPE (ptr->st_info) == STT_STABS) { len = sprintf (width_buf, "type= %s desc= %s,", printable_stab_type ((int)ELF32_STABS_TYPE (ptr->st_size)), stringify (ELF32_STABS_DESC (ptr->st_size), 0, 'd', 0, "", "")); if (ELF32_STABS_OTHER (ptr->st_size)) len += sprintf (width_buf, " other= %s,", stringify (ELF32_STABS_OTHER (ptr->st_size), 0, 'd', 0, "", "")); } else len = sprintf (width_buf, "size= %s,", stringify (ptr->st_size, 0, 'd', 0, "", "")); if (width_size < len) width_size = len; switch (ptr->st_shndx) { default: len = (ignore_string) ? stringify_len (ptr->st_shndx, 'd', 0) : strlen (get_section_name (ptr->st_shndx)); break; case SHN_UNDEF: len = sizeof ("undef")-1; break; case SHN_ABS: len = sizeof ("abs")-1; break; case SHN_COMMON: len = sizeof ("common")-1; break; } if (width_shndx < len) width_shndx = len; ptr++; } ptr = (Elf32_Sym *)(file_bytes + sec_hdr->sh_offset); while (ptr < endptr) { switch (ELF32_ST_BIND (ptr->st_info)) { default: bind = stringify (ELF32_ST_BIND (ptr->st_info), 0, 'd', 0, "", ","); break; case STB_LOCAL: bind = "local,"; break; case STB_GLOBAL: bind = "global,"; break; case STB_WEAK: bind = "weak,"; break; } switch (ELF32_ST_TYPE (ptr->st_info)) { default: type = stringify (ELF32_ST_TYPE (ptr->st_info), 0, 'd', 0, "", ","); break; case STT_NOTYPE: type = "none,"; break; case STT_OBJECT: type = "obj,"; break; case STT_FUNC: type = "func,"; break; case STT_SECTION: type = "sect,"; break; case STT_FILE: type = "file,"; break; case STT_STABS: type = "stab,"; break; } switch ((int)ptr->st_shndx) { default: shndx = (ignore_string) ? stringify (ptr->st_shndx, 0, 'd', 0, "", "") : get_section_name (ptr->st_shndx); break; case (int)SHN_UNDEF: shndx = "undef"; break; case (int)SHN_ABS: shndx = "abs"; break; case (int)SHN_COMMON: shndx = "common"; break; } if (ELF32_ST_TYPE (ptr->st_info) == STT_STABS) { len = sprintf (size_buf, "type= %s desc= %s,", printable_stab_type ((int)ELF32_STABS_TYPE (ptr->st_size)), stringify (ELF32_STABS_DESC (ptr->st_size), 0, 'd', 0, "", "")); if (ELF32_STABS_OTHER (ptr->st_size)) sprintf (size_buf + len, " other= %s,", stringify (ELF32_STABS_OTHER (ptr->st_size), 0, 'd', 0, "", "")); } else sprintf (size_buf, "size= %s,", stringify (ptr->st_size, 0, 'd', 0, "", "")); printf (" Sym %s: value= %s, %-*s sect= %s%-*s type= %-5s bind= %-7s name= %s\n", stringify (sym_num, width_sym_num, 'd', 0, "", ""), stringify (ptr->st_value, width_value, 'x', 0, "", ""), width_size, size_buf, shndx, width_shndx + 1 - (int)strlen (shndx), ",", type, bind, elf_string (sec_hdr->sh_link, ptr->st_name)); ptr++; sym_num++; } } /* Print the hash table. */ static void print_section_hash (Elf32_Shdr *sec_hdr) { Elf32_Word size = sec_hdr->sh_size; Elf32_Word *ptr = (Elf32_Word *)(file_bytes + sec_hdr->sh_offset); Elf32_Word *endptr = (Elf32_Word *)((char *)ptr + size); Elf32_Word nbucket = *ptr++; Elf32_Word nchain = *ptr++; Elf32_Word *hchain = ptr + nbucket; int loading; Elf32_Word i; Elf32_Word element; Elf32_Word next; int width; if (endptr != (ptr + nbucket + nchain)) { printf (" \n"); print_section_raw (sec_hdr); return; } width = stringify_len ((nchain > nbucket) ? nchain : nbucket, 'd', 1); printf (" Symbol table = \"%s\"\n", get_section_name (sec_hdr->sh_link)); printf (" # Buckets = %s\n", stringify (nbucket, width, 'd', 0, "", "")); printf (" # Elements = %s\n\n", stringify (nchain, width, 'd', 0, "", "")); for (i = 0; i < nbucket; i++) { loading = 1; element = *ptr; while ((next = hchain[element]) != 0) { loading++; element = next; } printf (" Bucket %s: first: %s, loading: %s\n", stringify (i, width, 'd', 0, "", ""), stringify (*ptr++, width, 'd', 0, "", ""), stringify (loading, width, 'd', 0, "", "")); } putchar ('\n'); for (i = 0; i < nchain; i++) printf (" Chain %s: %s\n", stringify (i, width, 'd', 0, "", ""), stringify (*ptr++, width, 'd', 0, "", "")); } /* Print the string section body. */ static void print_section_string (Elf32_Shdr *sec_hdr) { Elf32_Word size = sec_hdr->sh_size; char *ptr = (char *)(file_bytes + sec_hdr->sh_offset); char *endptr = ptr + size; int sec_off = 0; int len = 0; int width_off = stringify_len (size-1, 'd', 1); while (ptr < endptr) { if (*ptr != '\0' || sec_off == 0) printf (" Offset %s: \"%s\"\n", stringify (sec_off, width_off, 'd', 0, "", ""), ptr); len = strlen (ptr) + 1; ptr += len; sec_off += len; } } /* Decode a relocation type into a printable value. */ static const char * get_reloc_type (int type) { static const char *reloc_386[] = { "R_386_NONE,", "R_386_32,", "R_386_PC32,", "R_386_GOT,", "R_386_PLT32,", "R_386_COPY,", "R_386_GLOB_DAT,", "R_386_JMP_SLOT,", "R_386_RELATIVE,", "R_386_GOTOFF,", "R_386_GOTPC,", }; if (ehdr.e_machine == EM_386 && (unsigned)type < (sizeof (reloc_386) / sizeof (char *))) return reloc_386[type]; return stringify (type, 0, 'd', 0, "", ","); } /* Print RELA relocations. */ static void print_section_rela (Elf32_Shdr *sec_hdr) { Elf32_Word size = sec_hdr->sh_size; Elf32_Rela *ptr = (Elf32_Rela *)(file_bytes + sec_hdr->sh_offset); Elf32_Rela *endptr = (Elf32_Rela *)((char *)ptr + size); Elf32_Shdr *sym_sec = SEC_PTR (sec_hdr->sh_link); Elf32_Sym *sym_ptr = (Elf32_Sym *)(file_bytes + sym_sec->sh_offset); int rel_object_p = (ehdr.e_type == ET_REL); int rel_num = 0; int width_offset = 0; int width_info = 0; int width_sym = 0; int width_type = 0; int width_addend = 0; int width_rel_num; int sym_num; int len; Elf32_Word offset; const char *sect_or_undef; const char *name; const char *offset_value; printf (" Symbol table section = \"%s\"\n", get_section_name (sec_hdr->sh_link)); printf (" Section being relocated = \"%s\"\n\n", get_section_name (sec_hdr->sh_info)); /* Calculate minimum lengths */ width_rel_num = stringify_len (endptr - ptr, 'd', 1); while (ptr < endptr) { if (rel_object_p) offset = ptr->r_offset; else offset = ptr->r_offset - sec_hdr->sh_addr; len = stringify_len (offset, 'd', 1); if (width_offset < len) width_offset = len; len = stringify_len (ptr->r_info, 'd', 1); if (width_info < len) width_info = len; len = stringify_len (ELF32_R_SYM (ptr->r_info), 'd', 1); if (width_sym < len) width_sym = len; len = strlen (get_reloc_type (ELF32_R_TYPE (ptr->r_info))); if (width_type < len) width_type = len; len = stringify_len (ptr->r_addend, 'd', 0); if (width_addend < len) width_addend = len; ptr++; } ptr = (Elf32_Rela *)(file_bytes + sec_hdr->sh_offset); while (ptr < endptr) { if (rel_object_p) { offset = ptr->r_offset; offset_value = ""; } else { offset = ptr->r_offset - sec_hdr->sh_addr; offset_value = stringify (ptr->r_offset, 8, 'x', 0, " [", "]"); } sym_num = ELF32_R_SYM (ptr->r_info); switch ((int)sym_ptr[sym_num].st_shndx) { default: sect_or_undef = "internal"; break; case (int)SHN_UNDEF: sect_or_undef = "external"; break; case (int)SHN_COMMON: sect_or_undef = "common "; break; case (int)SHN_ABS: sect_or_undef = "absolute"; break; } name = elf_string (sym_sec->sh_link, sym_ptr[sym_num].st_name); printf (" Reloc %s: offset= %s%s, info= %s, sym= %s, type= %-*s addend= %s, %s \"%s\"\n", stringify (rel_num, width_rel_num, 'd', 0, "", ""), stringify (offset, width_offset, 'd', 0, "", ""), offset_value, stringify (ptr->r_info, width_info, 'd', 0, "", ""), stringify (sym_num, width_sym, 'd', 0, "", ""), width_type, get_reloc_type (ELF32_R_TYPE (ptr->r_info)), stringify (ptr->r_addend, width_addend, 'd', 0, "", ""), sect_or_undef, name); ptr++; rel_num++; } } /* Print REL relocations. */ static void print_section_rel (Elf32_Shdr *sec_hdr) { Elf32_Word size = sec_hdr->sh_size; Elf32_Rel *ptr = (Elf32_Rel *)(file_bytes + sec_hdr->sh_offset); Elf32_Rel *endptr = (Elf32_Rel *)((char *)ptr + size); Elf32_Shdr *sym_sec = SEC_PTR (sec_hdr->sh_link); Elf32_Sym *sym_ptr = (Elf32_Sym *)(file_bytes + sym_sec->sh_offset); Elf32_Shdr *data_sec = SEC_PTR (sec_hdr->sh_info); char *data_ptr = (char *)(file_bytes + data_sec->sh_offset); int rel_object_p = (ehdr.e_type == ET_REL); int rel_num = 0; int width_offset = 0; int width_info = 0; int width_sym = 0; int width_type = 0; int width_addend = 0; int width_rel_num; int sym_num; int len; Elf32_Word offset; const char *sect_or_undef; const char *name; const char *offset_value; const char *addend_value; union { Elf32_Word i; char c[sizeof (Elf32_Word)]; } addend; printf (" Symbol table section = \"%s\"\n", get_section_name (sec_hdr->sh_link)); printf (" Section being relocated = \"%s\"\n\n", get_section_name (sec_hdr->sh_info)); /* Calculate minimum lengths */ width_rel_num = stringify_len (endptr - ptr, 'd', 1); while (ptr < endptr) { if (rel_object_p) offset = ptr->r_offset; else offset = ptr->r_offset - sec_hdr->sh_addr; len = stringify_len (offset, 'd', 1); if (width_offset < len) width_offset = len; len = stringify_len (ptr->r_info, 'd', 1); if (width_info < len) width_info = len; len = stringify_len (ELF32_R_SYM (ptr->r_info), 'd', 1); if (width_sym < len) width_sym = len; len = strlen (get_reloc_type (ELF32_R_TYPE (ptr->r_info))); if (width_type < len) width_type = len; if (offset < data_sec->sh_size) { memcpy (addend.c, data_ptr + offset, sizeof (Elf32_Word)); len = stringify_len (addend.i, 'd', 0); } else len = sizeof ("error")-1; if (width_addend < len) width_addend = len; ptr++; } ptr = (Elf32_Rel *)(file_bytes + sec_hdr->sh_offset); while (ptr < endptr) { if (rel_object_p) { offset = ptr->r_offset; offset_value = ""; } else { offset = ptr->r_offset - sec_hdr->sh_addr; offset_value = stringify (ptr->r_offset, 8, 'x', 0, " [", "]"); } if (offset < data_sec->sh_size) { memcpy (addend.c, data_ptr + offset, sizeof (Elf32_Word)); addend_value = stringify (addend.i, 0, 'd', 0, "", ""); } else addend_value = "error"; sym_num = ELF32_R_SYM (ptr->r_info); switch ((int)sym_ptr[sym_num].st_shndx) { default: sect_or_undef = "internal"; break; case (int)SHN_UNDEF: sect_or_undef = "external"; break; case (int)SHN_COMMON: sect_or_undef = "common "; break; case (int)SHN_ABS: sect_or_undef = "absolute"; break; } name = elf_string (sym_sec->sh_link, sym_ptr[sym_num].st_name); printf (" Reloc %s: offset= %s%s, info= %s, sym= %s, type= %-*s addend= %*s, %s \"%s\"\n", stringify (rel_num, width_rel_num, 'd', 0, "", ""), stringify (offset, width_offset, 'd', 0, "", ""), offset_value, stringify (ptr->r_info, width_info, 'd', 0, "", ""), stringify (sym_num, width_sym, 'd', 0, "", ""), width_type, get_reloc_type (ELF32_R_TYPE (ptr->r_info)), width_addend, addend_value, sect_or_undef, name); ptr++; rel_num++; } } /* Print the dynamic link structures. */ static void print_section_dynamic (Elf32_Shdr *sec_hdr) { Elf32_Word size = sec_hdr->sh_size; Elf32_Dyn *ptr = (Elf32_Dyn *)(file_bytes + sec_hdr->sh_offset); Elf32_Dyn *endptr = (Elf32_Dyn *)((char *)ptr + size); int dyn_num = 0; int width_tag_str = 0; int width_val_num = 0; int width_dyn_num; int len; const char *tag; /* Calculate minimum lengths */ width_dyn_num = stringify_len (endptr - ptr, 'd', 1); while (ptr < endptr) { if (ptr->d_tag >= 0 && ptr->d_tag < sizeof (dyn_tag) / sizeof (dyn_tag[0])) len = strlen (dyn_tag[ ptr->d_tag ]); else len = stringify_len (ptr->d_tag, 'd', 1); if (width_tag_str < len) width_tag_str = len; len = stringify_len (ptr->d_un.d_val, 'd', 1); if (width_val_num < len) width_val_num = len; ptr++; } ptr = (Elf32_Dyn *)(file_bytes + sec_hdr->sh_offset); while (ptr < endptr) { if (ptr->d_tag >= 0 && ptr->d_tag < sizeof (dyn_tag) / sizeof (dyn_tag[0])) tag = dyn_tag[ ptr->d_tag ]; else tag = stringify (ptr->d_tag, 0, 'd', 0, "", ""); printf (" Dynamic record %s: tag= %*s, value= 0x%.8lx, %*ld\n", stringify (dyn_num, width_dyn_num, 'd', 0, "", ""), width_tag_str, tag, (long)ptr->d_un.d_val, width_val_num, (long)ptr->d_un.d_val); ptr++; dyn_num++; } } /* Print the profil section. */ static void print_section_profil (Elf32_Shdr *sec_hdr) { Elf32_Word size = sec_hdr->sh_size; uchar_t *ptr = file_bytes + sec_hdr->sh_offset; int sec_off = 0; int width_off = stringify_len (size, 'd', 1); int entsize = sec_hdr->sh_entsize; Elf32_Word value; printf (" Low pc = %s\n", stringify (sec_hdr->sh_link, width_off, 'x', 0, "", "")); printf (" High pc = %s\n\n", stringify (sec_hdr->sh_info, width_off, 'x', 0, "", "")); if ((size % entsize) != 0) { print_section_raw (sec_hdr); return; } if (entsize != sizeof (short) && entsize != sizeof (unsigned) #ifdef NEW_PROFILE && entsize != sizeof (LHISTCOUNTER) #endif && entsize != sizeof (long unsigned)) { print_section_raw (sec_hdr); return; } while (size > 0) { if (entsize == sizeof (short)) { if ((((unsigned long)ptr) & ~(sizeof(short) - 1)) == 0) value = *(short *)ptr; else { union { short i; char c[sizeof (short)]; } u; memcpy (u.c, ptr, sizeof (short)); value = u.i; } if (value) printf (" Offset %s: %s ticks\n", stringify (sec_off, width_off, 'd', 0, "", ""), stringify (value, 6, 'u', 0, "", "")); } else if (entsize == sizeof (unsigned)) { if ((((unsigned long)ptr) & ~(sizeof(unsigned) - 1)) == 0) value = *(unsigned *)ptr; else { union { unsigned i; char c[sizeof (unsigned)]; } u; memcpy (u.c, ptr, sizeof (unsigned)); value = u.i; } if (value) printf (" Offset %s: %s ticks\n", stringify (sec_off, width_off, 'd', 0, "", ""), stringify (value, 11, 'u', 0, "", "")); } else if (entsize == sizeof (long unsigned)) { if ((((unsigned long)ptr) & ~(sizeof(long unsigned) - 1)) == 0) value = *(long unsigned *)ptr; else { union { long unsigned i; char c[sizeof (long unsigned)]; } u; memcpy (u.c, ptr, sizeof (long unsigned)); value = u.i; } if (value) printf (" Offset %s: %s tick(s)\n", stringify (sec_off, width_off, 'd', 0, "", ""), stringify (value, 11, 'd', 0, "", "")); } #ifdef NEW_PROFILE else if (entsize == sizeof (LHISTCOUNTER)) { long double dvalue; if ((((unsigned long)ptr) & ~(sizeof(LHISTCOUNTER) - 1)) == 0) dvalue = LPROF_CNT_TO_LDOUBLE (*(LHISTCOUNTER *)ptr); else { union { LHISTCOUNTER i; char c[sizeof (LHISTCOUNTER)]; } u; memcpy (u.c, ptr, sizeof (LHISTCOUNTER)); dvalue = LPROF_CNT_TO_LDOUBLE (u.i); } if (dvalue) printf (" Offset %s: %16.0Lf tick(s)\n", stringify (sec_off, width_off, 'd', 0, "", ""), dvalue); } #endif else abort (); sec_off += entsize; ptr += entsize; size -= entsize; } } /* Print the gprof section. */ static void print_section_gprof (Elf32_Shdr *sec_hdr) { struct gprof_arc { long frompc; long selfpc; long count; } arc; Elf32_Word size = sec_hdr->sh_size; uchar_t *ptr = file_bytes + sec_hdr->sh_offset; int arc_num = 1; int width_arc = stringify_len ((size / sizeof (arc)), 'd', 1); int width_from = 0; int width_self = 0; int width_cnt = 0; int len; if (sec_hdr->sh_entsize != sizeof (arc) || (size % sizeof (arc)) != 0) { print_section_raw (sec_hdr); return; } while (size > 0) { memcpy ((void *)&arc, ptr, sizeof (arc)); len = stringify_len (arc.frompc, 'x', 1); if (len > width_from) width_from = len; len = stringify_len (arc.selfpc, 'x', 1); if (len > width_self) width_self = len; len = stringify_len (arc.count, 'd', 1); if (len > width_cnt) width_cnt = len; ptr += sizeof (arc); size -= sizeof (arc); } size = sec_hdr->sh_size; ptr = file_bytes + sec_hdr->sh_offset; while (size > 0) { memcpy ((void *)&arc, ptr, sizeof (arc)); printf (" Arc %s: Frompc= %s, Selfpc= %s, Count= %s\n", stringify (arc_num++, width_arc, 'd', 0, "", ""), stringify (arc.frompc, width_from, 'x', 0, "", ""), stringify (arc.selfpc, width_self, 'x', 0, "", ""), stringify (arc.count, width_cnt, 'd', 0, "", "")); ptr += sizeof (arc); size -= sizeof (arc); } } /* Print the prof section. */ static void print_section_prof (Elf32_Shdr *sec_hdr) { struct prof_arc { long selfpc; long count; } record; Elf32_Word size = sec_hdr->sh_size; uchar_t *ptr = file_bytes + sec_hdr->sh_offset; int rec_num = 1; int width_rec = stringify_len ((size / sizeof (record)), 'd', 1); int width_self = 0; int width_cnt = 0; int len; if (sec_hdr->sh_entsize != sizeof (record) || (size % sizeof (record)) != 0) { print_section_raw (sec_hdr); return; } while (size > 0) { memcpy ((void *)&record, ptr, sizeof (record)); len = stringify_len (record.selfpc, 'x', 1); if (len > width_self) width_self = len; len = stringify_len (record.count, 'd', 1); if (len > width_cnt) width_cnt = len; ptr += sizeof (record); size -= sizeof (record); } size = sec_hdr->sh_size; ptr = file_bytes + sec_hdr->sh_offset; while (size > 0) { memcpy ((void *)&record, ptr, sizeof (record)); printf (" Record %s: Selfpc= %s, Count= %s\n", stringify (rec_num++, width_rec, 'd', 0, "", ""), stringify (record.selfpc, width_self, 'x', 0, "", ""), stringify (record.count, width_cnt, 'd', 0, "", "")); ptr += sizeof (record); size -= sizeof (record); } } #ifdef __OSF1__ /* Print the uarea section in the profiling output. */ static void print_section_uarea (Elf32_Shdr *sec_hdr) { Elf32_Word size = sec_hdr->sh_size; struct user *ptr = (struct user *)(file_bytes + sec_hdr->sh_offset); print_section_raw (sec_hdr); if (size == sizeof (struct user)) { int width = 0; int len; time_t t = ptr->u_start.tv_sec; double u_time = ptr->u_ru.ru_utime.tv_sec + (ptr->u_ru.ru_utime.tv_usec / 1000000.0); double s_time = ptr->u_ru.ru_stime.tv_sec + (ptr->u_ru.ru_stime.tv_usec / 1000000.0); char buf[30]; len = sprintf (buf, "%.4f", u_time); if (len > width) width = len; len = sprintf (buf, "%.4f", s_time); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_maxrss, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_ixrss, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_idrss, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_isrss, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_minflt, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_majflt, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_nswap, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_inblock, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_oublock, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_msgsnd, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_msgrcv, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_nsignals, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_nvcsw, 'd', 1); if (len > width) width = len; len = stringify_len (ptr->u_ru.ru_nivcsw, 'd', 1); if (len > width) width = len; putchar ('\n'); printf (" u_comm = %s\n", ptr->u_comm); printf (" u_logname = %s\n", ptr->u_logname); printf (" u_start = %s", ctime (&t)); printf (" u_ru.ru_utime = %*.4f seconds\n", width, u_time); printf (" u_ru.ru_stime = %*.4f seconds\n", width, s_time); printf (" u_ru.ru_maxrss = %s [%s]\n", stringify (ptr->u_ru.ru_maxrss, width, 'd', 0, "", ""), "max memory size"); printf (" u_ru.ru_ixrss = %s [%s]\n", stringify (ptr->u_ru.ru_ixrss, width, 'd', 0, "", ""), "integral shared memory size"); printf (" u_ru.ru_idrss = %s [%s]\n", stringify (ptr->u_ru.ru_idrss, width, 'd', 0, "", ""), "integral unshared data"); printf (" u_ru.ru_isrss = %s [%s]\n", stringify (ptr->u_ru.ru_isrss, width, 'd', 0, "", ""), "integral unshared stack"); printf (" u_ru.ru_minflt = %s [%s]\n", stringify (ptr->u_ru.ru_minflt, width, 'd', 0, "", ""), "page reclaims"); printf (" u_ru.ru_majflt = %s [%s]\n", stringify (ptr->u_ru.ru_majflt, width, 'd', 0, "", ""), "page faults"); printf (" u_ru.ru_nswap = %s [%s]\n", stringify (ptr->u_ru.ru_nswap, width, 'd', 0, "", ""), "swaps"); printf (" u_ru.ru_inblock = %s [%s]\n", stringify (ptr->u_ru.ru_inblock, width, 'd', 0, "", ""), "block input operations"); printf (" u_ru.ru_oublock = %s [%s]\n", stringify (ptr->u_ru.ru_oublock, width, 'd', 0, "", ""), "block output operations"); printf (" u_ru.ru_msgsnd = %s [%s]\n", stringify (ptr->u_ru.ru_msgsnd, width, 'd', 0, "", ""), "messages sent"); printf (" u_ru.ru_msgrcv = %s [%s]\n", stringify (ptr->u_ru.ru_msgrcv, width, 'd', 0, "", ""), "messages received"); printf (" u_ru.ru_nsignals = %s [%s]\n", stringify (ptr->u_ru.ru_nsignals, width, 'd', 0, "", ""), "signals received"); printf (" u_ru.ru_nvcsw = %s [%s]\n", stringify (ptr->u_ru.ru_nvcsw, width, 'd', 0, "", ""), "voluntary context switches"); printf (" u_ru.ru_nivcsw = %s [%s]\n", stringify (ptr->u_ru.ru_nivcsw, width, 'd', 0, "", ""), "involuntary context switches"); } } #endif #ifdef NEW_PROFILE /* Print the stats section. */ static void print_section_stats (Elf32_Shdr *sec_hdr) { struct profile_stats *ptr = (struct profile_stats *)(file_bytes + sec_hdr->sh_offset); if (sec_hdr->sh_size != sizeof (struct profile_stats)) print_section_raw (sec_hdr); else _profile_print_stats(stdout, ptr, (profhdr_p) ? &profhdr : (struct profile_profil *)0); } #endif #ifdef NEW_PROFILE /* Print the profil header section. */ static void print_section_profhdr (Elf32_Shdr *sec_hdr) { struct profile_profil *ptr = (struct profile_profil *)(file_bytes + sec_hdr->sh_offset); if (sec_hdr->sh_size == sizeof (struct profile_profil)) { profhdr = *ptr; profhdr_p = 1; } print_section_raw (sec_hdr); } #endif /* Print the progbits section. */ static void print_section_progbits (Elf32_Shdr *sec_hdr) { const char *name = elf_string ((Elf32_Word)ehdr.e_shstrndx, sec_hdr->sh_name); if (strcmp (name, ".interp") == 0) print_section_string (sec_hdr); else if (no_progbits) printf (" Section body skipped...\n"); else if (strcmp (name, ".comment") == 0) print_section_string (sec_hdr); else if (strcmp (name, ".stab") == 0) print_section_stab (sec_hdr); else if (strcmp (name, ".stabstr") == 0) print_section_string (sec_hdr); else if (strcmp (name, ".debug_sfnames") == 0) print_section_string (sec_hdr); else if (sec_hdr->sh_type == SHT_PROGBITS && ehdr.e_type == ET_PROF) { if (strcmp (name, ".profil") == 0 || strcmp (name, ".lprofil") == 0) print_section_profil (sec_hdr); else if (strcmp (name, ".gprof") == 0) print_section_gprof (sec_hdr); else if (strcmp (name, ".prof") == 0) print_section_prof (sec_hdr); #ifdef __OSF1__ else if (strcmp (name, ".uarea") == 0) print_section_uarea (sec_hdr); #endif #ifdef NEW_PROFILE else if (strcmp (name, ".stats") == 0) print_section_stats (sec_hdr); else if (strcmp (name, ".profhdr") == 0) print_section_profhdr (sec_hdr); else print_section_raw (sec_hdr); #endif } else print_section_raw (sec_hdr); } /* Size the max fields in printing section headers. */ static void size_section (Elf32_Word sec_index) { Elf32_Shdr *sec_hdr = SEC_PTR (sec_index); const char *name; const char *sec_type; struct sec_list *sec_ptr; int len; name = get_section_name (sec_index); if (sec_index) /* skip dummy section */ { add_layout (&file_layout, name, sec_hdr->sh_offset, ((int)sec_hdr->sh_type == SHT_NOBITS) ? 0 : sec_hdr->sh_size, layout_free_no); if (ehdr.e_phnum && (sec_hdr->sh_flags & SHF_ALLOC)) add_layout (&vm_layout, name, sec_hdr->sh_addr, sec_hdr->sh_size, layout_free_no); } if (!summary) return; /* Skip section if desired. */ if (sections) { for (sec_ptr = sections; sec_ptr != (struct sec_list *)0; sec_ptr = sec_ptr->next) { if (strcmp (name, sec_ptr->section) == 0) break; } if (!sec_ptr) return; } len = stringify_len (sec_index, 'd', 1); if (len > sh_index_width) sh_index_width = len; len = strlen (name); if (len > sh_name_width) sh_name_width = len; switch ((int)sec_hdr->sh_type) { default: sec_type = stringify (sec_hdr->sh_type, 0, 'd', 0, "type=", ""); break; case SHT_NULL: sec_type = "none"; break; case SHT_PROGBITS: sec_type = "progbits"; break; case SHT_SYMTAB: sec_type = "symtab"; break; case SHT_STRTAB: sec_type = "strtab"; break; case SHT_RELA: sec_type = "rela"; break; case SHT_HASH: sec_type = "hash"; break; case SHT_DYNAMIC: sec_type = "dynamic"; break; case SHT_NOTE: sec_type = "note"; break; case SHT_NOBITS: sec_type = "nobits"; break; case SHT_REL: sec_type = "rel"; break; case SHT_SHLIB: sec_type = "shlib"; break; case SHT_DYNSYM: sec_type = "dynsym"; break; } len = strlen (sec_type); if (len > sh_type_width) sh_type_width = len; len = stringify_len (sec_hdr->sh_offset, 'd', 1); if (len > sh_start_width) sh_start_width = len; len = stringify_len (sec_hdr->sh_size, 'd', 1); if (len > sh_size_width) sh_size_width = len; len = stringify_len (sec_hdr->sh_offset + (((int)sec_hdr->sh_type == SHT_NOBITS) ? 0 : sec_hdr->sh_size), 'x', 1); if (len > sh_end_width) sh_end_width = len; len = stringify_len (sec_hdr->sh_addr, 'x', 1); if (len > sh_addr_width) sh_addr_width = len; len = stringify_len (sec_hdr->sh_addralign, 'd', 1); if (len > sh_align_width) sh_align_width = len; len = stringify_len (sec_hdr->sh_flags, 'x', 1); if (len > sh_flags_width) sh_flags_width = len; len = stringify_len (sec_hdr->sh_info, 'd', 1); if (len > sh_info_width) sh_info_width = len; len = stringify_len (sec_hdr->sh_link, 'd', 1); if (len > sh_link_width) sh_link_width = len; len = stringify_len (sec_hdr->sh_entsize, 'd', 1); if (len > sh_esize_width) sh_esize_width = len; } /* Print a section header. */ static void print_section (Elf32_Word sec_index) { Elf32_Shdr *sec_hdr = SEC_PTR (sec_index); const char *sec_type; const char *name; struct sec_list *sec_ptr; void (*sec_func)(Elf32_Shdr *); /* Skip section if desired. */ name = get_section_name (sec_index); if (sections) { for (sec_ptr = sections; sec_ptr != (struct sec_list *)0; sec_ptr = sec_ptr->next) { if (strcmp (name, sec_ptr->section) == 0) break; } if (!sec_ptr) return; } switch ((int)sec_hdr->sh_type) { default: sec_type = stringify (sec_hdr->sh_type, 0, 'd', 0, "type=", ""); sec_func = print_section_raw; break; case SHT_NULL: sec_type = "none"; sec_func = print_section_raw; break; case SHT_PROGBITS: sec_type = "progbits"; sec_func = print_section_progbits; break; case SHT_SYMTAB: sec_type = "symtab"; sec_func = print_section_symtab; break; case SHT_STRTAB: sec_type = "strtab"; sec_func = print_section_string; break; case SHT_RELA: sec_type = "rela"; sec_func = print_section_rela; break; case SHT_HASH: sec_type = "hash"; sec_func = print_section_hash; break; case SHT_DYNAMIC: sec_type = "dynamic"; sec_func = print_section_dynamic; break; case SHT_NOTE: sec_type = "note"; sec_func = print_section_raw; break; case SHT_NOBITS: sec_type = "nobits"; sec_func = print_section_raw; break; case SHT_REL: sec_type = "rel"; sec_func = print_section_rel; break; case SHT_SHLIB: sec_type = "shlib"; sec_func = print_section_raw; break; case SHT_DYNSYM: sec_type = "dynsym"; sec_func = print_section_symtab; break; } printf ("%sSect %s %-*s %-*s off=%s %s size=%s addr=%s align=%s flag=%s [%s%s%s] esize=%s info=%s link=%s\n", (!summary || sec_index == 0) ? "\n" : "", stringify (sec_index, sh_index_width, 'd', 0, "", ""), sh_name_width, name, sh_type_width, sec_type, stringify (sec_hdr->sh_offset, sh_start_width, 'x', 0, "", ""), stringify (sec_hdr->sh_offset + ((sec_hdr->sh_type == SHT_NOBITS) ? 0 : sec_hdr->sh_size), sh_end_width, 'x', 0, "", ""), stringify (sec_hdr->sh_size, sh_size_width, 'd', 0, "", ""), stringify (sec_hdr->sh_addr, sh_addr_width, 'x', 0, "", ""), stringify (sec_hdr->sh_addralign, sh_align_width, 'd', 0, "", ""), stringify (sec_hdr->sh_flags, sh_flags_width, 'x', 0, "", ""), (sec_hdr->sh_flags & SHF_EXECINSTR) ? "x" : "-", (sec_hdr->sh_flags & SHF_ALLOC) ? "a" : "-", (sec_hdr->sh_flags & SHF_WRITE) ? "w" : "-", stringify (sec_hdr->sh_entsize, sh_esize_width, 'd', 0, "", ""), stringify (sec_hdr->sh_info, sh_info_width, 'd', 0, "", ""), stringify (sec_hdr->sh_link, sh_link_width, 'd', 0, "", "")); if (sec_hdr->sh_size > 0 && sec_hdr->sh_type != SHT_NOBITS && !summary) { putchar ('\n'); (*sec_func) (sec_hdr); } } /* Print program headers. */ static void print_proghdr (void) { Elf32_Phdr *prog_hdr; const char *type; Elf32_Word ph_index; int width_index = stringify_len (ehdr.e_phnum, 'd', 1); int width_vaddr = 0; int width_vend = 0; int width_type = 0; int width_align = 0; int width_flags = 0; int width_offset = 0; int width_offend = 0; int width_filesz = 0; int width_memsz = 0; int len; char flags[4]; char *load_start; char *load_end; const char *load_num; putchar ('\n'); for (ph_index = 0; ph_index < ehdr.e_phnum; ph_index++) { prog_hdr = PROGHDR_PTR (ph_index); switch ((int)prog_hdr->p_type) { default: type = stringify (prog_hdr->p_type, 0, 'd', 0, "type=", ""); break; case PT_NULL: type = "null,"; break; case PT_LOAD: type = "load,"; break; case PT_DYNAMIC: type = "dynamic,"; break; case PT_INTERP: type = "interp,"; break; case PT_NOTE: type = "note,"; break; case PT_SHLIB: type = "shlib,"; break; case PT_PHDR: type = "proghdr,"; break; } len = strlen (type); if (len > width_type) width_type = len; len = stringify_len (prog_hdr->p_vaddr, 'x', 1); if (len > width_vaddr) width_vaddr = len; len = stringify_len (prog_hdr->p_vaddr + prog_hdr->p_memsz, 'x', 1); if (len > width_vend) width_vend = len; len = stringify_len (prog_hdr->p_align, 'd', 1); if (len > width_align) width_align = len; len = stringify_len (prog_hdr->p_flags, 'x', 1); if (len > width_flags) width_flags = len; len = stringify_len (prog_hdr->p_offset, 'x', 1); if (len > width_offset) width_offset = len; len = stringify_len (prog_hdr->p_offset + prog_hdr->p_filesz, 'x', 1); if (len > width_offend) width_offend = len; len = stringify_len (prog_hdr->p_filesz, 'd', 1); if (len > width_filesz) width_filesz = len; len = stringify_len (prog_hdr->p_memsz, 'd', 1); if (len > width_memsz) width_memsz = len; } for (ph_index = 0; ph_index < ehdr.e_phnum; ph_index++) { prog_hdr = PROGHDR_PTR (ph_index); switch ((int)prog_hdr->p_type) { default: type = stringify (prog_hdr->p_type, 0, 'd', 0, "type=", ""); break; case PT_NULL: type = "null,"; break; case PT_LOAD: type = "load,"; break; case PT_DYNAMIC: type = "dynamic,"; break; case PT_INTERP: type = "interp,"; break; case PT_NOTE: type = "note,"; break; case PT_SHLIB: type = "shlib,"; break; case PT_PHDR: type = "proghdr,"; break; } flags[0] = (prog_hdr->p_flags & PF_R) ? 'r' : '-'; flags[1] = (prog_hdr->p_flags & PF_W) ? 'w' : '-'; flags[2] = (prog_hdr->p_flags & PF_X) ? 'x' : '-'; flags[3] = '\0'; printf ("Hdr %s: %-*s vaddr= %s %s, align= %s, flags= %s [%s], off= %s %s, filesz= %s, memsz= %s\n", stringify (ph_index, width_index, 'd', 0, "", ""), width_type, type, stringify (prog_hdr->p_vaddr, width_vaddr, 'x', 0, "", ""), stringify (prog_hdr->p_vaddr + prog_hdr->p_memsz, width_vend, 'x', 0, "", ""), stringify (prog_hdr->p_align, width_align, 'd', 0, "", ""), stringify (prog_hdr->p_flags, width_flags, 'x', 0, "", ""), flags, stringify (prog_hdr->p_offset, width_offset, 'x', 0, "", ""), stringify (prog_hdr->p_offset + prog_hdr->p_filesz, width_offend, 'x', 0, "", ""), stringify (prog_hdr->p_filesz, width_filesz, 'd', 0, "", ""), stringify (prog_hdr->p_memsz, width_memsz, 'd', 0, "", "")); if ((int)prog_hdr->p_type == PT_LOAD) { load_num = stringify (ph_index, 0, 'd', 0, "", ""); len = strlen (load_num) + strlen (flags); load_start = (char *) xmalloc (sizeof("Load cmd #, region start []") + len); sprintf (load_start, "Load cmd #%s, region start [%s]", load_num, flags); add_layout (&vm_layout, load_start, prog_hdr->p_vaddr, 0, layout_free_no); add_layout (&file_layout, load_start, prog_hdr->p_offset, 0, layout_free_yes); load_end = (char *) xmalloc (sizeof("Load cmd #, region end []") + len); sprintf (load_end, "Load cmd #%s, region end [%s]", load_num, flags); add_layout (&vm_layout, load_end, prog_hdr->p_vaddr + prog_hdr->p_memsz, 0, layout_free_no); add_layout (&file_layout, load_end, prog_hdr->p_offset + prog_hdr->p_filesz, 0, layout_free_yes); } } } /* Scan for linker generated symbols, and put them in the VM layout */ static void find_linker_symbols (void) { int i; Elf32_Shdr *sec_hdr; const char *name; Elf32_Sym *ptr; Elf32_Sym *endptr; layout_t *layout_ptr; for (i = 0; i < ehdr.e_shnum; i++) { sec_hdr = SEC_PTR (i); if ((int)sec_hdr->sh_type != SHT_SYMTAB && (int)sec_hdr->sh_type != SHT_DYNSYM) continue; ptr = (Elf32_Sym *)(file_bytes + sec_hdr->sh_offset); endptr = (Elf32_Sym *)((char *)ptr + sec_hdr->sh_size); for ( ; ptr < endptr; ptr++) { name = elf_string (sec_hdr->sh_link, ptr->st_name); if (name[0] == '\0') continue; switch ((name[0] << 16) | (name[1] << 8) | name[2]) { default: continue; case (('_' << 16) | ('G' << 8) | 'L'): if (strcmp (name, "_GLOBAL_OFFSET_POINTER") != 0) continue; break; case (('_' << 16) | ('e' << 8) | 'n'): if (strcmp (name, "_end") != 0) continue; break; case (('_' << 16) | ('e' << 8) | 'd'): if (strcmp (name, "_edata") != 0) continue; break; case (('_' << 16) | ('e' << 8) | 't'): if (strcmp (name, "_etext") != 0) continue; break; case (('e' << 16) | ('n' << 8) | 'd'): if (strcmp (name, "end") != 0) continue; break; case (('e' << 16) | ('d' << 8) | 'a'): if (strcmp (name, "edata") != 0) continue; break; case (('e' << 16) | ('t' << 8) | 'e'): if (strcmp (name, "etext") != 0) continue; break; } for (layout_ptr = vm_layout; layout_ptr != (layout_t *)0; layout_ptr = layout_ptr->next) { if (layout_ptr->name == name) break; if (layout_ptr->name[0] == name[0] && strcmp (layout_ptr->name, name) == 0) break; } if (layout_ptr == (layout_t *)0) add_layout (&vm_layout, name, ptr->st_value, 0, layout_free_no); } } } int main(int argc, char *argv[]) { int argnum; Elf32_Word i; int letter; int ch; while ((letter = getopt (argc, argv, "deln:pst:vx")) != EOF) { switch (letter) { default: errors++; break; case 'd': /* invoke objdump to disassemble text sections */ objdump = 1; break; case 'e': /* put linker generated symbols in the VM layout */ linker_symbols = 1; break; case 'l': /* skip printing layout information */ no_layout = 1; break; case 'n': /* print a specific section */ { struct sec_list *p = (struct sec_list *) xmalloc (sizeof (struct sec_list)); p->next = sections; p->section = optarg; sections = p; break; } case 'p': /* skip printing the progbits section body */ no_progbits = 1; break; case 's': /* print just the summary information */ summary = 1; break; case 't': /* specify output format */ format = ch = tolower (*optarg); if (optarg[1] != '\0' || (ch != 'd' && ch != 'x' && ch != 'o' && ch != 'u' & ch != 'i')) { fprintf (stderr, "-t %s is not 'i', 'd', 'o', 'u', or 'x'\n", optarg); errors++; } break; case 'v': /* print version string */ print_vers = 1; break; case 'x': /* string table pointer is invalid */ ignore_string = 1; break; } } if (errors || optind >= argc) { fprintf (stderr, "Calling sequence:\n\n"); fprintf (stderr, "\telfdump [-n name]... [-delpsx] [-t format] files...\n"); fprintf (stderr, "\nwhere:\n\n"); fprintf (stderr, "-d\tInvoke objdump -d for executable sections.\n"); fprintf (stderr, "-e\tPut the linker generated symbols in the vm layout.\n"); fprintf (stderr, "-l\tDo not print file/VM layout information.\n"); fprintf (stderr, "-n name\tOnly print section 'name'\n"); fprintf (stderr, "-p\tDo not print the body of a progbits section.\n"); fprintf (stderr, "-s\tOnly print section header summary information.\n"); fprintf (stderr, "-t fmt\tSpecify output format for numbers (i, d, o, u, or x).\n"); fprintf (stderr, "-v\tPrint version number.\n"); fprintf (stderr, "-x\tAssume the string table is corrupt.\n"); return 1; } if (print_vers) printf ("%s\n\n", elfdump_what_string); for (argnum = optind; (file = argv[argnum]) != (char *)0; argnum++) { if (argnum > optind) printf ("\f====================\n\n"); /* Map in the file. */ if (stat (file, &file_stat) < 0 || (file_fd = open (file, O_RDONLY)) < 0 || (file_bytes = (uchar_t *) mmap ((caddr_t)0, (size_t)file_stat.st_size, PROT_READ, MAP_PRIVATE|MAP_FILE|MAP_VARIABLE, file_fd, (off_t)0)) == (uchar_t *)-1) { perror (file); errors++; continue; } ehdr = *(Elf32_Ehdr *)file_bytes; if (file_stat.st_size < sizeof (ehdr) || memcmp (ehdr.e_ident, "\177ELF", 4) != 0) { fprintf (stderr, "%s is not an ELF file.\n", file); errors++; continue; } if (ehdr.e_ehsize != sizeof (ehdr)) { fprintf (stderr, "%s elf header is %s bytes, expected %s\n", file, stringify (ehdr.e_ehsize, 0, 'd', 0, "", ""), stringify (sizeof (ehdr), 0, 'd', 0, "", "")); errors++; continue; } add_layout (&file_layout, "Global header", 0, sizeof (ehdr), layout_free_no); if (ehdr.e_shnum) add_layout (&file_layout, "Section headers", ehdr.e_shoff, ehdr.e_shnum * ehdr.e_shentsize, layout_free_no); if (ehdr.e_phnum) add_layout (&file_layout, "Program headers", ehdr.e_phoff, ehdr.e_phnum * ehdr.e_phentsize, layout_free_no); printf ("File: %s", file); switch (ehdr.e_type) { default: printf (", type %d", ehdr.e_type); break; case ET_NONE: printf (", no file type"); break; case ET_REL: printf (", relocatable"); break; case ET_EXEC: printf (", executable"); break; case ET_DYN: printf (", shared object"); break; case ET_CORE: printf (", core file"); break; case ET_PROF: printf (", profile output"); break; } switch (ehdr.e_machine) { default: printf (", machine %d", ehdr.e_machine); break; case EM_NONE: printf (", no machine"); break; case EM_M32: printf (", we 32100"); break; case EM_SPARC: printf (", sparc"); break; case EM_386: printf (", i386"); break; case EM_68K: printf (", m68k"); break; case EM_88K: printf (", m88k"); break; case EM_860: printf (", i860"); break; case EM_MIPS: printf (", mips"); break; } switch (ehdr.e_ident[EI_CLASS]) { default: printf (", class %d", ehdr.e_ident[EI_CLASS]); break; case ELFCLASS32: printf (", 32-bit"); break; case ELFCLASS64: printf (", 64-bit"); break; } switch (ehdr.e_ident[EI_DATA]) { default: printf (", data %d", ehdr.e_ident[EI_DATA]); break; case ELFDATA2LSB: printf (", little endian"); break; case ELFDATA2MSB: printf (", big endian"); break; } printf ("\nversion = %s, elf header size = %s, entry = %s\n", stringify (ehdr.e_version, 0, 'd', 0, "", ""), stringify (ehdr.e_ehsize, 0, 'd', 0, "", ""), stringify (ehdr.e_entry, 8, 'x', 0, "", "")); printf ("flags = %s, section header string index = %s\n", stringify (ehdr.e_flags, 8, 'x', 0, "", ""), stringify (ehdr.e_shstrndx, 0, 'd', 0, "", "")); printf ("# sections = %s, section element size = %s, section offset = %s\n", stringify (ehdr.e_shnum, 2, 'd', 0, "", ""), stringify (ehdr.e_shentsize, 2, 'd', 0, "", ""), stringify (ehdr.e_shoff, 6, 'd', 0, "", "")); printf ("# headers = %s, header element size = %s, header offset = %s\n\n", stringify (ehdr.e_phnum, 2, 'd', 0, "", ""), stringify (ehdr.e_phentsize, 2, 'd', 0, "", ""), stringify (ehdr.e_phoff, 6, 'd', 0, "", "")); /* Print each of the sections now. */ for (i = 0; i < ehdr.e_shnum; i++) size_section (i); for (i = 0; i < ehdr.e_shnum; i++) print_section (i); /* Print each of the program headers now. */ if (ehdr.e_phnum != 0) print_proghdr (); /* Print the layout information if desired */ if (!no_layout) { print_layout (file_layout, "ELF file"); if (ehdr.e_phnum) { if (linker_symbols) find_linker_symbols (); print_layout (vm_layout, "Virtual Memory"); } } if (file_bytes != (uchar_t *)-1) munmap ((caddr_t)file_bytes, (size_t)file_stat.st_size); if (file_fd >= 0) close (file_fd); if (file_layout) free_layout (&file_layout); if (vm_layout) free_layout (&vm_layout); } return (errors) ? 1 : 0; } From erich@uruk.org Fri Nov 11 10:21:00 1994 From: erich@uruk.org (Erich Stefan Boleyn) Date: Fri, 11 Nov 1994 10:21:00 -0000 Subject: traditional Intel & Microsoft formats... References: <199411110653.WAA01871@cygnus.com> Message-ID: <199411111824.KAA25854@uruk.org> John Gilmore writes: > I applaud your effort to support more file formats... EEK! I didn't say I was doing all of the file formats. I was asking who is working on/interested in/might be interested in those formats. Having said that, I'll probably end up doing some to support them. My major project(s) is the dynamic linker, then an emulation/dynamic translation system. > ...in the hope of > making it possible to run (proprietary or free) programs from the > PC world on GNU systems. Have you examined the Wine emulator > for Windows programs? And the "sim" directory of instruction-set > simulators in the GDB releases? Yes, I have a fairly complete list of instruction-set emulators for the more recent chips out there (no offense, but supporting such things as the Apple II is of little or no interest to me ;-). The WINE project is intersting, but I don't think it is of large enough scope without a fast binary emulator out there. Considering that an OS emulation must be done in addition to the binary emulation, it may well be that large parts of the WINE project get used. > Some of us have similar dreams... I'm glad to hear that. Actually, I traded e-mail messages with Micheal Bushnell (of the HURD, though most of you know that) about this topic, and he mentioned interest in the same goal. I've started putting together a design/concept doc with the info I have so far. This is both to flush out the ideas, and to get feedback, as a useful emulator can be a tricky business. On a practical level, it would also be to drum up support, since the whole project is pretty big, and supporting some formats that otherwise might be ignored would be necessary. Oh, yes... it's a moral obligation to call it SPAM, for "Synthetic Processing on Aribitrary Machines" or somesuch ;-). > By the way, it looks to me like Windows DLL linking is remarkably like > dynamic linking on SVR4 or SunOS. Since the GNU Linker now supports > dynamic linking (which was, indeed, a fair bit of work), making it > handle DLL's is probably not as big a job as you think. MS-Windows 3.1 DLLs have their own weirdness to deal with, though I tend to agree that it isn't a huge job. DLLs are supported directly by the MS runtime loader. > The way to support any of these formats is to write a new BFD > back-end. It's really pretty easy. Look at one of the simple ones > that isn't full of macros -- say, binary.c or tekhex.c or srec.c or > oasys.c. (The macro-ized bfd target code is to support seventeen > variants of a.out or COFF on seventeen Unix machines.) To read a new > file format, you only need to write a dozen functions (check file > format, get section info, get section contents, get symbol table size, > get symbol table, etc). Once you get this simple stuff into a BFD > target, you get immense leverage from the already-99%-working code > in the assembler, linker, binutils, and GDB that calls BFD. Really, what I'm looking to do with an "emulator" scheme is to extend the BFD to have a runtime for dealing with other OSs and hardware architectures on most any machine. The existence of the BFD and its leverage is what's going to make this possible in the first place. Let's just finish the job ;-). Erich -- Erich Stefan Boleyn \__ E-mail (preferred): Mathematician, Software Engineer \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 From rms@gnu.ai.mit.edu Fri Nov 11 10:31:00 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) Date: Fri, 11 Nov 1994 10:31:00 -0000 Subject: [masaki@eie.monolta.co.jp: GAS bug and etc] References: <9411111450.AA12152@delorie> Message-ID: <9411111830.AA21125@mole.gnu.ai.mit.edu> Supporting 16-bit mode assembly for the 386 is not harmful if it is easy, but if it takes up a lot of time, then it might be better off left out. Do we need to have a program that runs in 16-bit mode for booting? If so, how big a program would it have to be? (I presume all it needs to do is switch to 32-bit mode.) Might it be easier to hand assemble that program than to add and subsequently maintain this gas feature? From dj@stealth.ctron.com Fri Nov 11 10:46:00 1994 From: dj@stealth.ctron.com (DJ Delorie) Date: Fri, 11 Nov 1994 10:46:00 -0000 Subject: [masaki@eie.monolta.co.jp: GAS bug and etc] References: <9411111830.AA21125@mole.gnu.ai.mit.edu> Message-ID: <9411111848.AA05929@delorie> > Supporting 16-bit mode assembly for the 386 is not harmful if it is > easy, but if it takes up a lot of time, then it might be better off > left out. Do we need to have a program that runs in 16-bit mode for > booting? If so, how big a program would it have to be? (I presume > all it needs to do is switch to 32-bit mode.) Might it be easier to > hand assemble that program than to add and subsequently maintain this > gas feature? Even when in protected mode, the 386 and up processors support variable width operations. For example, when C calls for a "short", the 386 uses a 16-bit register and thus needs 16-bit operations. This has nothing to do with the runtime mode of the CPU or the default size of the segment (16 vs 32), and must be supported on all 386-based systems, including Hurd. The theory is that since gas must already support these 16-bit instructions for the i386 anyway, it should be trivial to tell it that the *default* size should be assumed different, so that it would produce code that assumed it was running in a 16-bit segment instead of a 32-bit segment. Then, the only work that would need to be done is to produce dos-style OMF output, which is also used for some 32-bit systems. As for the separate topic of bootstrapping 32-bit programs in the 16-bit world of DOS, we've got that covered already, so that you can fully bootstrap djgpp 2.0 with nothing but GNU tools. We wrote a VERY simple 16-bit assembler with which to assemble the bootstrap code. DJ From mycroft@gnu.ai.mit.edu Fri Nov 11 13:42:00 1994 From: mycroft@gnu.ai.mit.edu (mycroft@gnu.ai.mit.edu) Date: Fri, 11 Nov 1994 13:42:00 -0000 Subject: [masaki@eie.monolta.co.jp: GAS bug and etc] Message-ID: <9411112139.AA00683@goldman.gnu.ai.mit.edu> The problem with using the 16-bit jcxz is that, even if the offset is small, if the target isn't in the first 64K of memory, the program is toast. The reason is that %eip is masked to 0x0000ffff AFTER adding the offset. The comment you're referring to: rel16/32 indicates that these instructions map to two; one with a 16-bit relative displacement, the other with a 32-bit relative displacement, depending on the operand-size attribute of the instruction. only applies to the `rel16/32' versions of the conditional jump instructions. The JCXZ and JECXZ instructions do not allow 16- or 32-bit displacements. The `Operation' section for that instruction should be more clear. BTW, why are you using JCXZ or JECXZ at all? The equivalent sequence: testl %ecx,%ecx jz ... is the same speed on the 386, but faster on the Pentium (and probably the 486, but I don't have those timing specs). From rms@gnu.ai.mit.edu Fri Nov 11 13:42:00 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) Date: Fri, 11 Nov 1994 13:42:00 -0000 Subject: Elfdump References: <9411111638.AA06307@pasta.osf.org> Message-ID: <9411112141.AA21468@mole.gnu.ai.mit.edu> * fee, provided that the above copyright notice appears in all copies and * that both the copyright notice and this permission notice appear in * supporting documentation. Requirements like this about supporting documentation are somewhat obnoxious -- as well as legally unenforceable in the US from what I've heard -- because they impose a requirement on separate and independent works. So I've decided we should avoid such programs except when they are very necessary. Is there any possibility you could remove that clause from the terms? From rms@gnu.ai.mit.edu Fri Nov 11 14:27:00 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) Date: Fri, 11 Nov 1994 14:27:00 -0000 Subject: [masaki@eie.monolta.co.jp: GAS bug and etc] References: <9411111848.AA05929@delorie> Message-ID: <9411112227.AA21589@mole.gnu.ai.mit.edu> The theory is that since gas must already support these 16-bit instructions for the i386 anyway, it should be trivial to tell it that the *default* size should be assumed different, so that it would produce code that assumed it was running in a 16-bit segment instead of a 32-bit segment. Well, if the theory holds true, this won't cost us much. Then, the only work that would need to be done is to produce dos-style OMF output, which is also used for some 32-bit systems. This isn't useful for the GNU system at all; it should have lower priority than work that does help the GNU project. That's crucial for people who would work either on this or on some other GNU work. I hope they'll make sure they are not spending substantial time on this. From artk@congruent.com Fri Nov 11 14:58:00 1994 From: artk@congruent.com (Arthur Kreitman) Date: Fri, 11 Nov 1994 14:58:00 -0000 Subject: Elfdump References: <9411112141.AA21468@mole.gnu.ai.mit.edu> Message-ID: <9411112248.AA18043@Congruent.COM> > Date: Fri, 11 Nov 94 16:41:59 -0500 > From: rms@gnu.ai.mit.edu (Richard Stallman) > > * fee, provided that the above copyright notice appears in all copies and > * that both the copyright notice and this permission notice appear in > * supporting documentation. > > Requirements like this about supporting documentation are somewhat > obnoxious -- as well as legally unenforceable in the US from what I've > heard -- because they impose a requirement on separate and independent > works. Is a binary that comes from your source code a separate work? From artk@congruent.com Fri Nov 11 15:01:00 1994 From: artk@congruent.com (Arthur Kreitman) Date: Fri, 11 Nov 1994 15:01:00 -0000 Subject: [masaki@eie.monolta.co.jp: GAS bug and etc] References: <9411112227.AA21589@mole.gnu.ai.mit.edu> Message-ID: <9411112245.AA17970@Congruent.COM> > Date: Fri, 11 Nov 94 17:27:20 -0500 > From: rms@gnu.ai.mit.edu (Richard Stallman) > > The theory is that since gas must already support these 16-bit > instructions for the i386 anyway, it should be trivial to tell it that > the *default* size should be assumed different, so that it would > produce code that assumed it was running in a 16-bit segment instead > of a 32-bit segment. > > Well, if the theory holds true, this won't cost us much. > > Then, the only work that would need to be done > is to produce dos-style OMF output, which is also used for some 32-bit > systems. > > This isn't useful for the GNU system at all; it should have lower > priority than work that does help the GNU project. That's crucial for > people who would work either on this or on some other GNU work. I > hope they'll make sure they are not spending substantial time on this. I would also point out that if you're interested, as I am, in being compatible with the Evil Empire (Microsoft), that the value of any omf or sixteen bit work will be zero real soon. From rms@gnu.ai.mit.edu Sat Nov 12 08:41:00 1994 From: rms@gnu.ai.mit.edu (Richard Stallman) Date: Sat, 12 Nov 1994 08:41:00 -0000 Subject: Elfdump References: <9411112248.AA18043@Congruent.COM> Message-ID: <9411121641.AA25070@mole.gnu.ai.mit.edu> > Date: Fri, 11 Nov 94 16:41:59 -0500 > From: rms@gnu.ai.mit.edu (Richard Stallman) > > * fee, provided that the above copyright notice appears in all copies and > * that both the copyright notice and this permission notice appear in > * supporting documentation. > > Requirements like this about supporting documentation are somewhat > obnoxious -- as well as legally unenforceable in the US from what I've > heard -- because they impose a requirement on separate and independent > works. Is a binary that comes from your source code a separate work? No, but I don't follow the point. The issue I'm talking about has to do with documentation, not binaries. From meissner@osf.org Mon Nov 14 06:50:00 1994 From: meissner@osf.org (Michael Meissner) Date: Mon, 14 Nov 1994 06:50:00 -0000 Subject: Elfdump References: <9411111638.AA06307@pasta.osf.org> <9411112141.AA21468@mole.gnu.ai.mit.edu> <9411112141.AA21468@mole.gnu.ai.mit.edu> Message-ID: <9411141449.AA16266@pasta.osf.org> | * fee, provided that the above copyright notice appears in all copies and | * that both the copyright notice and this permission notice appear in | * supporting documentation. | | Requirements like this about supporting documentation are somewhat | obnoxious -- as well as legally unenforceable in the US from what I've | heard -- because they impose a requirement on separate and independent | works. | | So I've decided we should avoid such programs except when they are | very necessary. | | Is there any possibility you could remove that clause from the terms? No. I was just offering elfdump in case it was useful. From hjl@nynexst.com Mon Nov 21 20:09:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Mon, 21 Nov 1994 20:09:00 -0000 Subject: bin86 0.2 is released. References: <199411190328.WAA15221@calum.csclub.uwaterloo.ca> Message-ID: <9411220408.AA14356@titanic.nynexst.com> > We seem to have cross bin86 for Solaris working. The most important > changes involve alignment (it needs to be on) and byte ordering. > Some of the patches just eliminate compiler warnings (conversion of > pointer to integer without a cast, etc.) and some (in the Makefiles) > reflect the local setup, and can probably be ignored (the change to $BINDIR, > for example). > Thanks a lot. I release it as bin86 0.2 with some minor modifications. The primary ftp sites for the compiler/C library are tsx-11.mit.edu under pub/linux/packages/GCC/private/dontuse and sunsite.unc.edu under pub/Linux/GCC/private/dontuse. The two secondary ftp sites are i44s10.info.uni-karlsruhe.de under pub/linux/libc/private/dontuse and ftp.ctd.comsat.com under pub/linux/alpha. Gals, Guys, I'd like to hear the cross-compile kernel stories. I tried it under SunOS 4.1.3. But the kernel code has a few endian dependent code in ./zBoot. H.J. ------ To build this real mode as/ld for x86, just edit Makefile and then do make install It is only tested under SunOS 4.1.3 and Linux. H.J. Lu hjl@nynexst.com 11/21/94 ------ We seem to have cross bin86 for Solaris working. The most important changes involve alignment (it needs to be on) and byte ordering. Some of the patches just eliminate compiler warnings (conversion of pointer to integer without a cast, etc.) and some (in the Makefiles) reflect the local setup, and can probably be ignored (the change to $BINDIR, for example). - Ian (iagoldbe@csclub.uwaterloo.ca) ---- I modified it for the latest Linux C library 4.5.21 and released it as bin86 0.1. It is only tested for building the Linux kernel and is not intended for any other purposes. To build it under Linux, just type make all make install It is not tested for cross-compiling. If you have any patches for cross-compiling, please send them to me. Thanks. H.J. Lu hjl@nynexst.com 03/03/94 ------------- This is the as86 and ld86 distribution written by Bruce Evans. It's copyright Bruce Evans, all rights reserved although you may use and copy it for your personal use. It's a complete 8086 assembler and loader which can make 32-bit code for the 386+ processors (under linux it's used only to create the 16-bit bootsector and setup binaries). The syntax is not compatible with the GNU assembler, but closer to intel syntax ("wrong" order of operands etc). Hints for compiling: - you'll need the a.out.h-files from the a.out.h directory for the linker. These aren't really part of the distribution, but I included them for ease of setup (in case you need to crosscompile etc). Do a cp a.out.h/* ld/ or similar before compiling the linker. - the assembler needs the typeconv.o file produced by the linker compilation. So compile the linker first, and then do a cp ld/typeconv.o as/ before making the assembler. This distribution also contains some test-files etc that aren't actually needed, but as they also give some idea of the assembler syntax, I left them in. The directories are as follows: as - the assembler sources (minus typeconv.c) ld - linker sources bcc - bruce evans' cc frontend sources (the actual compiler isn't included). bccfp - assembly floating point routines written by bruce evans. Note that these use integer register returns, and won't work with the linux libraries. They can be used as examples of as86 code. a.out.h - header files for crosscompilation. Note that I am NOT the author of this package, but I'll forward any comments to bruce evans and I'll try to answer any questions about the assembler/linker I can. I just made it available as bde doesn't have ftp capability right now. Bruce Evans does have mail as . Linus Torvalds From iagoldbe@calum.csclub.uwaterloo.ca Mon Nov 21 20:41:00 1994 From: iagoldbe@calum.csclub.uwaterloo.ca (Ian Goldberg) Date: Mon, 21 Nov 1994 20:41:00 -0000 Subject: Cross-compiling the kernel (Was: binx86 0.2) References: <9411220408.AA14356@titanic.nynexst.com> Message-ID: <199411220430.XAA21657@calum.csclub.uwaterloo.ca> > Gals, Guys, I'd like to hear the cross-compile kernel stories. I > tried it under SunOS 4.1.3. But the kernel code has a few endian > dependent code in ./zBoot. We fixed those endian problems in zBoot and tools/build. We now have a working cross-compile for the Linux kernel that should work on any big- or little-endian machine with the appropriate tools (a cross- compiler/assembler, etc). The patches to the Makefiles and the zBoot and tools stuff have been sent to Linus. The 1.1.64 kernel I'm using right now was compiled on a Solaris 2.3 machine. ---------.. ._ _.------------ Ian Goldberg University of Waterloo PM+CS iagoldberg@csclub.uwaterloo.ca foo(a) { return (a?foo(a&a-1)+1:0); } From dj@stealth.ctron.com Wed Nov 23 10:42:00 1994 From: dj@stealth.ctron.com (DJ Delorie) Date: Wed, 23 Nov 1994 10:42:00 -0000 Subject: Cabletron power outage Message-ID: <9411231842.AA17462@delorie> Cabletron will be powered down tonight (11/23) until Monday morning (11/28) to upgrade our backup generator. Mail will be offline for more than the three day timeout, so if you see any rejects from "...@ctron.com", please either ignore them or hold them until Monday and re-mail. Thanks, DJ dj@ctron.com From hjl@nynexst.com Wed Nov 23 18:41:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 23 Nov 1994 18:41:00 -0000 Subject: Does the ELF gas support stabs like a.out does? Message-ID: <9411240240.AA20822@titanic.nynexst.com> Hi, It seems the ELF gas doesn't support stabs like the a.out version does. That piece code is used to put __init_misc () on the __libc_subinit list. It doesn't work with the ELF gas. Is there aother way to create a list using the ELF gas without create a new subsection? Thanks. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com ---- # gcc-aout -c foo.s # nm foo.o 00000000 T __init_misc 00000000 - 00 0000 (4) __libc_subinit # gcc-elf -c foo.s # nm foo.o 00000000 T __init_misc -----foo.s---- .text .align 4 .globl __init_misc __init_misc: ret .stabs "__libc_subinit",23,0,0,__init_misc From baford@schirf.cs.utah.edu Fri Nov 25 07:56:00 1994 From: baford@schirf.cs.utah.edu (Bryan Ford) Date: Fri, 25 Nov 1994 07:56:00 -0000 Subject: Patch: support for 16-bit i386 code. Message-ID: <199411251550.IAA14047@schirf.cs.utah.edu> I finally just decided to do this myself; wasn't too hard. This patch creates '.code16' and '.code32' pseudo-opcodes for i386 gas, which determine whether it writes 16-bit or 32-bit code. When writing 16-bit code, it still only uses 32-bit addressing modes, so the resulting code is suboptimal; but how much performance-critical 16-bit code is there these days anyway? :-) BTW, this patch is to binutils-2.5.2. Please acknowledge that you've received it and when you expect it'll appear in a release. Thanks! *** include/opcode/old/i386.h Fri Nov 25 07:11:50 1994 --- include/opcode/i386.h Fri Nov 25 08:09:00 1994 *************** *** 36,43 **** conflict with the "movs" string move instruction. Thus, {"movsb", 2, 0x0fbe, _, ReverseRegRegmem|Modrm, { Reg8|Mem, Reg16|Reg32, 0} }, is not kosher; we must seperate the two instructions. */ ! {"movsbl", 2, 0x0fbe, _, ReverseRegRegmem|Modrm, { Reg8|Mem, Reg32, 0} }, ! {"movsbw", 2, 0x660fbe, _, ReverseRegRegmem|Modrm, { Reg8|Mem, Reg16, 0} }, {"movswl", 2, 0x0fbf, _, ReverseRegRegmem|Modrm, { Reg16|Mem, Reg32, 0} }, /* move with zero extend */ --- 36,43 ---- conflict with the "movs" string move instruction. Thus, {"movsb", 2, 0x0fbe, _, ReverseRegRegmem|Modrm, { Reg8|Mem, Reg16|Reg32, 0} }, is not kosher; we must seperate the two instructions. */ ! {"movsbl", 2, 0x0fbe, _, ReverseRegRegmem|Modrm|Data32, { Reg8|Mem, Reg32, 0} }, ! {"movsbw", 2, 0x0fbe, _, ReverseRegRegmem|Modrm|Data16, { Reg8|Mem, Reg16, 0} }, {"movswl", 2, 0x0fbf, _, ReverseRegRegmem|Modrm, { Reg16|Mem, Reg32, 0} }, /* move with zero extend */ *************** *** 167,181 **** /* conversion insns */ /* conversion: intel naming */ ! {"cbw", 0, 0x6698, _, NoModrm, { 0, 0, 0} }, ! {"cwd", 0, 0x6699, _, NoModrm, { 0, 0, 0} }, ! {"cwde", 0, 0x98, _, NoModrm, { 0, 0, 0} }, ! {"cdq", 0, 0x99, _, NoModrm, { 0, 0, 0} }, /* att naming */ ! {"cbtw", 0, 0x6698, _, NoModrm, { 0, 0, 0} }, ! {"cwtl", 0, 0x98, _, NoModrm, { 0, 0, 0} }, ! {"cwtd", 0, 0x6699, _, NoModrm, { 0, 0, 0} }, ! {"cltd", 0, 0x99, _, NoModrm, { 0, 0, 0} }, /* Warning! the mul/imul (opcode 0xf6) must only have 1 operand! They are expanding 64-bit multiplies, and *cannot* be selected to accomplish --- 167,181 ---- /* conversion insns */ /* conversion: intel naming */ ! {"cbw", 0, 0x98, _, NoModrm|Data16, { 0, 0, 0} }, ! {"cwd", 0, 0x99, _, NoModrm|Data16, { 0, 0, 0} }, ! {"cwde", 0, 0x98, _, NoModrm|Data32, { 0, 0, 0} }, ! {"cdq", 0, 0x99, _, NoModrm|Data32, { 0, 0, 0} }, /* att naming */ ! {"cbtw", 0, 0x98, _, NoModrm|Data16, { 0, 0, 0} }, ! {"cwtl", 0, 0x98, _, NoModrm|Data32, { 0, 0, 0} }, ! {"cwtd", 0, 0x99, _, NoModrm|Data16, { 0, 0, 0} }, ! {"cltd", 0, 0x99, _, NoModrm|Data32, { 0, 0, 0} }, /* Warning! the mul/imul (opcode 0xf6) must only have 1 operand! They are expanding 64-bit multiplies, and *cannot* be selected to accomplish *************** *** 321,334 **** {"jnle", 1, 0x7f, _, Jump, { Disp, 0, 0} }, {"jg", 1, 0x7f, _, Jump, { Disp, 0, 0} }, /* these turn into pseudo operations when disp is larger than 8 bits */ #define IS_JUMP_ON_CX_ZERO(o) \ (o == 0x66e3) #define IS_JUMP_ON_ECX_ZERO(o) \ (o == 0xe3) ! {"jcxz", 1, 0x66e3, _, JumpByte, { Disp, 0, 0} }, ! {"jecxz", 1, 0xe3, _, JumpByte, { Disp, 0, 0} }, #define IS_LOOP_ECX_TIMES(o) \ (o == 0xe2 || o == 0xe1 || o == 0xe0) --- 321,339 ---- {"jnle", 1, 0x7f, _, Jump, { Disp, 0, 0} }, {"jg", 1, 0x7f, _, Jump, { Disp, 0, 0} }, + #if 0 /* XXX where are these macros used? + To get them working again, they need to take + an entire template as the parameter, + and check for Data16/Data32 flags. */ /* these turn into pseudo operations when disp is larger than 8 bits */ #define IS_JUMP_ON_CX_ZERO(o) \ (o == 0x66e3) #define IS_JUMP_ON_ECX_ZERO(o) \ (o == 0xe3) + #endif ! {"jcxz", 1, 0xe3, _, JumpByte|Data16, { Disp, 0, 0} }, ! {"jecxz", 1, 0xe3, _, JumpByte|Data32, { Disp, 0, 0} }, #define IS_LOOP_ECX_TIMES(o) \ (o == 0xe2 || o == 0xe1 || o == 0xe0) *************** *** 432,439 **** /* i386sl (and i486sl?) only */ {"rsm", 0, 0x0faa, _, NoModrm,{ 0, 0, 0} }, ! {"boundl", 2, 0x62, _, Modrm, { Reg32, Mem, 0} }, ! {"boundw", 2, 0x6662, _, Modrm, { Reg16, Mem, 0} }, {"hlt", 0, 0xf4, _, NoModrm, { 0, 0, 0} }, {"wait", 0, 0x9b, _, NoModrm, { 0, 0, 0} }, --- 437,444 ---- /* i386sl (and i486sl?) only */ {"rsm", 0, 0x0faa, _, NoModrm,{ 0, 0, 0} }, ! {"boundl", 2, 0x62, _, Modrm|Data32, { Reg32, Mem, 0} }, ! {"boundw", 2, 0x62, _, Modrm|Data16, { Reg16, Mem, 0} }, {"hlt", 0, 0xf4, _, NoModrm, { 0, 0, 0} }, {"wait", 0, 0x9b, _, NoModrm, { 0, 0, 0} }, *************** *** 808,813 **** --- 813,819 ---- }; static const prefix_entry i386_prefixtab[] = { + #define ADDR_PREFIX_OPCODE 0x67 { "addr16", 0x67 }, /* address size prefix ==> 16bit addressing * (How is this useful?) */ #define WORD_PREFIX_OPCODE 0x66 *** gas/config/old/tc-i386.h Fri Nov 25 06:34:23 1994 --- gas/config/tc-i386.h Fri Nov 25 08:06:26 1994 *************** *** 125,131 **** #define tc_headers_hook(a) {;} /* not used */ #define MAX_OPERANDS 3 /* max operands per insn */ ! #define MAX_PREFIXES 4 /* max prefixes per opcode */ #define MAX_IMMEDIATE_OPERANDS 2/* max immediates per insn */ #define MAX_MEMORY_OPERANDS 2 /* max memory ref per insn (lcall uses 2) */ --- 125,131 ---- #define tc_headers_hook(a) {;} /* not used */ #define MAX_OPERANDS 3 /* max operands per insn */ ! #define MAX_PREFIXES 5 /* max prefixes per opcode */ #define MAX_IMMEDIATE_OPERANDS 2/* max immediates per insn */ #define MAX_MEMORY_OPERANDS 2 /* max memory ref per insn (lcall uses 2) */ *************** *** 263,268 **** --- 263,270 ---- #define JumpByte 0x4000 #define JumpDword 0x8000 #define ReverseRegRegmem 0x10000 + #define Data16 0x20000 /* needs data prefix if in 32-bit mode */ + #define Data32 0x40000 /* needs data prefix if in 16-bit mode */ /* (opcode_modifier & COMES_IN_ALL_SIZES) is true if the instuction comes in byte, word, and dword sizes and is encoded into *** gas/config/old/tc-i386.c Fri Nov 25 06:34:23 1994 --- gas/config/tc-i386.c Fri Nov 25 08:37:02 1994 *************** *** 174,179 **** --- 174,181 ---- static int flag_do_long_jump; /* FIXME what does this do? */ + static int flag_16bit_code; /* 1 if we're writing 16-bit code, 0 if 32-bit */ + /* Interface to relax_segment. There are 2 relax states for 386 jump insns: one for conditional & one for unconditional jumps. This is because the these two types *************** *** 318,323 **** --- 320,331 ---- : (Imm32)); } /* smallest_imm_type() */ + void set_16bit_code_flag(new_16bit_code_flag) + int new_16bit_code_flag; + { + flag_16bit_code = new_16bit_code_flag; + } + const pseudo_typeS md_pseudo_table[] = { #ifndef I386COFF *************** *** 334,339 **** --- 342,349 ---- {"value", cons, 2}, {"noopt", s_ignore, 0}, {"optim", s_ignore, 0}, + {"code16", set_16bit_code_flag, 1}, + {"code32", set_16bit_code_flag, 0}, {0, 0, 0} }; *************** *** 1034,1039 **** --- 1044,1064 ---- i.tm = *t; t = &i.tm; /* alter new copy of template */ + /* If the matched instruction specifies an explicit opcode suffix, + use it - and make sure none has already been specified. */ + if (t->opcode_modifier & (Data16|Data32)) + { + if (i.suffix) + { + as_bad ("extraneous opcode suffix given"); + return; + } + if (t->opcode_modifier & Data16) + i.suffix = WORD_OPCODE_SUFFIX; + else + i.suffix = DWORD_OPCODE_SUFFIX; + } + /* If there's no opcode suffix we try to invent one based on register operands. */ if (!i.suffix && i.reg_operands) *************** *** 1117,1123 **** t->base_opcode |= W; /* Now select between word & dword operations via the operand size prefix. */ ! if (i.suffix == WORD_OPCODE_SUFFIX) { if (i.prefixes == MAX_PREFIXES) { --- 1142,1148 ---- t->base_opcode |= W; /* Now select between word & dword operations via the operand size prefix. */ ! if ((i.suffix == WORD_OPCODE_SUFFIX) ^ flag_16bit_code) { if (i.prefixes == MAX_PREFIXES) { *************** *** 1383,1388 **** --- 1408,1427 ---- if (t->extension_opcode != None) i.rm.reg = t->extension_opcode; } + + /* GAS currently doesn't support 16-bit memory addressing modes at all, + so if we're writing 16-bit code and using a memory addressing mode, + always spew out an address size prefix. */ + if ((i.rm.mode != 3) && flag_16bit_code) + { + if (i.prefixes == MAX_PREFIXES) + { + as_bad ("%d prefixes given and address size override gives too many prefixes", + MAX_PREFIXES); + return; + } + i.prefix[i.prefixes++] = ADDR_PREFIX_OPCODE; + } } } } *************** *** 1470,1475 **** --- 1509,1527 ---- { int size = (t->opcode_modifier & JumpByte) ? 1 : 4; unsigned long n = i.disps[0]->X_add_number; + unsigned char *q; + + /* The jcx/jecx instruction might need a data size prefix. + XXX would it be OK just to output all the prefixes? */ + for (q = i.prefix; q < i.prefix + i.prefixes; q++) + { + if (*q == WORD_PREFIX_OPCODE) + { + p = frag_more (1); + insn_size += 1; + md_number_to_chars (p, (valueT) *q, 1); + } + } if (fits_in_unsigned_byte (t->base_opcode)) { Bryan --- Bryan Ford baford@cs.utah.edu University of Utah, CSS `finger baford@schirf.cs.utah.edu' for PGP key and other info. From ian@cygnus.com Sun Nov 27 16:42:00 1994 From: ian@cygnus.com (Ian Lance Taylor) Date: Sun, 27 Nov 1994 16:42:00 -0000 Subject: Does the ELF gas support stabs like a.out does? References: <9411240240.AA20822@titanic.nynexst.com> Message-ID: <9411280042.AA00282@tweedledumb.cygnus.com> From: hjl@nynexst.com (H.J. Lu) Date: Wed, 23 Nov 94 21:40:24 EST It seems the ELF gas doesn't support stabs like the a.out version does. That piece code is used to put __init_misc () on the __libc_subinit list. It doesn't work with the ELF gas. That is correct. The symbol set features of a.out are not supported in ELF. I don't particularly like symbol sets, and, more importantly, they can not be efficiently supported in the ELF linker. All normal uses of symbol sets can be handled using either weak symbols or separate sections in ELF. Is there aother way to create a list using the ELF gas without create a new subsection? No. Creating a new section is the way to go. glibc uses symbol sets in various ways. Roland McGrath and I have worked out how they will be ported to ELF. You may want to ask exactly what he plans to do in glibc, and copy it. Part of it is that the linker will automatically define special symbols marking the start and end of any sections whose names can be represented as C identifiers. The symbols for section SEC are named __start_SEC and __stop_SEC. Ian From hjl@nynexst.com Wed Nov 30 19:21:00 1994 From: hjl@nynexst.com (H.J. Lu) Date: Wed, 30 Nov 1994 19:21:00 -0000 Subject: A tough bug in mixing two binary formats in the linker Message-ID: <9412010321.AA02574@titanic.nynexst.com> There is a very tough bug dealing with mixing two binary formats. bfd_check_format_matches () does a very poor job checking the binary format used by the contents in an archive. If two different binary format .o files are archived by the same ar, from headers two .a files look the same. If the linker is called with: ld -m binary_format_1 foo.a which foo.a is in binary_format_2, bfd_check_format_matches () will match foo.a with binary_format_1 since it only looks at the header of foo.a. One possible solution is set _bfd_check_format [bfd_archive] to a function which not only checks the header of an archive, but also check what's inside. If bfd_generic_archive_p () is only used for that purpose, it should be fixed. Has anyone been working on it? I don't know enough about BFD. Probably my patch will break other stuff :-(. BTW, if there are more than one binary formats in an archive, we will be in a even bigger mess :-(. -- H.J. Lu NYNEX Science and Technology, Inc. hjl@nynexst.com From dj@stealth.ctron.com Sun Dec 18 16:47:00 1994 From: dj@stealth.ctron.com (DJ Delorie) Date: Sun, 18 Dec 1994 16:47:00 -0000 Subject: diffs for binutils-2.5.2 for djgpp Message-ID: <9412190047.AA14658@delorie> Extracting this file will yield one file of diffs per file to be modified. Sun Dec 18 19:29:00 1994 DJ Delorie [.] * install.bat: new file for djgpp users to install with [gas] * config/tc-i386.h: don't assume coff means local==".L". gcc checks for underscores; gas checks for a.out; djgpp is coff with underscores, so gcc and gas had disagreed. begin 400 binutils-2.5.2.diffs.tar.gz M'XL("-C2]"X"`&)N=61I9F9S+G1A<@#ME6UOVC`0QWE+I7Z'$Y-*22'/@9:I MTNA&IVW9>-%.JK1.47`<53OWPLQ,@:5GIIK5"D_P3D/CLN__%YQP! M"4.F#4D\2TG$5-,QM<1RH@$!_<%T,P&EW',.R.E:;CSN6:57`J4A> MFF"]_B.?:=NMOZ%S!UG_+=8?T3@D(VU;]3ZB>/0/7,3^$=1F!TP#CJVH== M0^P(1N<:91$"Y1)[S,M_!R4>O-_AZ+FP\8;[@;<_UW-Y)W]V/_0EN0';YIG^'XV.HJW6X%,NK5=C;6TP9^91;A[L[*%LN MUBQJO=$HJYWV/O5S,>]+CS\RWP#]4M>-6K;W1077:EE*\\P[/;VO[CKJ;)O3=U M>[W([A.8)-?H"BBF"JJN4?GG.F M,EUEKY(X+`8IGG,7HW`(*"I>SM+#\RG^]UIZ=):ER&WKC_*;N4V9<4G^3W(_ M@X56,EFW:XJ:NQ:914&16!2LY5.8-J7!5Q%%_/[A;DP3&A:RJ^%*=679)+II A[V6KD$@D$HE$(I%()!*)1"*12"02R7_$+[=T_SH`*``` ` end