Date: Fri, 30 Jul 2021 18:02:04 +0200
On Fri, Jul 30, 2021 at 5:41 PM Tom Honermann <tom_at_[hidden]> wrote:
> On 7/30/21 10:56 AM, Thiago Macieira via SG16 wrote:
> > On Thursday, 29 July 2021 19:11:03 PDT Charlie Barto wrote:
> >> If such functionality were to be added it would be neat if the linux
> >> implementations worked even if procfs were not mounted (such as when the
> >> process is init) unless I'm mistaken fetching the command line through
> proc
> >> for your own process is making like two system calls to de-reference a
> >> pointer into your own address space.
> > Going off-topic here, but correcting the above.
> > Procfs is not required for one's own command-line and environment in any
> Unix
> > I know of. They are duplicated in Linux's /proc, but they are added to
> the
> > process' virtual address space just above the stack (and below the auxv).
>
> True today, but I suspect their location is subject to change (though
> probably unlikely).
>
> Is there a straight forward way to determine their location in memory?
>
Do we need to?
It seems like a robust (yet painful) solution would be to ask the language
below (c folks) to make this happen
(When glibc calls main it can put argv in a global)
> Tom.
>
> >
> > Trivia: if you modify that area, the /proc files also change, allowing
> you to
> > change the name presented in ps and similar tools.
> >
> > $ ps -o pid,command -Cfile.so
> > PID COMMAND
> > 4873 file.so [kdeinit5] file
> local:/run/user/1000/klauncherdAEtky.1.slave-
> > socket local:/run/user/1000/kded5hvkirU.1.slave-socket
> > 4874 file.so [kdeinit5] file
> local:/run/user/1000/klauncherdAEtky.1.slave-
> > socket local:/run/user/1000/kded5FwKgfB.2.slave-socket
> >
>
>
> On 7/30/21 10:56 AM, Thiago Macieira via SG16 wrote:
> > On Thursday, 29 July 2021 19:11:03 PDT Charlie Barto wrote:
> >> If such functionality were to be added it would be neat if the linux
> >> implementations worked even if procfs were not mounted (such as when the
> >> process is init) unless I'm mistaken fetching the command line through
> proc
> >> for your own process is making like two system calls to de-reference a
> >> pointer into your own address space.
> > Going off-topic here, but correcting the above.
> > Procfs is not required for one's own command-line and environment in any
> Unix
> > I know of. They are duplicated in Linux's /proc, but they are added to
> the
> > process' virtual address space just above the stack (and below the auxv).
>
> True today, but I suspect their location is subject to change (though
> probably unlikely).
>
> Is there a straight forward way to determine their location in memory?
>
Do we need to?
It seems like a robust (yet painful) solution would be to ask the language
below (c folks) to make this happen
(When glibc calls main it can put argv in a global)
> Tom.
>
> >
> > Trivia: if you modify that area, the /proc files also change, allowing
> you to
> > change the name presented in ps and similar tools.
> >
> > $ ps -o pid,command -Cfile.so
> > PID COMMAND
> > 4873 file.so [kdeinit5] file
> local:/run/user/1000/klauncherdAEtky.1.slave-
> > socket local:/run/user/1000/kded5hvkirU.1.slave-socket
> > 4874 file.so [kdeinit5] file
> local:/run/user/1000/klauncherdAEtky.1.slave-
> > socket local:/run/user/1000/kded5FwKgfB.2.slave-socket
> >
>
>
Received on 2021-07-30 11:02:18