Commit Graph

3 Commits

Author SHA1 Message Date
Tao Liu 1fd80c623c Preparing for gdb stack unwind support
There are 3 designs for supporting arbitrary tasks stack unwinding:
  1) One gdb thread represent a task[1][2].
  2) One gdb thread represent a cpu[3].
  3) Leaving only one gdb thread[4].

1 & 2 have a flaw that, when there are lots of tasks/cpus, it will slow
the startup of crash, introduce complexity of the registers context
synchronization between crash and gdb, hard to cover live debug mode
etc. So here we used the 3rd design.

Related discussions:
  [1]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00524.html
  [2]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00529.html
  [3]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00471.html
  [4]: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg00541.html

To switch task, or view arbitrary tasks stack unwinding, we will reuse
the current gdb thread, and load the target task's regcache to the
thread. This will simplify many code.

Note: this will change the behavior of "info threads" and "thread x", E.g:

Before:
  crash> gdb thread
  [Current thread is 1 (CPU 0)]
  crash> info threads
    Id   Target Id         Frame
  * 1    CPU 0             <unavailable> in ?? ()
    2    CPU 1             <unavailable> in ?? ()
    3    CPU 2             <unavailable> in ?? ()
    ...
  crash> thread 2
  [Switching to thread 2 (CPU 1)]
   #0  <unavailable> in ?? ()

After:
  crash> gdb thread
  [Current thread is 1 (10715 bash)]
  crash> info threads
    Id   Target Id         Frame
  * 1    10715 bash        0xc0000000002bde04 in crash_setup_regs ...
  crash> thread 2
  gdb: gdb request failed: thread 2

As a result, the "info threads" and "thread x" will be less useful. We
will extend cmd "set" later to implement a similar function. E.g:

  crash> set <pid|task>

Then the task context of crash and gdb will both be switched to
pid/task, so the following command: "bt" "gdb bt" will output
the same task context.

[lijiang: squash these four patches(see the Link) into one patch]

Link: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01085.html
Link: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01087.html
Link: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01086.html
Link: https://www.mail-archive.com/devel@lists.crash-utility.osci.io/msg01088.html
Co-developed-by: Aditya Gupta <adityag@linux.ibm.com>
Co-developed-by: Alexey Makhalov <alexey.makhalov@broadcom.com>
Signed-off-by: Tao Liu <ltao@redhat.com>
2024-11-04 15:06:45 +08:00
Alexey Makhalov 2f967fb5eb crash_taget: fetch_registers support
Provides API for crash_target to fetch registers of given
CPU. It will allow gdb to perform such commands as "bt",
"frame", "info locals".

Highlevel API is crash_get_cpu_reg (). It calls machine
(architecture) specific function: machdep->get_cpu_reg().
Input arguments such as register number and register size
come from gdb arch information. So, get_cpu_regs()
implementations in crash must understand it.

Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
2021-09-28 17:00:19 +08:00
Alexey Makhalov 9fab193edb Update to gdb-10.2
Main changes:
[1] update gdb-7.6.patch to gdb-10.2.patch, and keep all functionality
    and good compatibility
[2] remove unneeded patches(gdb-7.6-proc_service.h.patch and
    gdb-7.6-ppc64le-support.patch)
[3] to make the c++ compiler happy, add the extern "C" to eliminate
    compilation issues, also add CXXFLAGS=-m32 to generate proper
    32bit object files
[4] the parameter types of some functions are changed, eg, the set of
    prettyprint variables
[5] eliminate error_hook() and SJLJ while running in C++ code (after
    gdb_command_funnel()) use try-catch mechanism instead
[6] request_types() is redone to do not call GNU_GET_NEXT_DATATYPE multiple
    times but single usage of GNU_ITERATE_DATATYPES with proper callback
    instead. Complete iteration happens on C++ side now.
[7] remove "struct global_iterator" from request structure, but add
    several fields (including callback pointer) to be able to perform
    iteration on C++ side
[8] type of "linux_banner" symbol is reported as 'D' by new gdb as its
    section ".rodata" marked as writable in vmlinux
[9] BFD API has changed.
[10] the deprecated_command_loop_hook got deprecated. So, call crash
     main_loop() directly from gdb captured_main()
[11] remove previously used hooks for that in target.c. Add crash_target
     for gdb to provide target operations such as xfer_partial to read
     and write crash dump memory.

Signed-off-by: Alexey Makhalov <amakhalov@vmware.com>
Signed-off-by: Lianbo Jiang <lijiang@redhat.com>
2021-09-28 17:00:05 +08:00