assets/developer-notes/stephanie-gawroriski/2019/09/21.mkd

   1 # 2019/09/21
   2
   3 ## 07:07
   4
   5 Okay so work continues on vtables and such.
   6
   7 ## 10:06
   8
   9 Okay so the bootstrap is up and building, now to figure out the boot crashes.
  10 Seems I have a pointer which is in the wrong spot.
  11
  12 ## 10:14
  13
  14 Noticed that I do not write class data to the ROM.
  15
  16 ## 12:10
  17
  18 Notes from Discord: Yay vtables. Hopefully after all this refactoring, things
  19 run as per the usual. Okay does not run, so hmmmmm. Shall find out why!. Okay
  20 so. Seems the entry method is in the wrong spot. BootRAM is 21K. Ooooh this
  21 might be why. Maybe?. Guessing the class address is wrong. It seems classes
  22 are a bit small. Are classes really this tiny?. Seems like a class is only
  23 like 24 bytes long?. Ooooooh. I never even bother writing the actual class
  24 data to the ROM. That might be why. So BOOT_ENTRY is hit which is a good
  25 thing. But it reads invalid memory. Which reads the pool references are null.
  26 pool entries 1, 15, and 16. Which means the pool pointer might be wrong. Or
  27 has no actual values. So not sure if the pool values are being written. But at
  28 least I got the class and method offsets correct. Noted strings are at
  29 seemingly valid pointers though. The value read from the pool is zero. So I
  30 wonder. Is the pool pointer in invalid memory?. Seems to be in good memory.
  31 First thing allocated. Okay so the boot pool is in the right spot. It is
  32 probably something dumb to be honest. Okay it seems the stuff is right. Unless
  33 the pool pointer is incrrect?. But it is at the right address it just has the
  34 wrong values?. Only reasonable thing is that something is being overwritten?.
  35 Oooh. something is being overwritten. One operating is completely disregarding
  36 location in memory. It is not the pool. It is an int table. Okay it has to be
  37 the class data, since I disregard the write pointer. Well the offset. Okay the
  38 ClassInfo init was writing the wrong spot. The pool pointer references are in
  39 the wrong spot now though. Oh. The strings are probably invalid because of the
  40 initial meta data. So increase speed lookup. Okay cool. So jvmIsInstance()
  41 works. then it just crashes in config reader. So it tries to read an array at
  42 address 0x00000001. Okay so it stops in the instance initializer. it is doing
  43 the super class call. Okay so. The accessed field is reading as 0 and then 1
  44 for the vtable. (method ptr, and pool ptr). Which means the accessed field
  45 offset must be wrong. Or the offset is. So very possible it is the accessed
  46 field position which is wrong. If I had to guess, perhaps the vtables are
  47 being written wrong. So the initial load into the constructor works then it
  48 fails. Okay so. The class info was being allocated for the current class size
  49 instead of the one for class info. So it should have overrwritten in this case
  50 and it has. I see it now executing system calls.
  51
  52 ## 21:19
  53
  54 I do have the callstack, so I can see where the pure virtual call comes from.
  55 It is StringBuilder.append().
  56
  57 ## 13:01
  58
  59 There are pure virtual calls, so maybe since I skip privates those are not
  60 fully linked?
  61
  62 ## 14:05
  63
  64 I am pretty sure I can simplify the bootstrap when it comes to loading class
  65 info and such. I really am just at this point going to be rebuilding the
  66 BootRAM initializer but in the bootstrap. So perhaps for this point I should
  67 make it so that it is pretty much a copy of that code? I think at this point
  68 I should have a dedicate class loader or something that can work with a given
  69 class similar to the `LoadedClassInfo` in the BootRAM.
  70
  71 ## 16:09
  72
  73 I think the simplest thing to do would be to model this after the BootRAM
  74 initializer by following it logically. I think that would be easy and simple
  75 and can handle things accordingly.