mbox series

[0/4] Modernize frame unwinders and add disable feature

Message ID 20240306125135.766567-1-blarsen@redhat.com
Headers
Series Modernize frame unwinders and add disable feature |

Message

Guinevere Larsen March 6, 2024, 12:51 p.m. UTC 
  This patch series started with me trying to make it easier to test GDB's
ability to unwind using CFI data, to improve a previous patch I sent to
the list. However, once I finished these changes, I realized there was
an unrelated bug I should fix before proposing the CFI test. Since these
changes are significant enough already, and I think would be interesting
on their own, I figured I shoudl submit this patch series as is right
now while I figure out the other bug.

The first patch is just a minor change, storing frame unwinders in a
vector instead of through an unwinder table accessible using the
registry system. This isn't required (like I originally thought it was),
but it does make the whole system more readable in my opinion.

Patch 3 has the real meat of the modernization, making GDB use
polymorphism to handle frame unwinders. This is slightly slower than
using function pointers, but much more readable in my opinion.

As for the unwinder classes, they were chosen somewhat arbitrarily,
mostly based on where I found an unwinder and its name. I almost expect
some unwinders to be mis-categorized, but that should be easy to fix.

The changes up to patch 3 have been tested with a try-branch, no
regressions as far as I could see.

Guinevere Larsen (4):
  gdb: make gdbarch store a vector of frame unwinders
  gdb: add "unwinder class" to frame unwinders
  gdb: Migrate frame unwinders to use C++ classes
  GDB: introduce ability to disable frame unwinders

 gdb/NEWS                                      |   7 +
 gdb/aarch64-tdep.c                            |  12 +-
 gdb/alpha-mdebug-tdep.c                       |   6 +-
 gdb/alpha-tdep.c                              |  12 +-
 gdb/amd64-obsd-tdep.c                         |   6 +-
 gdb/amd64-tdep.c                              |  24 +-
 gdb/amd64-windows-tdep.c                      |   6 +-
 gdb/amdgpu-tdep.c                             |   5 +-
 gdb/arc-tdep.c                                |  10 +-
 gdb/arch-utils.c                              |   8 +
 gdb/arm-tdep.c                                |  29 +-
 gdb/avr-tdep.c                                |   5 +-
 gdb/bfin-tdep.c                               |   6 +-
 gdb/bpf-tdep.c                                |   6 +-
 gdb/cris-tdep.c                               |  12 +-
 gdb/csky-tdep.c                               |  10 +-
 gdb/doc/gdb.texinfo                           |  24 ++
 gdb/dummy-frame.c                             |   8 +-
 gdb/dummy-frame.h                             |   2 +-
 gdb/dwarf2/frame-tailcall.c                   |   6 +-
 gdb/dwarf2/frame-tailcall.h                   |   2 +-
 gdb/dwarf2/frame.c                            |  16 +-
 gdb/frame-unwind.c                            | 359 ++++++++++++++----
 gdb/frame-unwind.h                            | 165 +++++++-
 gdb/frame.c                                   |  28 +-
 gdb/frv-linux-tdep.c                          |   6 +-
 gdb/frv-tdep.c                                |   5 +-
 gdb/ft32-tdep.c                               |   6 +-
 gdb/gdbarch.c                                 |   3 +
 gdb/gdbarch.h                                 |   5 +
 gdb/gdbarch.py                                |   3 +
 gdb/h8300-tdep.c                              |   5 +-
 gdb/hppa-linux-tdep.c                         |   5 +-
 gdb/hppa-tdep.c                               |  17 +-
 gdb/i386-obsd-tdep.c                          |   5 +-
 gdb/i386-tdep.c                               |  30 +-
 gdb/ia64-tdep.c                               |  24 +-
 gdb/inline-frame.c                            |   5 +-
 gdb/inline-frame.h                            |   2 +-
 gdb/iq2000-tdep.c                             |   5 +-
 gdb/jit.c                                     |   6 +-
 gdb/lm32-tdep.c                               |   5 +-
 gdb/loongarch-tdep.c                          |   7 +-
 gdb/m32c-tdep.c                               |   5 +-
 gdb/m32r-linux-tdep.c                         |   5 +-
 gdb/m32r-tdep.c                               |   5 +-
 gdb/m68hc11-tdep.c                            |   5 +-
 gdb/m68k-linux-tdep.c                         |   6 +-
 gdb/m68k-tdep.c                               |   6 +-
 gdb/mep-tdep.c                                |   5 +-
 gdb/microblaze-tdep.c                         |   6 +-
 gdb/mips-sde-tdep.c                           |   6 +-
 gdb/mips-tdep.c                               |  24 +-
 gdb/mn10300-tdep.c                            |   5 +-
 gdb/moxie-tdep.c                              |   5 +-
 gdb/msp430-tdep.c                             |   5 +-
 gdb/nds32-tdep.c                              |  14 +-
 gdb/nios2-tdep.c                              |  12 +-
 gdb/or1k-tdep.c                               |   7 +-
 gdb/ppc-fbsd-tdep.c                           |   5 +-
 gdb/ppc-obsd-tdep.c                           |   5 +-
 gdb/python/py-unwind.c                        |  50 ++-
 gdb/record-btrace.c                           |  12 +-
 gdb/record.h                                  |   4 +-
 gdb/riscv-tdep.c                              |   8 +-
 gdb/rl78-tdep.c                               |   6 +-
 gdb/rs6000-aix-tdep.c                         |   5 +-
 gdb/rs6000-tdep.c                             |  12 +-
 gdb/rx-tdep.c                                 |  10 +-
 gdb/s12z-tdep.c                               |   7 +-
 gdb/s390-linux-tdep.c                         |   5 +-
 gdb/s390-tdep.c                               |  10 +-
 gdb/sentinel-frame.c                          |   8 +-
 gdb/sentinel-frame.h                          |   2 +-
 gdb/sh-tdep.c                                 |  11 +-
 gdb/sparc-netbsd-tdep.c                       |   6 +-
 gdb/sparc-obsd-tdep.c                         |   6 +-
 gdb/sparc-sol2-tdep.c                         |   6 +-
 gdb/sparc-tdep.c                              |   6 +-
 gdb/sparc64-fbsd-tdep.c                       |   6 +-
 gdb/sparc64-netbsd-tdep.c                     |   6 +-
 gdb/sparc64-obsd-tdep.c                       |  12 +-
 gdb/sparc64-sol2-tdep.c                       |   6 +-
 gdb/sparc64-tdep.c                            |   6 +-
 gdb/testsuite/gdb.base/frame-unwind-disable.c |  21 +
 .../gdb.base/frame-unwind-disable.exp         | 114 ++++++
 gdb/tic6x-tdep.c                              |  12 +-
 gdb/tilegx-tdep.c                             |   5 +-
 gdb/tramp-frame.c                             |  50 ++-
 gdb/v850-tdep.c                               |   5 +-
 gdb/vax-tdep.c                                |   6 +-
 gdb/windows-tdep.c                            |  33 +-
 gdb/windows-tdep.h                            |  16 +-
 gdb/xstormy16-tdep.c                          |   5 +-
 gdb/xtensa-tdep.c                             |   7 +-
 gdb/z80-tdep.c                                |   7 +-
 96 files changed, 1098 insertions(+), 442 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/frame-unwind-disable.c
 create mode 100644 gdb/testsuite/gdb.base/frame-unwind-disable.exp

Comments

Luis Machado March 11, 2024, 2:56 p.m. UTC | #1 
Hi,

On 3/6/24 12:51, Guinevere Larsen wrote:
> This patch series started with me trying to make it easier to test GDB's
> ability to unwind using CFI data, to improve a previous patch I sent to
> the list. However, once I finished these changes, I realized there was
> an unrelated bug I should fix before proposing the CFI test. Since these
> changes are significant enough already, and I think would be interesting
> on their own, I figured I shoudl submit this patch series as is right
> now while I figure out the other bug.
> 
> The first patch is just a minor change, storing frame unwinders in a
> vector instead of through an unwinder table accessible using the
> registry system. This isn't required (like I originally thought it was),
> but it does make the whole system more readable in my opinion.
> 
> Patch 3 has the real meat of the modernization, making GDB use
> polymorphism to handle frame unwinders. This is slightly slower than
> using function pointers, but much more readable in my opinion.
> 
> As for the unwinder classes, they were chosen somewhat arbitrarily,
> mostly based on where I found an unwinder and its name. I almost expect
> some unwinders to be mis-categorized, but that should be easy to fix.
> 
> The changes up to patch 3 have been tested with a try-branch, no
> regressions as far as I could see.
> 
> Guinevere Larsen (4):
>   gdb: make gdbarch store a vector of frame unwinders
>   gdb: add "unwinder class" to frame unwinders
>   gdb: Migrate frame unwinders to use C++ classes
>   GDB: introduce ability to disable frame unwinders

I haven't gone through the series in detail, but I thought I'd give it a try on one of the
aarch64 machines I have access to. I didn't look particularly healthy:


# of unexpected core files      47
# of expected passes            116521
# of unexpected failures        581
# of expected failures          77
# of known failures             116
# of untested testcases         128
# of unresolved testcases       1102
# of unsupported tests          458
# of duplicate test names       10

I see a number of internal errors going on. Mostly like these:

        ../../../repos/binutils-gdb/gdbsupport/errors.cc:58
0xaaaad27e7877 check_ptrace_stopped_lwp_gone
        ../../../repos/binutils-gdb/gdb/linux-nat.c:1634
0xaaaad27e7877 check_ptrace_stopped_lwp_gone
        ../../../repos/binutils-gdb/gdb/linux-nat.c:1630
0xaaaad2ae0fa3 linux_resume_one_lwp
Guinevere Larsen March 11, 2024, 3 p.m. UTC | #2 
On 11/03/2024 15:56, Luis Machado wrote:
> Hi,
>
> On 3/6/24 12:51, Guinevere Larsen wrote:
>> This patch series started with me trying to make it easier to test GDB's
>> ability to unwind using CFI data, to improve a previous patch I sent to
>> the list. However, once I finished these changes, I realized there was
>> an unrelated bug I should fix before proposing the CFI test. Since these
>> changes are significant enough already, and I think would be interesting
>> on their own, I figured I shoudl submit this patch series as is right
>> now while I figure out the other bug.
>>
>> The first patch is just a minor change, storing frame unwinders in a
>> vector instead of through an unwinder table accessible using the
>> registry system. This isn't required (like I originally thought it was),
>> but it does make the whole system more readable in my opinion.
>>
>> Patch 3 has the real meat of the modernization, making GDB use
>> polymorphism to handle frame unwinders. This is slightly slower than
>> using function pointers, but much more readable in my opinion.
>>
>> As for the unwinder classes, they were chosen somewhat arbitrarily,
>> mostly based on where I found an unwinder and its name. I almost expect
>> some unwinders to be mis-categorized, but that should be easy to fix.
>>
>> The changes up to patch 3 have been tested with a try-branch, no
>> regressions as far as I could see.
>>
>> Guinevere Larsen (4):
>>    gdb: make gdbarch store a vector of frame unwinders
>>    gdb: add "unwinder class" to frame unwinders
>>    gdb: Migrate frame unwinders to use C++ classes
>>    GDB: introduce ability to disable frame unwinders
> I haven't gone through the series in detail, but I thought I'd give it a try on one of the
> aarch64 machines I have access to. I didn't look particularly healthy:
>
>
> # of unexpected core files      47
> # of expected passes            116521
> # of unexpected failures        581
> # of expected failures          77
> # of known failures             116
> # of untested testcases         128
> # of unresolved testcases       1102
> # of unsupported tests          458
> # of duplicate test names       10
>
> I see a number of internal errors going on. Mostly like these:
>
>          ../../../repos/binutils-gdb/gdbsupport/errors.cc:58
> 0xaaaad27e7877 check_ptrace_stopped_lwp_gone
>          ../../../repos/binutils-gdb/gdb/linux-nat.c:1634
> 0xaaaad27e7877 check_ptrace_stopped_lwp_gone
>          ../../../repos/binutils-gdb/gdb/linux-nat.c:1630
> 0xaaaad2ae0fa3 linux_resume_one_lwp
>
Oh no! Linaro CI had showed something was wrong, but I wasn't able to 
grab an aarch64 machine to test yet. I'll check it out when I can, 
thanks for narrowing it down for me
Luis Machado March 11, 2024, 3:10 p.m. UTC | #3 
On 3/11/24 15:00, Guinevere Larsen wrote:
> On 11/03/2024 15:56, Luis Machado wrote:
>> Hi,
>>
>> On 3/6/24 12:51, Guinevere Larsen wrote:
>>> This patch series started with me trying to make it easier to test GDB's
>>> ability to unwind using CFI data, to improve a previous patch I sent to
>>> the list. However, once I finished these changes, I realized there was
>>> an unrelated bug I should fix before proposing the CFI test. Since these
>>> changes are significant enough already, and I think would be interesting
>>> on their own, I figured I shoudl submit this patch series as is right
>>> now while I figure out the other bug.
>>>
>>> The first patch is just a minor change, storing frame unwinders in a
>>> vector instead of through an unwinder table accessible using the
>>> registry system. This isn't required (like I originally thought it was),
>>> but it does make the whole system more readable in my opinion.
>>>
>>> Patch 3 has the real meat of the modernization, making GDB use
>>> polymorphism to handle frame unwinders. This is slightly slower than
>>> using function pointers, but much more readable in my opinion.
>>>
>>> As for the unwinder classes, they were chosen somewhat arbitrarily,
>>> mostly based on where I found an unwinder and its name. I almost expect
>>> some unwinders to be mis-categorized, but that should be easy to fix.
>>>
>>> The changes up to patch 3 have been tested with a try-branch, no
>>> regressions as far as I could see.
>>>
>>> Guinevere Larsen (4):
>>>    gdb: make gdbarch store a vector of frame unwinders
>>>    gdb: add "unwinder class" to frame unwinders
>>>    gdb: Migrate frame unwinders to use C++ classes
>>>    GDB: introduce ability to disable frame unwinders
>> I haven't gone through the series in detail, but I thought I'd give it a try on one of the
>> aarch64 machines I have access to. I didn't look particularly healthy:
>>
>>
>> # of unexpected core files      47
>> # of expected passes            116521
>> # of unexpected failures        581
>> # of expected failures          77
>> # of known failures             116
>> # of untested testcases         128
>> # of unresolved testcases       1102
>> # of unsupported tests          458
>> # of duplicate test names       10
>>
>> I see a number of internal errors going on. Mostly like these:
>>
>>          ../../../repos/binutils-gdb/gdbsupport/errors.cc:58
>> 0xaaaad27e7877 check_ptrace_stopped_lwp_gone
>>          ../../../repos/binutils-gdb/gdb/linux-nat.c:1634
>> 0xaaaad27e7877 check_ptrace_stopped_lwp_gone
>>          ../../../repos/binutils-gdb/gdb/linux-nat.c:1630
>> 0xaaaad2ae0fa3 linux_resume_one_lwp
>>
> Oh no! Linaro CI had showed something was wrong, but I wasn't able to grab an aarch64 machine to test yet. I'll check it out when I can, thanks for narrowing it down for me
> 

You're welcome. Do let me know if you can't easily find an aarch64 machine to try things on, and I can provide more info
and take a deeper look.
Guinevere Larsen March 13, 2024, 12:08 p.m. UTC | #4 
On 11/03/2024 16:10, Luis Machado wrote:
> On 3/11/24 15:00, Guinevere Larsen wrote:
>> On 11/03/2024 15:56, Luis Machado wrote:
>>> Hi,
>>>
>>> On 3/6/24 12:51, Guinevere Larsen wrote:
>>>> This patch series started with me trying to make it easier to test GDB's
>>>> ability to unwind using CFI data, to improve a previous patch I sent to
>>>> the list. However, once I finished these changes, I realized there was
>>>> an unrelated bug I should fix before proposing the CFI test. Since these
>>>> changes are significant enough already, and I think would be interesting
>>>> on their own, I figured I shoudl submit this patch series as is right
>>>> now while I figure out the other bug.
>>>>
>>>> The first patch is just a minor change, storing frame unwinders in a
>>>> vector instead of through an unwinder table accessible using the
>>>> registry system. This isn't required (like I originally thought it was),
>>>> but it does make the whole system more readable in my opinion.
>>>>
>>>> Patch 3 has the real meat of the modernization, making GDB use
>>>> polymorphism to handle frame unwinders. This is slightly slower than
>>>> using function pointers, but much more readable in my opinion.
>>>>
>>>> As for the unwinder classes, they were chosen somewhat arbitrarily,
>>>> mostly based on where I found an unwinder and its name. I almost expect
>>>> some unwinders to be mis-categorized, but that should be easy to fix.
>>>>
>>>> The changes up to patch 3 have been tested with a try-branch, no
>>>> regressions as far as I could see.
>>>>
>>>> Guinevere Larsen (4):
>>>>     gdb: make gdbarch store a vector of frame unwinders
>>>>     gdb: add "unwinder class" to frame unwinders
>>>>     gdb: Migrate frame unwinders to use C++ classes
>>>>     GDB: introduce ability to disable frame unwinders
>>> I haven't gone through the series in detail, but I thought I'd give it a try on one of the
>>> aarch64 machines I have access to. I didn't look particularly healthy:
>>>
>>>
>>> # of unexpected core files      47
>>> # of expected passes            116521
>>> # of unexpected failures        581
>>> # of expected failures          77
>>> # of known failures             116
>>> # of untested testcases         128
>>> # of unresolved testcases       1102
>>> # of unsupported tests          458
>>> # of duplicate test names       10
>>>
>>> I see a number of internal errors going on. Mostly like these:
>>>
>>>           ../../../repos/binutils-gdb/gdbsupport/errors.cc:58
>>> 0xaaaad27e7877 check_ptrace_stopped_lwp_gone
>>>           ../../../repos/binutils-gdb/gdb/linux-nat.c:1634
>>> 0xaaaad27e7877 check_ptrace_stopped_lwp_gone
>>>           ../../../repos/binutils-gdb/gdb/linux-nat.c:1630
>>> 0xaaaad2ae0fa3 linux_resume_one_lwp
>>>
>> Oh no! Linaro CI had showed something was wrong, but I wasn't able to grab an aarch64 machine to test yet. I'll check it out when I can, thanks for narrowing it down for me
>>
> You're welcome. Do let me know if you can't easily find an aarch64 machine to try things on, and I can provide more info
> and take a deeper look.
>
I think I found the reason why aarch64 started failing so many cases. 
Can you try the following change and see if it works?

I'm not 100% sure because the machine I'm using seems to have some 
rather unstable results, but I think it should have solved the problem.
Luis Machado March 13, 2024, 12:44 p.m. UTC | #5 
On 3/13/24 12:08, Guinevere Larsen wrote:
> On 11/03/2024 16:10, Luis Machado wrote:
>> On 3/11/24 15:00, Guinevere Larsen wrote:
>>> On 11/03/2024 15:56, Luis Machado wrote:
>>>> Hi,
>>>>
>>>> On 3/6/24 12:51, Guinevere Larsen wrote:
>>>>> This patch series started with me trying to make it easier to test GDB's
>>>>> ability to unwind using CFI data, to improve a previous patch I sent to
>>>>> the list. However, once I finished these changes, I realized there was
>>>>> an unrelated bug I should fix before proposing the CFI test. Since these
>>>>> changes are significant enough already, and I think would be interesting
>>>>> on their own, I figured I shoudl submit this patch series as is right
>>>>> now while I figure out the other bug.
>>>>>
>>>>> The first patch is just a minor change, storing frame unwinders in a
>>>>> vector instead of through an unwinder table accessible using the
>>>>> registry system. This isn't required (like I originally thought it was),
>>>>> but it does make the whole system more readable in my opinion.
>>>>>
>>>>> Patch 3 has the real meat of the modernization, making GDB use
>>>>> polymorphism to handle frame unwinders. This is slightly slower than
>>>>> using function pointers, but much more readable in my opinion.
>>>>>
>>>>> As for the unwinder classes, they were chosen somewhat arbitrarily,
>>>>> mostly based on where I found an unwinder and its name. I almost expect
>>>>> some unwinders to be mis-categorized, but that should be easy to fix.
>>>>>
>>>>> The changes up to patch 3 have been tested with a try-branch, no
>>>>> regressions as far as I could see.
>>>>>
>>>>> Guinevere Larsen (4):
>>>>>     gdb: make gdbarch store a vector of frame unwinders
>>>>>     gdb: add "unwinder class" to frame unwinders
>>>>>     gdb: Migrate frame unwinders to use C++ classes
>>>>>     GDB: introduce ability to disable frame unwinders
>>>> I haven't gone through the series in detail, but I thought I'd give it a try on one of the
>>>> aarch64 machines I have access to. I didn't look particularly healthy:
>>>>
>>>>
>>>> # of unexpected core files      47
>>>> # of expected passes            116521
>>>> # of unexpected failures        581
>>>> # of expected failures          77
>>>> # of known failures             116
>>>> # of untested testcases         128
>>>> # of unresolved testcases       1102
>>>> # of unsupported tests          458
>>>> # of duplicate test names       10
>>>>
>>>> I see a number of internal errors going on. Mostly like these:
>>>>
>>>>           ../../../repos/binutils-gdb/gdbsupport/errors.cc:58
>>>> 0xaaaad27e7877 check_ptrace_stopped_lwp_gone
>>>>           ../../../repos/binutils-gdb/gdb/linux-nat.c:1634
>>>> 0xaaaad27e7877 check_ptrace_stopped_lwp_gone
>>>>           ../../../repos/binutils-gdb/gdb/linux-nat.c:1630
>>>> 0xaaaad2ae0fa3 linux_resume_one_lwp
>>>>
>>> Oh no! Linaro CI had showed something was wrong, but I wasn't able to grab an aarch64 machine to test yet. I'll check it out when I can, thanks for narrowing it down for me
>>>
>> You're welcome. Do let me know if you can't easily find an aarch64 machine to try things on, and I can provide more info
>> and take a deeper look.
>>
> I think I found the reason why aarch64 started failing so many cases. Can you try the following change and see if it works?
> 
> I'm not 100% sure because the machine I'm using seems to have some rather unstable results, but I think it should have solved the problem.
> 

The attached fixlet completely clears things up, and the testsuite for aarch64-linux is back to normal.

# of unexpected core files      1
# of expected passes            119178
# of unexpected failures        22
# of expected failures          77
# of known failures             120
# of untested testcases         128
# of unsupported tests          458
# of duplicate test names       3