VM debugging - process IDs (was Re: [Vm-dev] Re: slang printf
btc at openinworld.com
Mon Feb 22 12:05:37 UTC 2016
@Esteban, thanks, that worked.
@Alain, This is not for the Xen stuff. Nice to see your enthusiasm
thought. I'll ping you when I have anything at all interesting with
that. What I'm doing now is good practice for that. I'm working on
the new primitives for Dennis' OwnedLock (basically a copy of Eliot's
critical section code with modified return value semantics), but I'm
doing an experiment making the lock release stricter, i.e. that only
the owner can release, and hit an interesting snag where the
activeProcess seen by the primitive seems different than the process
that called the primitive. I'll ask some advise on that separately
once I got me head around it a bit more.
@Eliot, I found all those print methods and how to call them from gdb.
Now when I do...
(gdb) break break primitiveOwnedLockStrictRelease
(gdb) run ../50594/50594.image
Execute the test method, which breaks out to gdb, then...
(gdb) call printAllStacks()
Process 0xb1a6678 priority 40
0xbfff4098 I OwnedLock>release 0x8779700: a(n) OwnedLock
processes at priority 10
Process 0xb93daa8 priority 10
0xbff650a0 M ProcessorScheduler class>idleProcess 0x8ccedd0: a(n)
Process 0xb93d040 priority 50
0xbff620a0 M WeakArray class>finalizationProcess 0x8ccefc0: a(n) WeakArray class
Process 0xad2c848 priority 80
0xbff640e0 M DelayExperimentalSpinScheduler(DelayMicrosecondScheduler)>runTimerEventLoop
0xa0a3760: a(n) DelayExperimentalSpinScheduler
Process 0xb4335e0 priority 60
0xad8eb50 s SmalltalkImage>lowSpaceWatcher
Process 0xb93d748 priority 60
0xbff6107c M InputEventFetcher>waitForInput 0x9261618: a(n) InputEventFetcher
So I factored the first few lines of printAllStacks out to...
| proc |
proc := self activeProcess.
self printNameOfClass: (objectMemory fetchClassOf: proc) count: 5;
space; printHex: proc.
self print: ' priority '; printNum: (self quickFetchInteger:
PriorityIndex ofObject: proc); cr.
(not that I know the significance of <api> and <inline:false> , but
monkey-see-monkey-do seems effective so far)
So now I can do...
(gdb) call printActiveProcess()
Process 0xb1a6678 priority 40
double cool !!
but how can I match up that process ID with the one shown in-Image by
without calling printAllStacks() each time?
On Mon, Feb 22, 2016 at 12:28 AM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> Hi Ben,
> you'll see a lot of print methods in StackInterpreter that dump stack frames etc. these are built above some simple string and number of output routines, like print: & printNum: that you can use in simulated code and print to stdout in the real VM also.
> For debug logging during simulation the interpreter simulators respond to #transcript by answering the output window in the VM simulation. There's a menu pick in the bottom right inspector to toggle the transcript between the small one in the VM simulation and the system's Transcript.
> _,,,^..^,,,_ (phone)
>> On Feb 21, 2016, at 6:43 AM, Alain Rastoul <alf.mmm.cat at gmail.com> wrote:
>>> On 21/02/2016 14:34, Ben Coman wrote:
>>> The most promising I found so far is...
>>> self printStringOf: 'BLAH3' ; flush.
>>> but nothing show up on the bash console that started the VM.
>> Hi Ben,
>> On a standard linux console, printf should output to console (I just verified now) .
>> What kind of console ?
>> xen console for rump vm (on netbsd?) ?
>> oh my ! great
>> if so, it depends of the kind of virtualization you choosed :
>> hw, I guess depends of bios and drivers (bochs/qemu should go out to qemu drivers/console?)
>> pv there is a special hypercall api in mini-os to output to host domain console (don't remember exactly, may be search for printk in Mini-os/xen headers, I'll digg into and post you what I found soon).
>> (nb: If you are at that point I am *very* interested, I struggled a lot to link a hacked vm with netbsd libs .. I am bad at autoconf, cmake and co. currently in my standby list, I will resume )
More information about the Vm-dev