[comp.unix.ultrix] adb apprentice wizardry

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