[9fans] Inferno: starting a process in a stopped state

[9fans] Inferno: starting a process in a stopped state

[Edouard Klein]

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
Permalink: https://9fans.topicbox.com/groups/9fans/T4297f451b18d599a-Md3642db0bae45288d5553df6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Inferno: starting a process in a stopped state

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]

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 <edou@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
Permalink: https://9fans.topicbox.com/groups/9fans/T4297f451b18d599a-Mb91c323511c37b5d7da47a39
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2670 bytes --]

Re: [9fans] Inferno: starting a process in a stopped state

[Edouard Klein]

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 <rminnich@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 <edou@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-M67ba8d91ab92ee064844712b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Inferno: starting a process in a stopped state

[Edouard Klein]

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 <edou@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 <rminnich@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 <edou@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-M798e4b1249a2536aa222a53b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] Inferno: starting a process in a stopped state

[Edouard Klein]

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 <edou@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 <edou@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 <rminnich@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 <edou@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