From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: Mark Kettenis Cc: gdb@sourceware.cygnus.com Subject: Re: GDB & FreeBSD Date: Tue, 23 May 2000 12:43:00 -0000 Message-id: <5m3dn99ho5.fsf@jtc.redback.com> References: <200005211217.e4LCHPv00623@delius.kettenis.local> X-SW-Source: 2000-05/msg00117.html Mark> I spent some time on reviving GDB on FreeBSD. Not too difficult Mark> since it turns out that I can re-use a lot of code from the Mark> NetBSD port (thanks J.T. :-)). Your welcome. Mark> However, in doing so, I've probably killed support for older Mark> FreeBSD systems (I suspect that the same happened with NetBSD). If so, it wasn't the intent. The earliest machines I have are running 1.3. If it turns out I broke an earlier release, I'll fix it. But I'm not planning on installing NetBSD 0.9 just to check... I'd rather spend the time to get i386/ELF support into the tree. --jtc -- J.T. Conklin RedBack Networks >From jtc@redback.com Tue May 23 12:53:00 2000 From: jtc@redback.com (J.T. Conklin) To: Cc: Subject: Re: Breakpoint on Memory Range? Date: Tue, 23 May 2000 12:53:00 -0000 Message-id: <5mya5182nx.fsf@jtc.redback.com> References: <000001bfc4d2$7424ac80$1923a8c0@cat.co.za> X-SW-Source: 2000-05/msg00118.html Content-length: 829 >>>>> "Riaz" == Riaz writes: Riaz> Does GDB 5.0 (i386 NetBSD) offer the ability to stop execution Riaz> when there has been a "write" to a memory range? GDB supports watchpoints, that can be used to see if a memory variable is changed. The watchpoint command takes an expression, not a memory range, as its argument; although I suppose that you could construct a expression that would fit your range. Even if this works, it will be slow. Riaz> I specifically need to know whether my code is being overwritten. I think this is unlikely, unless you are dynamically generating code on the stack, in the heap or in the data segment. The .text (code) segment is mapped read only. Any attempt to overwrite your code should result in a segmentation violation. --jtc -- J.T. Conklin RedBack Networks >From ac131313@cygnus.com Tue May 23 18:58:00 2000 From: Andrew Cagney To: Larry Cohen Cc: help-gcc@gnu.org, gdb@sourceware.cygnus.com Subject: Re: Request for status on fix for limitations with g77 -fdebug_kludge option Date: Tue, 23 May 2000 18:58:00 -0000 Message-id: <392B36FA.67079BC8@cygnus.com> References: <002d01bfc4b8$b0343020$1b2731cc@FWB.SAIC.Com> X-SW-Source: 2000-05/msg00119.html Content-length: 1036 Larry Cohen wrote: > > To Whom It May Concern; > > I have recently downloaded and installed gcc-2.95.2 and gdb-5.0 packages > for the purposes of compiling and running FORTRAN-77 programs. The gcc > package documentation states that gdb is currently incapable of printing > out the values of variables that are part of COMMON BLOCK storage and > that rudimentary COMMON BLOCK variable information could be retrieved > within gdb by invoking the -fdebug-kludge option during the g77 compile > process. Also, the documentation states that this limitation in > printing out the explicit value of a COMMON BLOCK variable will be fixed > in some future release of gcc and gdb. Would you please send me any > information about when these future gcc and gdb releases (that print out > the value of a COMMON BLOCK variable) will occur. FYI, At present there is no active Fortran GDB maintainer and effectivly zero activity on GDB's support for fortran :-( Definitly an oportunity in the making for anyone interested. Andrew >From guy@netapp.com Tue May 23 21:22:00 2000 From: Guy Harris To: gdb@sourceware.cygnus.com Subject: On Digital UNIX, "continue" doesn't continue correctly if a signal isdelivered Date: Tue, 23 May 2000 21:22:00 -0000 Message-id: <200005240422.VAA19399@tooting> X-SW-Source: 2000-05/msg00120.html Content-length: 4264 On Digital UNIX/Alpha, we have a program that has an interval timer set up to continuously deliver signals; with GDB 4.18, we find that if you stop at a breakpoint, and then try to continue from that breakpoint, it doesn't continue - instead, it stops again at the same breakpoint. The same thing happens with the GDB that was in the CVS tree as of a short while ago. The problem appears to be that various tests in "wait_for_inferior()", which test whether the current SP is for a frame closer to the top of the stack than the frame for "step_sp" (or "step_sp - 16") fail, because "step_sp" hasn't been set. When continuing from the breakpoint (with the PRSTEP flag set in the "pr_flags" field of the structure passed to PIOCRUN, so that it executes only one instruction), it stops in "__sigtramp", as a SIGALRM was delivered to the process in the interval since the breakpoint trap; however, GDB doesn't realize that it's in the signal trampoline, and doesn't properly continue, so that when it next gets a breakpoint trap after returning from the signal, as it presumably re-executes the breakpoint instruction, it doesn't realize that it should drive on, and it just stops. "step_sp" gets set by "step_1()", "step_once()", and "until_next_command()", presumably because all those routines call "proceed()" with "step" set; however, "step_sp" isn't set by "continue_command()" or any routine between "continue_command()" and "proceed()", presumably because "proceed()" isn't called with "step" set in that code path. However, "proceed()" will be single-stepping, because we're resuming from a breakpoint, and we need to step over the instruction at which the breakpoint was placed and then put the breakpoint back, as per: if (addr == (CORE_ADDR) -1) { /* If there is a breakpoint at the address we will resume at, step one instruction before inserting breakpoints so that we do not stop right away (and report a second hit at this breakpoint). */ if (read_pc () == stop_pc && breakpoint_here_p (read_pc ())) oneproc = 1; in "proceed()". Making "proceed()" set "step_frame_address" and "step_sp" if "oneproc" is set but "step" isn't set appears to fix the problem: Index: gdb/infrun.c =================================================================== RCS file: /cvs/src/src/gdb/infrun.c,v retrieving revision 1.14 diff -c -r1.14 gdb/infrun.c *** gdb/infrun.c 2000/05/22 09:02:23 1.14 --- gdb/infrun.c 2000/05/24 03:44:38 *************** *** 1040,1048 **** #endif /* HP_OS_BUG */ if (oneproc) ! /* We will get a trace trap after one instruction. ! Continue it automatically and insert breakpoints then. */ ! trap_expected = 1; else { int temp = insert_breakpoints (); --- 1040,1058 ---- #endif /* HP_OS_BUG */ if (oneproc) ! { ! /* We will get a trace trap after one instruction. ! Continue it automatically and insert breakpoints then. */ ! trap_expected = 1; ! ! /* Oh, and if we weren't explicitly told to single-step, our ! caller may not have updated "step_sp", so do it ourselves. */ ! if (!step) ! { ! step_frame_address = FRAME_FP (get_current_frame ()); ! step_sp = read_sp (); ! } ! } else { int temp = insert_breakpoints (); Whether this is the right way to fix this is another matter. (For example, perhaps "proceed()" should always set "step_frame_address" and "step_sp" if it will be passing a non-zero value as the first argument to "resume()", and the routines in "gdb/infcmd.c" that set them should leave it up to "proceed()" to do so.) I've attached a small sample program which exhibits the problem; if run with "clock" as an argument, it sets up a timer to repeatedly deliver SIGALRM, and if you set a breakpoint on "procedure()", run the program, and then type "continue", it will stop again in "procedure()" without printing "Hello", indicating that it hasn't continued from the breakpoint. However, if run with "noclock" as an argument, so that it doesn't repeatedly get SIGALRM, it *will* print "Hello" before stopping again at "procedure()". Applying the patch above makes "continue" behave correctly regardless of whether the program was run with "clock" or "noclock". >From kettenis@wins.uva.nl Wed May 24 01:34:00 2000 From: Mark Kettenis To: ldm@ilog.fr, chrisd@reservoir.com, wim.delvaux@desc.com Cc: gdb@sourceware.cygnus.com Subject: Re: bug in gdb-5.0 & shared libraries on Solaris 7 Date: Wed, 24 May 2000 01:34:00 -0000 Message-id: <200005240834.e4O8Y6c00547@delius.kettenis.local> References: <00052401214900.31315@buro> X-SW-Source: 2000-05/msg00121.html Content-length: 536 Wow, three bug reports for the same problem in one day! We should probably make fixing this a real priority :-). Anyway, thanks for reporting. The following patch will fix the problems with setting breakpoints in dynamically loaded objects: http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00230.html This patch isn't checked in yet (ping Michael/JimB), but I hope this will be in the next GDB release. There should really be a test in the testsuite for this problem, since it keeps coming up :-(. Any volunteers? Mark >From moene@knmi.nl Wed May 24 02:54:00 2000 From: Toon Moene To: gdb@sourceware.cygnus.com Subject: Re: Request for status on fix for limitations with g77 -fdebug_kludge option Date: Wed, 24 May 2000 02:54:00 -0000 Message-id: <392BA6A9.ACE682F@knmi.nl> X-SW-Source: 2000-05/msg00122.html Content-length: 969 Andrew Cagney wrote: >Larry Cohen wrote: >> The gcc >> package documentation states that gdb is currently incapable of printing >> out the values of variables that are part of COMMON BLOCK storage and >> that rudimentary COMMON BLOCK variable information could be retrieved >> within gdb by invoking the -fdebug-kludge option during the g77 compile >> process. > At present there is no active Fortran GDB maintainer and effectivly > zero activity on GDB's support for fortran :-( While this is true, to the best of my knowledge the issue with printing COMMON BLOCK items in gdb has been solved (it was a limitation of the way g77 wrote debug information). The solution is in the CVS mainline of GCC. Pick any recent snapshot of GCC if you can't use CVS and see if using just -g solves your problem. -- Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands. Tel. +31302206443, Fax +31302210407, e-mail moene@knmi.nl URL: http://www.knmi.nl/hirlam >From kevinb@cygnus.com Wed May 24 09:55:00 2000 From: Kevin Buettner To: gdb@sourceware.cygnus.com Cc: gdb-patches@sourceware.cygnus.com Subject: PARAMS removal this weekend Date: Wed, 24 May 2000 09:55:00 -0000 Message-id: <1000524165459.ZM30150@ocotillo.lan> X-SW-Source: 2000-05/msg00123.html Content-length: 1030 Earlier this week, I posted a patch for removing most occurrences of PARAMS from the gdb sources. See: http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00330.html I have seen no objections to this patch and Andrew has suggested that I specify a date and time for when this patch goes in. So at 5:00 pm MST of Saturday, May 27 (which is midnight GMT on Sunday), I'll tag the repository, do the PARAMS removal on the gdb directory, and tag it again. I will use gdb-pre-params-removal-2000-05-28 and gdb-post-params-removal-2000-05-28 for the tags. (I'm not sure how long it will take to do all of this, but I wouldn't be surprised if it were a couple of hours.) Rather than relying on the patch posted earlier this week, I'll be using a script to do the actual PARAMS removal. The script and some additional commentary may be found at http://sourceware.cygnus.com/ml/gdb-patches/2000-05/msg00331.html If you have any concerns about the PARAMS removal activity, please let me know as soon as possible. Kevin >From kettenis@wins.uva.nl Wed May 24 15:55:00 2000 From: Mark Kettenis To: obrien@FreeBSD.org Cc: ac131313@cygnus.com, gdb@sourceware.cygnus.com Subject: Re: GDB & FreeBSD Date: Wed, 24 May 2000 15:55:00 -0000 Message-id: <200005242255.e4OMtdm00475@delius.kettenis.local> References: <200005211217.e4LCHPv00623@delius.kettenis.local> <3929EC4C.AD7E0620@cygnus.com> <200005231142.e4NBgjU00165@delius.kettenis.local> <20000523091639.D22706@dragon.nuxi.com> X-SW-Source: 2000-05/msg00124.html Content-length: 1546 Date: Tue, 23 May 2000 09:16:39 -0700 From: "David O'Brien" On Tue, May 23, 2000 at 01:42:45PM +0200, Mark Kettenis wrote: > I be able to cook something up that should work on all i386 BSD's with The thust shouldn't be viewed as working on all i386 BSD's, but all 4.4BSD derived systems. FreeBSD/Alpha is very import to me also. Most of the work I did is specifically related to i386-specific things, so it doesn't help FreeBSD/Alphe very much :-(. > I'd check it in along with a TODO entry mentioning the need to access > how hard it is to ``fix'' 1.x. I can offer a 1.x install CDROM, but I don't know of any one still running a FreeBSD 1.x box. It's probably not worth it. People still using FreeBSD 1.x, can use older versions of GDB instead. > OK, I'll do that for the code that I have right now (which should work > on FreeBSD 2.2 and up) and then see if I can revive the support for > older FreeBSD's after that. My concern is for FreeBSD 3.0+ (ie. ELF). If support for FreeBSD 2.x had to be dropped, it would not bother me. I'd like to have the current systems supported; and those of the future (again ELF). If I can be of any help providing access to FreeBSD 4-STABLE (which will become 4.1 RELEASE) or 5-CURRENT systems, please let me know. Well, testing on some other FreeBSD releases besides 3.4 wouldn't hurt. If no-one volunteers, setting me up with an account on such a system would probably lead to some test-runs on it :-). Mark >From ac131313@cygnus.com Wed May 24 19:15:00 2000 From: Andrew Cagney To: Kevin Buettner Cc: gdb@sourceware.cygnus.com, gdb-patches@sourceware.cygnus.com Subject: Re: PARAMS removal this weekend Date: Wed, 24 May 2000 19:15:00 -0000 Message-id: <392C8C8E.DE480348@cygnus.com> References: <1000524165459.ZM30150@ocotillo.lan> X-SW-Source: 2000-05/msg00125.html Content-length: 812 Kevin Buettner wrote: > So at 5:00 pm MST of Saturday, May 27 (which is midnight GMT on Sunday), > I'll tag the repository, do the PARAMS removal on the gdb directory, > and tag it again. I will use gdb-pre-params-removal-2000-05-28 and > gdb-post-params-removal-2000-05-28 for the tags. (I'm not sure how > long it will take to do all of this, but I wouldn't be surprised if > it were a couple of hours.) Sounds like then it is. > Rather than relying on the patch posted earlier this week, I'll be > using a script to do the actual PARAMS removal. The script and some > additional commentary may be found at Yes. BTW, the best way for people to avoid being hurt by this is to mount a pre-emptive strike - eliminate PARAMS from your code before Kevin comes through on the script on the weekend. Andrew >From donnte@microsoft.com Thu May 25 01:28:00 2000 From: Donn Terry To: 'Mark Mitchell' Cc: kettenis@wins.uva.nl, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, gdb@sourceware.cygnus.com Subject: RE: Suggested (easier) fix to ... RE: Regressions problem (200 failures) Date: Thu, 25 May 2000 01:28:00 -0000 Message-id: <309F4FC4705DC844987051A517E9E39B09D1A9@red-pt-02.redmond.corp.microsoft.com> X-SW-Source: 2000-05/msg00126.html Content-length: 1556 I can't answer why any better than the author of the change that started all this ;-) . > 2000-02-17 Mark Mitchell > > * function.c (thread_prologue_and_epilogue_insns): Put a line note > after the prologue. My suspicion is that there were situations where the "first statement" breakpoint wasn't happening correctly, but I don't know details beyond this. Agreed, it only affects a subset of all gcc/gdb implementations, which clearly explains why everyone wasn't seeing it. Donn > -----Original Message----- > From: Mark Mitchell [ mailto:mark@codesourcery.com ] > Sent: Tuesday, May 23, 2000 1:07 AM > To: Donn Terry > Cc: kettenis@wins.uva.nl; > Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE; > kingdon@redhat.com; gdb@sourceware.cygnus.com > Subject: RE: Suggested (easier) fix to ... RE: Regressions > problem (200 > fa ilures) > > > >>>>> "Donn" == Donn Terry writes: > > Donn> Remember this one? I finally found time (or rather > Donn> desperation :-) ) to look at it more closely. > > The analysis sounds good. So, this bug should only affect platforms > that don't define HAS_INIT_SECTION; platforms that, for example, use > ELF .init/.fini sections won't run into this issue. > > Why are we emitting a line note at the end of the prologue? (And > thus before the call to __main?) Couldn't we wait until the first > real statement? > > -- > Mark Mitchell mark@codesourcery.com > CodeSourcery, LLC http://www.codesourcery.com > >From mark@codesourcery.com Thu May 25 08:38:00 2000 From: Mark Mitchell To: donnte@microsoft.com Cc: kettenis@wins.uva.nl, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, gdb@sourceware.cygnus.com Subject: RE: Suggested (easier) fix to ... RE: Regressions problem(200 fa ilures) Date: Thu, 25 May 2000 08:38:00 -0000 Message-id: <20000525084647W.mitchell@codesourcery.com> References: <309F4FC4705DC844987051A517E9E39B09D1A9@red-pt-02.redmond.corp.microsoft.com> X-SW-Source: 2000-05/msg00127.html Content-length: 474 >>>>> "Donn" == Donn Terry writes: Donn> I can't answer why any better than the author of the change Donn> that started all this ;-) . Touche. OK, now I understand the problem -- thanks to you. I'll look back at why I did what I did -- and then see if I can figure out how to fix it. Thanks for bearing with me on this. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com >From mgalgoci@redhat.com Thu May 25 11:41:00 2000 From: Matt Galgoci To: gdb@sourceware.cygnus.com Subject: [spolk@cygnus.com: Re: [smooge@redhat.com: helping the debian people]] Date: Thu, 25 May 2000 11:41:00 -0000 Message-id: <20000525144136.B5227@redhat.com> X-SW-Source: 2000-05/msg00128.html Content-length: 2293 Would one of you folks, in your copius spare time ;-), please look into this. THanks, --Matt Galgoci ----- Forwarded message from Syd Polk ----- Date: Thu, 25 May 2000 11:01:57 -0700 From: Syd Polk To: mgalgoci@redhat.com CC: spolk@redhat.com Subject: Re: [smooge@redhat.com: helping the debian people] I would send mail to gdb@sourceware.cygnus.com or gdb-local@cygnus.com. Matt Galgoci wrote: > > FYI. > > ----- Forwarded message from Stephen John Smoogen ----- > > Date: Wed, 24 May 2000 22:14:41 -0400 (EDT) > From: Stephen John Smoogen > To: Matt Galgoci > Subject: helping the debian people > > http://www.debian.org/Lists-Archives/debian-devel-announce-0005/msg00008.html > > Package: gdb (debian/main) > Maintainer: Vincent Renardias > [HELP] Fix needed. (RB) > 58450 gdb: Won't compile on PowerPC > 62081 Looking for gdb-4.18-objc patches.... > > Stephen J Smoogen > Web Support Peon > Red Hat Inc > > ----- End forwarded message ----- > > -- > Matthew J. Galgoci > Key fingerprint = 46C1 B1EB 0BE9 E398 7CC3 E788 007D 4FF9 18C2 42C0 > > "Take a shower. I can smell you across the vpn." wrote: > > FYI. > > ----- Forwarded message from Stephen John Smoogen ----- > > Date: Wed, 24 May 2000 22:14:41 -0400 (EDT) > From: Stephen John Smoogen > To: Matt Galgoci > Subject: helping the debian people > > http://www.debian.org/Lists-Archives/debian-devel-announce-0005/msg00008.html > > Package: gdb (debian/main) > Maintainer: Vincent Renardias > [HELP] Fix needed. (RB) > 58450 gdb: Won't compile on PowerPC > 62081 Looking for gdb-4.18-objc patches.... > > Stephen J Smoogen > Web Support Peon > Red Hat Inc > > ----- End forwarded message ----- > > -- > Matthew J. Galgoci > Key fingerprint = 46C1 B1EB 0BE9 E398 7CC3 E788 007D 4FF9 18C2 42C0 > > "Take a shower. I can smell you across the vpn." ----- End forwarded message ----- -- Matthew J. Galgoci Key fingerprint = 46C1 B1EB 0BE9 E398 7CC3 E788 007D 4FF9 18C2 42C0 "Take a shower. I can smell you across the vpn." >From donnte@microsoft.com Thu May 25 20:44:00 2000 From: Donn Terry To: Mark Mitchell , rth@cygnus.com Cc: kettenis@wins.uva.nl, Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE, kingdon@redhat.com, gdb@sourceware.cygnus.com Subject: RE: Suggested (easier) fix to ... RE: Regressions problem (200 failures) Date: Thu, 25 May 2000 20:44:00 -0000 Message-id: <309F4FC4705DC844987051A517E9E39B16EEF6@red-pt-02.redmond.corp.microsoft.com> X-SW-Source: 2000-05/msg00129.html Content-length: 10047 Mark: I just tried to rebuild with my interim patch in place, and found that RTH had completely rewritten the area. If I don't run into too many ICEs during the rebuild of the compiler suite (it comes and goes regularly depending on who has patched what) I'll know something tomorrow (Fri) about what effect his changes had on this, but from looking at the code, it may have the same problem. (I'm skipping my patch for the moment.) Richard: quick synopsis: the code in this area doesn't (didn't?) take into account the possibility of there being a call to __main, with the consequence that the initial breakpoint for main ends up at the {, rather than at the first statement *if* the call to __main is generated. Donn -----Original Message----- From: Mark Mitchell Sent: Thu 5/25/2000 8:46 AM To: Donn Terry Cc: kettenis@wins.uva.nl; Peter.Schauer@Regent.E-Technik.TU-Muenchen.DE; kingdon@redhat.com; gdb@sourceware.cygnus.com Subject: RE: Suggested (easier) fix to ... RE: Regressions problem (200 fa ilures) >>>>> "Donn" == Donn Terry writes: Donn> I can't answer why any better than the author of the change Donn> that started all this ;-) . Touche. OK, now I understand the problem -- thanks to you. I'll look back at why I did what I did -- and then see if I can figure out how to fix it. Thanks for bearing with me on this. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com < http://www.codesourcery.com > begin 600 winmail.dat M>)\^(@8#`0:0"``$```````!``$``0>0!@`(````Y`0```````#H``$%@`,` M#@```-`'!0`9`!0`%P`:``0`/@$!"8`!`"$````P-#-$.30S0C`Y045!1C0S M035#-#5&-C(R-T$R-$,R,@`A!P$@@`,`#@```-`'!0`9`!0`*@`%``0`/`$! M#8`$``(````"``(``0.0!@!D%P``.P```$``.0"*4C_!P<:_`1\`,4`!```` M#@```#0`.0`P`#<`-@`Y```````#`!I``````!\`,$`!````#@```#0`.0`P M`#<`-@`Y```````#`!E``````!\`20`!````E````%(`10`Z`"``4P!U`&<` M9P!E`',`=`!E`&0`(``H`&4`80!S`&D`90!R`"D`(`!F`&D`>``@`'0`;P`@ M`"X`+@`N`"``4@!%`#H`(`!2`&4`9P!R`&4`0`N`&,`;P!M````'P!:``$````< M````30!A`'(`:P`@`$T`:0!T`&,`:`!E`&P`;````!\`,D`!````+````&T` M80!R`&L`0`!C`&\`9`!E`',`;P!U`'(`8P!E`'(`>0`N`&,`;P!M`````@%< M``$````;````4TU44#I-05)+0$-/1$533U520T5262Y#3TT```,`'4`````` M`@%>``$```!!`````````($K'Z2^HQ`9G6X`W0$/5`(`````36%R:R!-:71C M:&5L;`!33510`&UAR$=4.40,!W1#7,@8`!L,1U3,$1A#9;Q+K$>,([PGW.QC/#C`U M.Q'2#&!C`%`+"0%D,S:3$6`+I30@$`(J7`ZRO0&09Q3P"J,1XQWH-!3P`#PA M1$]#5%E0`$4@2%1-3"!0`%5"3$E#("(M("\O5S-#(8!$5")$()0S+C(A@$5. MG"(^'NT>CR/!,3@?\&\@HB,/)!\FD#,=@"5P17Q!1"7-#O$F[REO)/0V00[P M/$U%5$$'L$$Q+&`](D<)\`20871%!;`B$M!/3E0BT%03+/`%X45X$/%N9V4] M!E)V$S$O00"0`B`@-M`N,"XT'-`X,#`B_A,JSR4#-S0*21N-?T?\"\S3S%_)D4T MD3JP*$\+)I\^A#418#Q"3T1`62!D:7(]/J!RGSWP/F,`(0,P00%D;P#@\T$! M"K%<<1BP00$0\`,P'T%E$6`^&QSQ/Q]G.3;Q'_!$259!.0``0W<^.2PV-$:O M0\)-"L!K.G\^.0'`04<*HD%'"G$D?##_*!$AX$9[3`A#_T4/1A]'+Q=(/U*K M/ALX'8`F;F+,Z8Y!!P&.@0B!N)_T%0')G@&62-H`M<#:``X'K98`A,$4$(&0( M<2[0=D/W:%]PLF2F;T'`=E)IX@,0_PBB:J]KOVS/;=]N[V__<0_O0>D(H0,!D>D$_-A#]`9!KU3(V<;:/SC(`T`6@_V>`L+/(#\D?RB_+ M/\Q/S5^?SF_/?]"/T9_>=W!O-W%^8@,093!E@'YT&-"@,&6?L&-IT`=``R`V M<5]?`,#?"X!G`&4C?J0`@&73P`GP_V;@9[1\;VDF"X!E,`__VO_<#]T? MWB_?/^!/X5_B;^OC?_`78G:A:^409:&XXT_G@IXP9S`$('5PL)9<_GMG`"U1 MYA%GL@.@L*4V,/\1(`5`-5`M8#@PN:'IO_&C^BH&D"K9K^Q?[6_N?^^/__"? M\:_RO_//]-\%:^;L.1#OBW`NX"TS&.`N_2_^/_]/_P!?`6\"?P./!)\%KP:_ M#J__Q:_&O\?/"N\+_PT/#A\/+U\0/Q%/$E\3;R!K1"_0;O\8+QD_&D\;7QQO M'7\>CT!@@$Q/0TM154\M\!M`MOJA>3@@+C%!4D<`24XM4DE'2%3Q-.`P<'@P MH1:X*;$HLO]"94,#0L%#7RD?,]MYH2GO'Q^/()\AKS`(0O!I,S81,(TQ-#@F M\$9/3E)4BH!I>BR`,C1[9JQS,C%Q,!#^9_?`YO!*`(M@LG`)<#OS MM3A=,2KB4D$[]\!E,*#O,`\5MRL`-'MB+_F=0+F`^CHS/#(F\4&Z*`E*`TH` M_XL`CD&/'S&/%>0S#CY_/X_W0)]!KTP(4_L10Y]$KWE'@%1H=2`U+S)2@4(P M4N`@.#HT-!!!?DT]GTJO2[],STW?5C54?F]/GU"O>4Y5"<,!E_0"Y3GO'HT')`4G.,,+FB12U<<(Y`ZR!K8"Y452U-Z-)V8&ZX M+D1%:1"P4GHA0(P@^F2.H2Z+,6D?:B]>UF[0W&)`G`!\`.D`=]71;X#P>6=N M=6B0BS%3GV!?CV%O8G]CCT[F=6)JGG%G92]F/T6W4D73H'FP9_^?,0G1BN#5 M\.5`?T#7(/I0WG@(DF_O]"Z!,'S#_VR1C"#E,>B!LK:*X%+1]U#OU@#E M<'+`BV`I=`]U'W8OKX0?A2^&/R96-301+SF"_WMO%]\D7R5O)G^+CS"/?Z_W M,J\V-9`04"W?-UDVSS??3SCO.?\[#15/9W06F3[_F]^<[YW_GP^@'Z$OHC^C M3Q>D7Z5O1?,B(U(B(#W>/5P??P^`'ZOO)I.P%IF./*88;N'[(&5`;=-`>[+0 MOF+^9SYK?N6\5SQ;?_\0?Q2_&/\=/R%\7>2-#RA\[L@]%QDD(0=9B M^;!S=_GY87=HY;#YL.6PYF!G\?_Y=:JOO%^LQ.@R;$#I,/=Q_^74Z&#YH0EP MM`^U'T6*AN__A_^)#\#_P@_#'\GORO_)+__?K^"_X<_BW^/OS*_-O\[/_](/ MTQ_4)_AQ^K&W,'V!"&/2:`E!.RU^("[6']'UCV=4;!_^\_\$_Q7_)O\W_TC_6?]J__][_XS_G?^N_[__T/ M_A\%A8!/2RP@;F]WS]'X=6YDJE#MX1$`U6."=ML]<='":X)0?H%Y#D?O5 M,-3@(-4`$+!^@7Y!&?__&P\<'QTO'C\?3R!?(6_>G?]&H/__*Q\"'P,O!#\O M3P9?_P=O"'\)CPJ?"Z\O[S#_,@_[6.82I&;5$=%0/`!NL;.`\4:@:"!M*1&J M(.ZB,Z__-+\USS;?-^\X_SH/.Q\\+_\]/SY//U]`;T%_0H]+M22P_T8_1T\L M/RU/+E]+GU-_5(]]WIU-3H`9L"8/3H^LQ$W_L[!N$1:`$W\4C^2/8[]DS_]E MWV;O9_]I#VH?:R]L/VU/_VY?;V]P?W&/@]['WPO M?3]^3_]_7X!O@7^"CX.?A*^%OX;/_X??B.^)_XL/C!^-+XX_CT]_D%^1;Y)_ MYVM@;V%_K,1MO6`A0+#`$1"P<"CP8ZI0_GFPOU=_6(]9GUJO6[]7/YA/K,1,3$.43Y5?_Y./J%^I;ZI_JX^LGZVOKK__K\^P MW['OLO^T#[4?MB^W/_^X3[E?NF^[?[R/O9^^K[^__\#/P=_"[\/_Q0_&'\]./^\_3PL0 M\/]/<3?BP5!(5$U,HK!]];`#`"8```````,`-@``````'P!'$`$````>```` M;0!E`',```@ M`'0`;P`@`"X`+@`N`"``4@!%`#H`(`!2`&4`9P!R`&4```@0 M`0```&4```!-05)+.DE*55-45%))14143U)%0E5)3$17251(35E)3E1%4DE- M4$%40TA)3E!,04-%+$%.1$9/54Y$5$A!5%)42$A!1$-/35!,151%3%E215=2 M251414Y42$5!4D5!249)1$].``````(!?P`!````3@```#PS,#E&-$9#-#