lenny@icus.ICUS.COM (Lenny Tropiano) (04/09/90)
In article <1135@icus.ICUS.COM> lenny@icus.ICUS.COM (Lenny Tropiano) writes: |>I was able to get a copy of the kern.o.cpio.Z file before Brant had |>a chance to release it to the osu-cis Internet archives. According [...] Gil and I were doing some hacking/brainstorming this weekend, we decided to do some major peeking at these object files. Some interesting things were found ... The archive library lib4 which contained ... |>rw-r--r-- 0/ 100 1500 Mar 15 09:00 1990 main.o |>rw-r--r-- 0/ 100 807 Mar 15 09:00 1990 trap.o |>rw-r--r-- 0/ 100 2662 Mar 15 09:00 1990 getcmd.o |>rw-r--r-- 0/ 100 1374 Mar 15 09:00 1990 memory.o |>rw-r--r-- 0/ 100 1054 Mar 15 09:00 1990 regs.o |>rw-r--r-- 0/ 100 248 Mar 15 09:00 1990 dload.o |>rw-r--r-- 0/ 100 614 Mar 15 09:00 1990 io.o |>rw-r--r-- 0/ 100 661 Mar 15 09:01 1990 atoh.o |>rw-r--r-- 0/ 100 1475 Mar 15 09:01 1990 8251.o |>rw-r--r-- 0/ 100 1821 Mar 15 09:01 1990 break.o |>rw-r--r-- 0/ 100 676 Mar 15 09:01 1990 dispreg.o |>rw-r--r-- 0/ 100 1030 Mar 15 09:01 1990 modbyte.o |>rw-r--r-- 0/ 100 762 Mar 15 09:01 1990 disass.o |>rw-r--r-- 0/ 100 898 Mar 15 09:01 1990 dispblk.o |>rw-r--r-- 0/ 100 12000 Mar 15 09:02 1990 text68.o |>rw-r--r-- 0/ 100 1148 Mar 15 09:03 1990 pnt.o |>rw-r--r-- 0/ 100 2727 Mar 15 09:03 1990 btrace.o |>rw-r--r-- 0/ 100 350 Mar 15 09:03 1990 getpid.o |>rw-r--r-- 0/ 100 306 Mar 15 09:03 1990 misc.o |>rw-r--r-- 0/ 100 1594 Mar 15 09:04 1990 dbstr.o |> Is basically all the pieces for the kernel debugger. What's interesting is that this (lib4) can be easily removed from the link (ld) stage. I suppose this is here for the use of the db.o (kernel debugger). References to an 8251 chip are interesting, at least to hardware hackers like Gil -- he mentioned we don't even have one of those in the machine. Hmmm. |>Now what? Most people would like to hack their kernel, and without source |>that becomes a bit of a challenge. Since none of us are going to get 3.51m |>source (or it seems quite unlikely in the future), we need to go to other |>extremes. Thanks to Alex Crain's work on unc (a good disassembler), it |>makes ripping apart binaries to assembly code a bit easier. For those |>real-hardcore hackers, adb will do in a lot of cases ;-). Well we did have a bunch of problems with unc (you listening Alex?). Mostly it would bomb out in 50% of the cases with "invalid text address" messages. It also doesn't show initialization of various spaces in the kernel. Specifically in conf.o, the v-block (see <sys/var.h>) should be initialized to the values in (<sys/space.h>). This is where the infamous NMOUNT kernel variables are kept (v.v_mount). adb'ing the kernel now shows it's 8 (as suspected). So what does this all say... well it's not easy to change NMOUNT without the conf.c source code, or a fix to unc the disassembler. |>Ok, now looking in (lib1)sys3.o there is the system call mount(). Assembly |>shows that the "8" is compared to bdevcnt, and then if not it returns |>errno=6. (#define ENXIO 6 /* No such device or address */) |> Mistake here. Gil and I looked further and it looks like the mount() system call just goes through the mount[] structure for an available slot. If there are no available slots, after reaching the end, it then returns the appropriate errno. So... one should only have to increase the space for mount[] structure in the kernel, and modify the v-block NMOUNT parameters. Unfortunately both the space declaration and v-block initialization are in conf.o. Alex! :-) |>You'll all be happy hacking soon! |> Either that or we'll all be up late pulling our hair out more often... Back to the laboratory... -Lenny -- | Lenny Tropiano ICUS Software Systems lenny@icus.ICUS.COM | | {ames,pacbell,decuac,sbcs,hombre,rayssd}!icus!lenny attmail!icus!lenny | +------ ICUS Software Systems -- PO Box 1; Islip Terrace, NY 11752 ------+