@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. Very cool. 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() I get...
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) ProcessorScheduler class
suspended processes 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
cool !
So I factored the first few lines of printAllStacks out to... printActiveProcess <api> | proc | <inline: false> 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 Process Watcher without calling printAllStacks() each time?
cheers -ben
On Mon, Feb 22, 2016 at 12:28 AM, Eliot Miranda eliot.miranda@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@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 )
HTH
regards
Alain
On Mon, Feb 22, 2016 at 8:05 PM, Ben Coman btc@openinworld.com wrote:
and hit an interesting snag where the activeProcess seen by the primitive seems different than the process that called the primitive.
Quick correction. Its not activeProcess that is wrong, its that the owning process is changing unexpectedly - maybe due to wrapping inside #on:do: and/or #ifCurtailed:
@Eliot, I found all those print methods and how to call them from gdb.
Belay that request about matching to process IDs inside the image. The gdb visible IDs remain the same, and its workable to record and cross reference back printAllStacks since the IDs remain the same and I'm getting to know them.
cheers -ben
On Mon, Feb 22, 2016 at 8:56 PM, Ben Coman btc@openinworld.com wrote:
On Mon, Feb 22, 2016 at 8:05 PM, Ben Coman btc@openinworld.com wrote:
and hit an interesting snag where the activeProcess seen by the primitive seems different than the process that called the primitive.
Quick correction. Its not activeProcess that is wrong, its that the owning process is changing unexpectedly - maybe due to wrapping inside #on:do: and/or #ifCurtailed:
I was right the first time. The active process was changing, but it was down to my lack of knowledge...
Transcript clear; crShow: Processor activeProcess; show:' - outside'. process := [ [ Transcript crShow: Processor activeProcess; show: ' - inside'. 1 second wait. ] ifCurtailed: [ Transcript crShow: Processor activeProcess; show: ' - curtailed' ] ] newProcess priority: 41. process resume. process terminate. ==> a Process(304957184) in nil - outside a Process(639380480) in nil - inside a Process(304957184) in nil - curtailed
Of course this makes some sense, the 'inside' process had been terminated, so it can't run there. Indeed, from gdb, the 'inside' process is absent from output of printAllStacks(). cheers -ben
@Eliot, I found all those print methods and how to call them from gdb.
Belay that request about matching to process IDs inside the image. The gdb visible IDs remain the same, and its workable to record and cross reference back printAllStacks since the IDs remain the same and I'm getting to know them.
cheers -ben
vm-dev@lists.squeakfoundation.org
-
Ben Coman