corefiles/1105: expected behavior of corefiles and gcore

[ac131313 at redhat dot com]

>Number:         1105
>Category:       corefiles
>Synopsis:       expected behavior of corefiles and gcore
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 02 03:18:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     ac131313 at redhat dot com
>Release:        unknown-1.0
>Organization:
>Environment:

>Description:
(notes from a hallway conversation, this needs to be tested)

When using GDB on a live threaded program that puts all threads into tight infinite loops (while (1);), I'll do something like:

    $ ./a.out &
    Pid 1234
    $ gdb ./a.out 1234
    (gdb) info threads
    ....
    (gdb) quit

As a user I'd also expect sequences such as:

    $ kill -QUIT 1234
    $ gdb ./a.out core
    (gdb) info threads
    ....
    (gdb) quit

and:

    $ gcore 1234
    $ gdb ./a.out core
    (gdb) info threads
    ....
    (gdb) quit

and:

    $ gdb ./a.out 1234
    (gdb) gcore
    (gdb) quit
    $ gdb ./a.out core
    (gdb) info threads

to all come back with effectively the same output.  Further, on both live and corefile targets, I'd expect to be able to select/examine each thread vis:

    (gdb) thread 5
    11    i = i + 1;
    (gdb) list
    10    __thread__ i = 1;
    11    i = i + 1;
    (gdb) print i
    $1 = 1

(which would involve thread local storage).

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: