hubcap@hubcap.clemson.edu (Mike Marshall) (05/04/88)
Good Morning - I haven't recompiled vnews since we were running ULTRIX 1.2, so when the new daylight savings time rules got dumped on us, vnews ended up displaying the wrong time. The simple fix was, of course, to recompile vnews. The fun, interesting and educational fix, however, was to patch the vnews executable with adb. My office mate, Amitava Ghosh, set about to do just that, and we learned a great deal about adb in the process. I would like to pass along what we did and what we learned. The way we did it might not be the way and adb wizard would have done it, but it worked, and if you're ever going to learn how to harness the power of adb, you gotta start somewhere! So here's what we did: The source to ctime indicated that the only thing that needed to be changed was a julian date in a static data structure that indicated the date that DST was to end. DST used to end on day 119, and now it ends on day 96. By using nm(1) to print the vnews executable's name list, the symbolic offset of all of the vnews data segments (along with other symbolic names) can be determined. By using the "offset,length format" command of adb, all of the data segments can be looked at. If you have patience, and you know what you are looking for you can find the data segment you need to change. In this case it turned out that the julian date that needed changing was found in the data segment named "hltab". As an example, the exact adb invocation that allowed us to look at hltab's contents was: hltab,100 ?D4 ^ ^ ^ | | |-------- using this format | |--------- for this number of 4-byte blocks |--- starting here This produced a bunch of output, and the stuff we were looking for (the 119) was imbedded down there somewhere. A tedious byte count showed that the 119 was at offset 1c0, and hltab+1c0,1 ?D4 printed the 119. The above command (hltab+1c0,1 ?D4) not only displayed the 4 bytes of interest, but also set the value of "." to point to the 119. ?W 60 writes a 96 (96 = 60 hex) at the location pointed to by ".", which fixed the executable... All done! -Mike Marshall hubcap@hubcap.clemson.edu ...!hubcap!hubcap