Commit Graph

9 Commits

Author SHA1 Message Date
Craig Small
8fcfb01a81 misc: Update the copyrights of files
The copyrights of the source files were all out of date and were not
the same format. This has been corrected. The source of the authors
was examining the git log for each file.

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2023-02-07 21:09:48 +11:00
Craig Small
82d8e3faf3 tests: Fix type for check_fatal_proc_unmounted
While ps used the correct type for PIDS_VM_RSS the test
did not. For some reason this only appeared to be an issue
for s390x

References:
 https://bugs.debian.org/1025495

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-12-06 22:23:08 +11:00
Jim Warner
b89e3230b2 library: adapted for absent 'core id' in /proc/cpuinfo
A big oops on my part - with a big thanks to Dr. Fink.

[ this version eliminates an extraneous startup call ]
[ to the 'stat_cores_verify' function as superfluous ]

Reference(s):
https://www.freelists.org/post/procps/For-procpsng4001-No-core-id-in-eg-aarch65-or-ppc64le-proccpuinfo

Prototyped by: Dr. Werner Fink <werner@suse.de>
Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-10-25 20:16:12 +11:00
Jim Warner
f571746af2 library: tweak support of p-core/e-core identification
Wow, after this we'll eliminate one 'jmp' instruction!

[ plus we can also save a single precious whitespace ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-10-04 10:57:34 +11:00
Jim Warner
6e51196589 library: provided for cpu p-core/e-core identification
With Intel's 12th generation Alder Lake processors now
providing two distinct types of core, it would be nice
if the library offered some sort of clue to core type.

Well, with this patch it does. We'll have 2 additional
enumerators. One deals with the cpu's core association
and the other provides the type of that core (P or E).

[ now, all we need is for some program to exploit it ]

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-28 17:30:56 +10:00
Jim Warner
046883b9d3 library: address an 'uninitialised value' VALGRIND bug
Thanks to valgrind and his --track-origins=yes option,
the problem and solution was suggested as shown below.

[ and it was created in that commit referenced below ]

But, after attacking this problem by adding a memset()
call in pids.c, a 2nd valgrind oops, also shown below,
was encountered. The dynamically acquired 'cmd' again!

[ might help to explain why changes appear excessive ]

Reference(s):
. 1st valgrind discovery
==11111== Conditional jump or move depends on uninitialised value(s)
==11111==    at 0x13425D: stat2proc (readproc.c:582)
==11111==    by 0x137436: look_up_our_self (readproc.c:1613)
==11111==    by 0x132196: fatal_proc_unmounted (pids.c:1388)
==11111==    by 0x11BA4D: before (top.c:3580)
==11111==    by 0x127E10: main (top.c:7173)
==11111==  Uninitialised value was created by a stack allocation
==11111==    at 0x132165: fatal_proc_unmounted (pids.c:1381)

. Jul, 2022 - fatal_proc_unmounted refactored
commit 52bd019d8c

. 2nd valgrind discovery
==22222== 16 bytes in 1 blocks are definitely lost
==22222==    by 0x4A0E60E: strdup (strdup.c:42)
==22222==    by 0x133D00: stat2proc (readproc.c:587)
==22222==    by 0x136E67: look_up_our_self (readproc.c:1613)
==22222==    by 0x131BC7: fatal_proc_unmounted (pids.c:1390)
==22222==    by 0x11B7C6: before (top.c:3580)
==22222==    by 0x127828: main (top.c:7173)

Signed-off-by: Jim Warner <james.warner@comcast.net>
2022-09-12 22:15:28 +10:00
Craig Small
55cc33fc0a misc: Update pc file to new library name 2022-08-29 20:42:45 +10:00
Craig Small
1502648ff9 library: Rename to libproc2
The newlib library used to be called libproc-2 but the new
name is preferred.

References:
 https://www.freelists.org/post/procps/Next-for-newlib,3

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 20:38:17 +10:00
Craig Small
3d0871728b build-sys: Relocate library to library/
All the dependent programs needed to have their includes moved too

Signed-off-by: Craig Small <csmall@dropbear.xyz>
2022-08-29 19:02:44 +10:00