OK, my echo stop <>/prog/33/dbgctl was wrong. It opens /prog/33/dbgctl for writing and reading, but only reads from it, output still goes to the standard output.
Here what I came up with next: echo stop <>[5]/prog/4/dbgctl >[1=5] This opens /prog/4/dbgctl RW on FD 5, and then redirects the standard output to FD5. I tried it on a text file, it works in redirecting the output. However, the process is not stopped when I write to its dbgctl file. It continues happily eating CPU cycles jumping to itself, its /prog/N/status still shows "ready", and reading /prog/N/stack yields cat: error reading /prog/4/stack: thread must be stopped I'll try again tomorrow but would appreciate any help or hints. Edouard Klein <e...@rdklein.fr> writes: > For the sake of people stumbling on this post a long time from now: > > I solved my immediate problem by running: > > echo stop <>/prog/33/dbgctl > > The <> redirection opens the file for reading and writing, not just for > writing, and solves the "permission denied" issue. > > However, Inferno's sh(1) man pages mentions > > A file descriptor may be redirected to an already open descriptor by > writing >[fd0=fd1] or <[fd0=fd1]. Fd1 is a previously opened file de‐ > scriptor and fd0 becomes a new copy (in the sense of sys-dup(2)) of it. > > But I see no hint on how to actually open a file and get a file > descriptor. > > It seems that there is a way to call limbo from sh, so maybe the open > system call can be called from sh, but I haven't discovered the syntax > yet. > > Anyway, if anybody knows, I'll be glad to know too, in the meantime, my > current hurdle is cleared so off I go. > > Cheers, > > Edouard. > > Edouard Klein <e...@rdklein.fr> writes: > >> Thanks Ron :) >> >> In DIS assembly, this is written as jmp $0, which can be changed to jmp >> $1 when I want to disable the loop and spare myself from decreasing all >> PC offsets in the code. >> >> >> Now, I have another problem: /prog/N/dbgctl can't be written to :/ >> >> >> Here is how to reproduce: >> >> Save the file below as hello.s >> asm hello.s # Assemble it >> hello& # Run it >> bind '#p' /prog # Mount /prog >> ps # Get the pid, assume e.g. 33 >> echo stop > /prog/33/dbgctl >> >> This yields >> sh: cannot open /prog/33/dbgctl: permission denied >> >> instead of stopping the program. >> >> But I can still kill it with >> echo kill > /prog/33/ctl >> sh: 33 "Command":killed >> >> I have no idea what's wrong. The dbgctl has mode --rw-r--r-- so I should >> be able to write to it. >> >> devprog.c has this snippet >> >> >> case Qdbgctl: >> if(SECURE || p->group->flags&Pprivatemem || omode != ORDWR) >> error(Eperm); >> >> Which seems to indicate that the simple > redirection may fail because >> it would only by an open in write mode. >> >> Is there a way, with Inferno's sh, to open a file in RW and get a file >> descriptor (kinda like bash's exec N<> fname) ? >> >> Is the problem stemming from something else ? >> >> Any ideas, no matter how far fetched or off the cuff, would be welcome >> as I'm banging my head against the wall, and the wall is starting to >> suffer. >> >> Thanks in advance, >> >> Cheers, >> >> Edouard >> >> >> >> ------------hello.s-------------- >> #0 >> jmp $1 >> load 0(mp),$0,12(mp) # Loads "$Sys" into @mp+12, loading the link >> descriptors at $0 >> # ???: why 12 in @mp+12 >> # ???: where is $0 ? >> frame $1,44(fp) # Stores in @fp+44 (44 bytes after the current >> frame pointer) >> # a pointer to a new stack frame to local-call >> to function of type $1 >> # ???: Why +44 ? >> movp 4(mp),32(44(fp)) # 32 after said new frame, store a pointer to >> @mp+4, the string to print >> # ???: Why 32 ? >> lea 40(fp),16(44(fp)) # Stores the address of @fp+40 in 16 after >> said new frame >> # ???: Why 40 ? Maybe because type $2 is 40 >> bytes long >> # ???: Why 16 ? >> mcall 44(fp),$0,12(mp) # Call, in module @mp+12 ($Sys), the first >> function in linkage record array $0, in frame @fp+44 >> ret # Return >> entry 0, 2 # Entrypoint is at the beginning of the >> instruction stream (offset 0) >> # The function type of this entry point is >> $2 (offset 2) >> desc $0,16,"f0" # Type $0 is 16 bytes == 4 words long, all >> pointers >> desc $1,40,"0080" # Type $1 is 40 bytes == 10 words long, the >> ninth is a pointer >> desc $2,48,"00c0" # Type $2 is 48 bytes == 12 words long, the >> ninth and tenth are pointers >> var @mp,16 # Define the module pointer, of length 16 >> string @mp+0,"$Sys" # The name of the module to load >> string @mp+4,"hello world and more\n" # The string to print >> module Command # The module name >> link 2,0,0x4244b354,"init" # The doc is wrong, its desc, pointer, >> ... not pointer, desc... >> # it is the list of exported symbols for the >> module. >> ldts @ldt,1 # This look like the imported symbols from $Sys >> word @ldt+0,1 >> ext @ldt+4,0xac849033,"print" >> source "/tmp/quatorze/hello.b" >> >> >> >> ron minnich <rminn...@gmail.com> writes: >> >>> I put a >>> 1:jump 1 >>> At the start, when I need to do this and have no other way. >>> >>> On Mon, Jul 22, 2024 at 01:28 Edouard Klein <e...@rdklein.fr> wrote: >>> >>> Hi ! >>> >>> I'm writing dis assembly, and I would like to debug my program right >>> from the entrypoint. >>> >>> I intend to use the /prog filesystem for that, thanks to which one can >>> stop a program by echoing "stop" to dbgctl file. >>> >>> However, what I need to do is stop the program at the very start. >>> >>> I have multiple ideas, such as introducing a sleep or a read that would >>> let me enough time to stop the program, but they have the bad property >>> of modifying the program. >>> >>> I could create a loader program that would exec the target program and >>> stop the loader right before the exec, and I suspect (but I'm not sure) >>> that would let me stop the target program. >>> >>> But these all sound very rube goldbergy to me. >>> >>> Is there a way to start a program in a stopped state that I have >>> overlooked ? >>> >>> Thanks in advance, >>> >>> Cheers, >>> >>> Edouard. >>> >>> 9fans / 9fans / see discussions + participants + delivery options Permalink ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4297f451b18d599a-M3e1e3d523a93168b1f2e3b2d Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
