Bug 1142589 - Handle /proc/sys/kernel/core_pattern in gdb testsuite
Handle /proc/sys/kernel/core_pattern in gdb testsuite
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Development
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Tom de Vries
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-07-24 08:00 UTC by Tom de Vries
Modified: 2019-07-24 08:00 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom de Vries 2019-07-24 08:00:42 UTC
In devel:gcc/gdb testlogs, we find:
...
WARNING: can't generate a core file - core tests suppressed - check ulimit -c
UNSUPPORTED: gdb.base/auxv.exp: generate native core dump
UNSUPPORTED: gdb.base/auxv.exp: info auxv on native core dump
UNSUPPORTED: gdb.base/auxv.exp: matching auxv data from live and core
...

Using a patch to print debug info about core generation, we observe:
...
[  836s] + ulimit -a -H
[  836s] core file size          (blocks, -c) unlimited
[  836s] data seg size           (kbytes, -d) unlimited
[  836s] scheduling priority             (-e) 0
[  836s] file size               (blocks, -f) unlimited
[  836s] pending signals                 (-i) 11647
[  836s] max locked memory       (kbytes, -l) 64
[  836s] max memory size         (kbytes, -m) unlimited
[  836s] open files                      (-n) 4096
[  836s] pipe size            (512 bytes, -p) 8
[  836s] POSIX message queues     (bytes, -q) 819200
[  836s] real-time priority              (-r) 0
[  836s] stack size              (kbytes, -s) unlimited
[  836s] cpu time               (seconds, -t) unlimited
[  836s] max user processes              (-u) 16384
[  836s] virtual memory          (kbytes, -v) unlimited
[  836s] file locks                      (-x) unlimited
[  836s] + ulimit -a -S
[  836s] core file size          (blocks, -c) unlimited
[  836s] data seg size           (kbytes, -d) unlimited
[  836s] scheduling priority             (-e) 0
[  836s] file size               (blocks, -f) unlimited
[  836s] pending signals                 (-i) 11647
[  836s] max locked memory       (kbytes, -l) 64
[  836s] max memory size         (kbytes, -m) unlimited
[  836s] open files                      (-n) 1024
[  836s] pipe size            (512 bytes, -p) 8
[  836s] POSIX message queues     (bytes, -q) 819200
[  836s] real-time priority              (-r) 0
[  836s] stack size              (kbytes, -s) 8192
[  836s] cpu time               (seconds, -t) unlimited
[  836s] max user processes              (-u) 4096
[  836s] virtual memory          (kbytes, -v) unlimited
[  836s] file locks                      (-x) unlimited
[  836s] + cat /proc/sys/kernel/core_pattern
[  836s] /.build/cores/%p
[  836s] + ./orphanripper make -j4 -k check//unix/-m64 check//unix/-m64/-fno-PIE/-no-pie check//unix/-m32 check//unix/-m32/-fno-PIE/-no-pie
...

I got the test-case that use core generation to work on my local machine by hardcoding /proc/sys/kernel/core_pattern to 'core'.

It would be nice if the gdb testsuite could do the opposite: interpret /proc/sys/kernel/core_pattern to known where to find the core.