JDevlieghere wrote:
Can we get (a subset) of this information on Darwin? I understand it's only
necessary for ELF core files, and from the discussion that there's no standard
POSIX way to get this, but it still feels a bit unfortunate to implement all
these methods but only implement this for
https://github.com/feg208 closed https://github.com/llvm/llvm-project/pull/88995
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
feg208 wrote:
> Yes, you'd have to put this test into a host test for a system that doesn't
> support this, like use the Posix one or make one for the Windows or Darwin
> Hosts.
Done!
https://github.com/llvm/llvm-project/pull/88995
___
lldb-commits
https://github.com/feg208 updated
https://github.com/llvm/llvm-project/pull/88995
>From 9b8ec4d0c31ad1b228add56bc27cd79457e515c7 Mon Sep 17 00:00:00 2001
From: Fred Grim
Date: Tue, 16 Apr 2024 14:46:37 -0700
Subject: [PATCH 1/3] adds additional information to the ProcessInfo object for
elf
jimingham wrote:
Yes, you'd have to put this test into a host test for a system that doesn't
support this, like use the Posix one or make one for the Windows or Darwin
Hosts.
Jim
> On Apr 17, 2024, at 10:43 AM, Fred Grim ***@***.***> wrote:
>
>
> That test looks good. It seems unlikely
feg208 wrote:
> It should never decrease, however. If you were just getting garbage values,
> then there should be a roughly even chance the second value will be less than
> the first. So this still gives some confidence this isn't totally bogus...
For sure. My concern is that it wouldn't
feg208 wrote:
> That test looks good. It seems unlikely that you would buggily always produce
> monotonically increasing times...
>
> Not to be a pest, but since this info is only provided on Linux, we should
> maybe add a test to make sure that asking for this information on systems
> that
feg208 wrote:
> That test looks good. It seems unlikely that you would buggily always produce
> monotonically increasing times...
>
> Not to be a pest, but since this info is only provided on Linux, we should
> maybe add a test to make sure that asking for this information on systems
> that
https://github.com/feg208 updated
https://github.com/llvm/llvm-project/pull/88995
>From 9b8ec4d0c31ad1b228add56bc27cd79457e515c7 Mon Sep 17 00:00:00 2001
From: Fred Grim
Date: Tue, 16 Apr 2024 14:46:37 -0700
Subject: [PATCH 1/2] adds additional information to the ProcessInfo object for
elf
jimingham wrote:
> > The user and system times should be monotonically increasing. So you could
> > stop at a breakpoint, fetch the times, then run your program through a
> > little spin loop to burn some CPU before hitting a second breakpoint. Then
> > get the times again and assert that
jimingham wrote:
That test looks good. It seems unlikely that you would buggily always produce
monotonically increasing times...
Not to be a pest, but since this info is only provided on Linux, we should
maybe add a test to make sure that asking for this information on systems that
don't
feg208 wrote:
> The user and system times should be monotonically increasing. So you could
> stop at a breakpoint, fetch the times, then run your program through a little
> spin loop to burn some CPU before hitting a second breakpoint. Then get the
> times again and assert that they are > the
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff c6e01627acf8591830ee1d211cff4d5388095f3d
9871016e5cae2d07455cd7857d49dd424066ca41 --
https://github.com/feg208 updated
https://github.com/llvm/llvm-project/pull/88995
>From 9b8ec4d0c31ad1b228add56bc27cd79457e515c7 Mon Sep 17 00:00:00 2001
From: Fred Grim
Date: Tue, 16 Apr 2024 14:46:37 -0700
Subject: [PATCH 1/2] adds additional information to the ProcessInfo object for
elf
feg208 wrote:
> The user and system times should be monotonically increasing. So you could
> stop at a breakpoint, fetch the times, then run your program through a little
> spin loop to burn some CPU before hitting a second breakpoint. Then get the
> times again and assert that they are > the
emaste wrote:
> is there not a Posix way to get these
Not really. On FreeBSD these generally come from sysctl(s).
Of the ones added in this pull request SetParentProcessID is already handled on
FreeBSD, while SetProcessGroupID, SetProcessSessionID, SetUserTime,
SetSystemTime,
jimingham wrote:
> On Apr 16, 2024, at 5:17 PM, Fred Grim ***@***.***> wrote:
>
>
> These seem like fairly POSIX-y bits of data, is there not a Posix way to get
> these (so other posix systems will also get this info?)
>
> Not that I know of for arbitrary processes in linux. fwiw the
feg208 wrote:
> These seem like fairly POSIX-y bits of data, is there not a Posix way to get
> these (so other posix systems will also get this info?)
Not that I know of for arbitrary processes in linux. fwiw the original code
without these values got similar bits out of the proc filesystem
jimingham wrote:
These seem like fairly POSIX-y bits of data, is there not a Posix way to get
these (so other posix systems will also get this info?)
Also, it looks like you added user time and system time information, but you
didn't test that those get valid values.
llvmbot wrote:
@llvm/pr-subscribers-lldb
Author: Fred Grim (feg208)
Changes
This adds some additional bits into a ProcessInfo structure that will be of use
in filling structs in an elf core file. This is a demand for implementing
process save-core
---
Full diff:
https://github.com/feg208 created
https://github.com/llvm/llvm-project/pull/88995
This adds some additional bits into a ProcessInfo structure that will be of use
in filling structs in an elf core file. This is a demand for implementing
process save-core
>From
21 matches
Mail list logo
