[Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[vsfos at foxmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

            Bug ID: 28018
           Summary: internal-error: Assertion 'TYPE_LENGTH(index_type) >
                    0' failed in create_range_type
           Product: gdb
           Version: 10.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: breakpoints
          Assignee: unassigned at sourceware dot org
          Reporter: vsfos at foxmail dot com
  Target Milestone: ---

I'm using arm-none-eabi toolchain from ARM to develop a program for a CortexM
device. And while debugging the program, failure assertion in create_range_type
will occur if some breakpoints are triggered. But some other breakpoints are
good.

The toolchain is at:
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads,
Version 10-2020-q4-major. And the debug environment is vscode(with cortex-debug
extension) + arm-none-eabi-gdb + jlink.

Debug console output:
Please check OUTPUT tab (Adapter Output) for output from JLinkGDBServerCL.exe
Launching server: "JLinkGDBServerCL.exe" "-if" "swd" "-port" "50000" "-swoport"
"50001" "-telnetport" "50002" "-device" "Cortex-M4"
Launching GDB: "arm-none-eabi-gdb.exe" "-q" "--interpreter=mi2"
undefinedC:\Program Files (x86)\GNU Arm Embedded Toolchain\10
2020-q4-major\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for
the index cache directory.
Reading symbols from
Z:\vsf\example\template\project\cmake\aic8800\build\vsf_template.elf...
vsf_arch_sleep (mode=0) at
z:/vsf/source/utilities/compiler/arm/3rd-party/CMSIS/CMSIS/Core/Include/cmsis_gcc.h:348
348     
Not implemented stop reason (assuming exception): undefined

Breakpoint 1, __vsf_debug_stream_on_rx () at
Z:/vsf/source/hal/driver/AIC/AIC8800/debug_uart/debug_uart.c:75
75              ch = stdio_uart_rxdata_getf();

Program
 received signal SIGTRAP, Trace/breakpoint trap.
vsf_arch_sleep (mode=0) at
z:/vsf/source/utilities/compiler/arm/3rd-party/CMSIS/CMSIS/Core/Include/cmsis_gcc.h:348
348     

Breakpoint 3, vsh_main (argc=0, argv=0x100044) at
Z:/vsf/source/shell/sys/linux/port/busybox/shell/vsh.c:255
255                 switch (ch) {
/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/src/gdb/gdb/gdbtypes.c:931:
internal-error: type* create_range_type(type*, type*, const dynamic_prop*,
const dynamic_prop*, LONGEST): Assertion `TYPE_LENGTH (index_type) > 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Quit this debugging session? 
(y or n) [answered Y; input not from terminal]

This is a bug, please report it.
  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/src/gdb/gdb/gdbtypes.c:931:
internal-error: type* create_range_type(type*, type*, const dynamic_prop*,
const dynamic_prop*, LONGEST): Assertion `TYPE_LENGTH (index_type) > 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Create a core file of GDB? 
(y or n) [answered Y; input not from terminal]

The console information tells me to report the bug here.

And the output from Jlink GDB server:
SEGGER J-Link GDB Server V7.22b Command Line Version

JLinkARM.dll V7.22b (DLL compiled Jun 17 2021 17:22:49)

Command line: -if swd -port 50000 -swoport 50001 -telnetport 50002 -device
Cortex-M4
-----GDB Server start settings-----
GDBInit file:                  none
GDB Server Listening port:     50000
SWO raw output listening port: 50001
Terminal I/O port:             50002
Accept remote connection:      localhost only
Generate logfile:              off
Verify download:               off
Init regs on start:            off
Silent mode:                   off
Single run mode:               off
Target connection timeout:     0 ms
------J-Link related settings------
J-Link Host interface:         USB
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 Cortex-M4
Target interface:              SWD
Target interface speed:        4000kHz
Target endian:                 little

Connecting to J-Link...
J-Link is connected.
Firmware: J-Link V10 compiled Jun 17 2021 16:40:36
Hardware: V10.10
S/N: 260117558
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 4.16 V
Listening on TCP/IP port 50000
Connecting to target...
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x0809A08E (Data = 0xBA404770)
Read 2 bytes @ address 0x0809A08E (Data = 0x4770)
Reading 64 bytes @ address 0x0809A080
Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0x0809A08E)
Reading 64 bytes @ address 0x0809A480
Read 4 bytes @ address 0x0809A4EC (Data = 0x001A1DF0)
Read 2 bytes @ address 0x0809A4CC (Data = 0xF88D)
Reading 64 bytes @ address 0x08001CC0
Read 2 bytes @ address 0x08001CE2 (Data = 0xF0ED)
Read 4 bytes @ address 0x080AD622 (Data = 0xB508BD08)
Reading 64 bytes @ address 0x080AD600
Reading 64 bytes @ address 0x001C7EC0
Read 4 bytes @ address 0x080AD62A (Data = 0x4770BD08)
Read 4 bytes @ address 0x080AD69A (Data = 0xB5F0E7FA)
Reading 64 bytes @ address 0x080AD680
Read 4 bytes @ address 0x080AD342 (Data = 0xB158BD08)
Reading 64 bytes @ address 0x080AD300
Reading 64 bytes @ address 0x080AD340
Read 4 bytes @ address 0x08126CD8 (Data = 0xE7F23601)
Read 4 bytes @ address 0x0800021E (Data = 0x00290020)
Reading 64 bytes @ address 0x080001C0
Read 4 bytes @ address 0x08000238 (Data = 0x001C7F00)
Read 4 bytes @ address 0x0800022E (Data = 0x00000008)
Reading register (MSP = 0x  1C7ED0)
Reading register (PSP = 0x       0)
Reading register (PRIMASK = 0x       0)
Reading register (BASEPRI = 0x       0)
Reading register (FAULTMASK = 0x       0)
Reading register (CONTROL = 0x       0)
Reading register (FPSCR = 0x       0)
Reading register (s0 = 0x       0)
Reading register (s1 = 0x       0)
Reading register (s2 = 0x       0)
Reading register (s3 = 0x       0)
Reading register (s4 = 0x       0)
Reading register (s5 = 0x       0)
Reading register (s6 = 0x       0)
Reading register (s7 = 0x       0)
Reading register (s8 = 0x       0)
Reading register (s9 = 0x       0)
Reading register (s10 = 0x       0)
Reading register (s11 = 0x       0)
Reading register (s12 = 0x       0)
Reading register (s13 = 0x       0)
Reading register (s14 = 0x       0)
Reading register (s15 = 0x       0)
Reading register (s16 = 0x       0)
Reading register (s17 = 0x       0)
Reading register (s18 = 0x       0)
Reading register (s19 = 0x       0)
Reading register (s20 = 0x       0)
Reading register (s21 = 0x       0)
Reading register (s22 = 0x       0)
Reading register (s23 = 0x       0)
Reading register (s24 = 0x       0)
Reading register (s25 = 0x       0)
Reading register (s26 = 0x       0)
Reading register (s27 = 0x       0)
Reading register (s28 = 0x       0)
Reading register (s29 = 0x       0)
Reading register (s30 = 0x       0)
Reading register (s31 = 0x       0)
Reading register (d0 = 0x       0)
Reading register (d1 = 0x       0)
Reading register (d2 = 0x       0)
Reading register (d3 = 0x       0)
Reading register (d4 = 0x       0)
Reading register (d5 = 0x       0)
Reading register (d6 = 0x       0)
Reading register (d7 = 0x       0)
Reading register (d8 = 0x       0)
Reading register (d9 = 0x       0)
Reading register (d10 = 0x       0)
Reading register (d11 = 0x       0)
Reading register (d12 = 0x       0)
Reading register (d13 = 0x       0)
Reading register (d14 = 0x       0)
Reading register (d15 = 0x       0)
Setting breakpoint @ address 0x08001CE2, Size = 2, BPHandle = 0x0001
Setting breakpoint @ address 0x0809A4CC, Size = 2, BPHandle = 0x0002
Starting target CPU...
...Breakpoint reached @ address 0x0809A4CC
Reading all registers
Removing breakpoint @ address 0x08001CE2, Size = 2
Removing breakpoint @ address 0x0809A4CC, Size = 2
Read 4 bytes @ address 0x0809A4CC (Data = 0x3007F88D)
Read 2 bytes @ address 0x0809A4CC (Data = 0xF88D)
Read 2 bytes @ address 0x0809A4CE (Data = 0x3007)
Reading 64 bytes @ address 0x0809A480
Read 4 bytes @ address 0x0809A4EC (Data = 0x001A1DF0)
Reading 64 bytes @ address 0x0809A4C0
Reading register (MSP = 0x  1C7E98)
Reading register (PSP = 0x       0)
Reading register (PRIMASK = 0x       0)
Reading register (BASEPRI = 0x       0)
Reading register (FAULTMASK = 0x       0)
Reading register (CONTROL = 0x       0)
Reading register (FPSCR = 0x       0)
Reading register (s0 = 0x       0)
Reading register (s1 = 0x       0)
Reading register (s2 = 0x       0)
Reading register (s3 = 0x       0)
Reading register (s4 = 0x       0)
Reading register (s5 = 0x       0)
Reading register (s6 = 0x       0)
Reading register (s7 = 0x       0)
Reading register (s8 = 0x       0)
Reading register (s9 = 0x       0)
Reading register (s10 = 0x       0)
Reading register (s11 = 0x       0)
Reading register (s12 = 0x       0)
Reading register (s13 = 0x       0)
Reading register (s14 = 0x       0)
Reading register (s15 = 0x       0)
Reading register (s16 = 0x       0)
Reading register (s17 = 0x       0)
Reading register (s18 = 0x       0)
Reading register (s19 = 0x       0)
Reading register (s20 = 0x       0)
Reading register (s21 = 0x       0)
Reading register (s22 = 0x       0)
Reading register (s23 = 0x       0)
Reading register (s24 = 0x       0)
Reading register (s25 = 0x       0)
Reading register (s26 = 0x       0)
Reading register (s27 = 0x       0)
Reading register (s28 = 0x       0)
Reading register (s29 = 0x       0)
Reading register (s30 = 0x       0)
Reading register (s31 = 0x       0)
Reading register (d0 = 0x       0)
Reading register (d1 = 0x       0)
Reading register (d2 = 0x       0)
Reading register (d3 = 0x       0)
Reading register (d4 = 0x       0)
Reading register (d5 = 0x       0)
Reading register (d6 = 0x       0)
Reading register (d7 = 0x       0)
Reading register (d8 = 0x       0)
Reading register (d9 = 0x       0)
Reading register (d10 = 0x       0)
Reading register (d11 = 0x       0)
Reading register (d12 = 0x       0)
Reading register (d13 = 0x       0)
Reading register (d14 = 0x       0)
Reading register (d15 = 0x       0)
Reading 64 bytes @ address 0x001C7E80
Read 4 bytes @ address 0x080AAF72 (Data = 0x4B04E7F9)
Reading 64 bytes @ address 0x080AAF40
Read 4 bytes @ address 0x080AAF8A (Data = 0x90384004)
Read 4 bytes @ address 0x001C7ECC (Data = 0x61000000)
Reading 64 bytes @ address 0x001C7EC0
Read 4 bytes @ address 0x0809A08E (Data = 0xBA404770)
Reading 64 bytes @ address 0x0809A080
Read 4 bytes @ address 0x080AD622 (Data = 0xB508BD08)
Reading 64 bytes @ address 0x080AD600
Read 4 bytes @ address 0x080AD62A (Data = 0x4770BD08)
Read 4 bytes @ address 0x080AD69A (Data = 0xB5F0E7FA)
Reading 64 bytes @ address 0x080AD680
Read 4 bytes @ address 0x080AD342 (Data = 0xB158BD08)
Reading 64 bytes @ address 0x080AD300
Reading 64 bytes @ address 0x080AD340
Read 4 bytes @ address 0x08126CD8 (Data = 0xE7F23601)
Read 4 bytes @ address 0x0800021E (Data = 0x00290020)
Reading 64 bytes @ address 0x080001C0
Read 4 bytes @ address 0x08000238 (Data = 0x001C7F00)
Read 4 bytes @ address 0x0800022E (Data = 0x00000008)
Setting breakpoint @ address 0x08001CE2, Size = 2, BPHandle = 0x0003
Performing single step...
...Target halted (DBGRQ, PC = 0x0809A4D0)
Reading all registers
Read 4 bytes @ address 0x0809A4D0 (Data = 0xF10D2201)
Read 2 bytes @ address 0x0809A4D0 (Data = 0x2201)
Reading 64 bytes @ address 0x0809A480
Read 4 bytes @ address 0x0809A4EC (Data = 0x001A1DF0)
Reading 64 bytes @ address 0x0809A4C0
Removing breakpoint @ address 0x08001CE2, Size = 2
Read 4 bytes @ address 0x0809A4D0 (Data = 0xF10D2201)
Read 2 bytes @ address 0x0809A4D0 (Data = 0x2201)
Read 4 bytes @ address 0x0809A4EC (Data = 0x001A1DF0)
Reading register (MSP = 0x  1C7E98)
Reading register (PSP = 0x       0)
Reading register (PRIMASK = 0x       0)
Reading register (BASEPRI = 0x       0)
Reading register (FAULTMASK = 0x       0)
Reading register (CONTROL = 0x       0)
Reading register (FPSCR = 0x       0)
Reading register (s0 = 0x       0)
Reading register (s1 = 0x       0)
Reading register (s2 = 0x       0)
Reading register (s3 = 0x       0)
Reading register (s4 = 0x       0)
Reading register (s5 = 0x       0)
Reading register (s6 = 0x       0)
Reading register (s7 = 0x       0)
Reading register (s8 = 0x       0)
Reading register (s9 = 0x       0)
Reading register (s10 = 0x       0)
Reading register (s11 = 0x       0)
Reading register (s12 = 0x       0)
Reading register (s13 = 0x       0)
Reading register (s14 = 0x       0)
Reading register (s15 = 0x       0)
Reading register (s16 = 0x       0)
Reading register (s17 = 0x       0)
Reading register (s18 = 0x       0)
Reading register (s19 = 0x       0)
Reading register (s20 = 0x       0)
Reading register (s21 = 0x       0)
Reading register (s22 = 0x       0)
Reading register (s23 = 0x       0)
Reading register (s24 = 0x       0)
Reading register (s25 = 0x       0)
Reading register (s26 = 0x       0)
Reading register (s27 = 0x       0)
Reading register (s28 = 0x       0)
Reading register (s29 = 0x       0)
Reading register (s30 = 0x       0)
Reading register (s31 = 0x       0)
Reading register (d0 = 0x       0)
Reading register (d1 = 0x       0)
Reading register (d2 = 0x       0)
Reading register (d3 = 0x       0)
Reading register (d4 = 0x       0)
Reading register (d5 = 0x       0)
Reading register (d6 = 0x       0)
Reading register (d7 = 0x       0)
Reading register (d8 = 0x       0)
Reading register (d9 = 0x       0)
Reading register (d10 = 0x       0)
Reading register (d11 = 0x       0)
Reading register (d12 = 0x       0)
Reading register (d13 = 0x       0)
Reading register (d14 = 0x       0)
Reading register (d15 = 0x       0)
Reading 64 bytes @ address 0x001C7E80
Read 4 bytes @ address 0x080AAF72 (Data = 0x4B04E7F9)
Reading 64 bytes @ address 0x080AAF40
Read 4 bytes @ address 0x080AAF8A (Data = 0x90384004)
Read 4 bytes @ address 0x001C7ECC (Data = 0x61000000)
Reading 64 bytes @ address 0x001C7EC0
Read 4 bytes @ address 0x0809A08E (Data = 0xBA404770)
Reading 64 bytes @ address 0x0809A080
Read 4 bytes @ address 0x080AD622 (Data = 0xB508BD08)
Reading 64 bytes @ address 0x080AD600
Read 4 bytes @ address 0x080AD62A (Data = 0x4770BD08)
Read 4 bytes @ address 0x080AD69A (Data = 0xB5F0E7FA)
Reading 64 bytes @ address 0x080AD680
Read 4 bytes @ address 0x080AD342 (Data = 0xB158BD08)
Reading 64 bytes @ address 0x080AD300
Reading 64 bytes @ address 0x080AD340
Read 4 bytes @ address 0x08126CD8 (Data = 0xE7F23601)
Read 4 bytes @ address 0x0800021E (Data = 0x00290020)
Reading 64 bytes @ address 0x080001C0
Read 4 bytes @ address 0x08000238 (Data = 0x001C7F00)
Read 4 bytes @ address 0x0800022E (Data = 0x00000008)
Setting breakpoint @ address 0x08001CE2, Size = 2, BPHandle = 0x0004
Starting target CPU...
Debugger requested to halt target...
...Target halted (PC = 0x0809A08E)
Reading all registers
Removing breakpoint @ address 0x08001CE2, Size = 2
Read 4 bytes @ address 0x0809A08E (Data = 0xBA404770)
Read 2 bytes @ address 0x0809A08E (Data = 0x4770)
Reading 64 bytes @ address 0x0809A080
Reading 64 bytes @ address 0x080B1D00
Read 2 bytes @ address 0x080B1D76 (Data = 0xF89D)
Setting breakpoint @ address 0x08001CE2, Size = 2, BPHandle = 0x0005
Setting breakpoint @ address 0x080B1D76, Size = 2, BPHandle = 0x0006
Starting target CPU...
...Breakpoint reached @ address 0x080B1D76
Reading all registers
Removing breakpoint @ address 0x08001CE2, Size = 2
Removing breakpoint @ address 0x080B1D76, Size = 2
Read 4 bytes @ address 0x080B1D76 (Data = 0x3007F89D)
Read 2 bytes @ address 0x080B1D76 (Data = 0xF89D)
Read 2 bytes @ address 0x080B1D78 (Data = 0x3007)
Reading 64 bytes @ address 0x080B1D00
Reading register (MSP = 0x  101030)
Reading register (PSP = 0x       0)
Reading register (PRIMASK = 0x       0)
Reading register (BASEPRI = 0x       0)
Reading register (FAULTMASK = 0x       0)
Reading register (CONTROL = 0x       0)
Reading register (FPSCR = 0x       0)
Reading register (s0 = 0x       0)
Reading register (s1 = 0x       0)
Reading register (s2 = 0x       0)
Reading register (s3 = 0x       0)
Reading register (s4 = 0x       0)
Reading register (s5 = 0x       0)
Reading register (s6 = 0x       0)
Reading register (s7 = 0x       0)
Reading register (s8 = 0x       0)
Reading register (s9 = 0x       0)
Reading register (s10 = 0x       0)
Reading register (s11 = 0x       0)
Reading register (s12 = 0x       0)
Reading register (s13 = 0x       0)
Reading register (s14 = 0x       0)
Reading register (s15 = 0x       0)
Reading register (s16 = 0x       0)
Reading register (s17 = 0x       0)
Reading register (s18 = 0x       0)
Reading register (s19 = 0x       0)
Reading register (s20 = 0x       0)
Reading register (s21 = 0x       0)
Reading register (s22 = 0x       0)
Reading register (s23 = 0x       0)
Reading register (s24 = 0x       0)
Reading register (s25 = 0x       0)
Reading register (s26 = 0x       0)
Reading register (s27 = 0x       0)
Reading register (s28 = 0x       0)
Reading register (s29 = 0x       0)
Reading register (s30 = 0x       0)
Reading register (s31 = 0x       0)
Reading register (d0 = 0x       0)
Reading register (d1 = 0x       0)
Reading register (d2 = 0x       0)
Reading register (d3 = 0x       0)
Reading register (d4 = 0x       0)
Reading register (d5 = 0x       0)
Reading register (d6 = 0x       0)
Reading register (d7 = 0x       0)
Reading register (d8 = 0x       0)
Reading register (d9 = 0x       0)
Reading register (d10 = 0x       0)
Reading register (d11 = 0x       0)
Reading register (d12 = 0x       0)
Reading register (d13 = 0x       0)
Reading register (d14 = 0x       0)
Reading register (d15 = 0x       0)
Reading 64 bytes @ address 0x00101140
Read 4 bytes @ address 0x080B1A08 (Data = 0xBF00BD38)
Reading 64 bytes @ address 0x080B19C0
Read 4 bytes @ address 0x080B1A0E (Data = 0xB570001A)
Reading 64 bytes @ address 0x00101180
GDB closed TCP/IP connection (Socket 964)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

Simon Marchi <simark at simark dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simark at simark dot ca

--- Comment #1 from Simon Marchi <simark at simark dot ca> ---
Hi,

Would you be able to share the program you are debugging, or some other
reproducer?

Simon

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[vsfos at foxmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

--- Comment #2 from SimonQian <vsfos at foxmail dot com> ---
Yes, the software is at https://github.com/vsfteam/vsf.
vscode workspace is at
https://github.com/vsfteam/vsf/tree/master/example/template/project/cmake/aic8800.

But it contains a sdk from chip vendor, I need to ask the vendor if I can
provide the sdk. I will reply soon.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[vsfos at foxmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

--- Comment #3 from SimonQian <vsfos at foxmail dot com> ---
I will try to implement a qemu with some other Cortex M4 chips and try to
reproduct the issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[vsfos at foxmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

--- Comment #4 from SimonQian <vsfos at foxmail dot com> ---
(In reply to Simon Marchi from comment #1)
> Hi,
> 
> Would you be able to share the program you are debugging, or some other
> reproducer?
> 
> Simon

I prepared a qemu to reproduce the problem, which use mps2 as target device.
The vscode workspace is at:
https://github.com/vsfteam/vsf/tree/master/example/template/project/cmake/mps2


the gdb output log:
Please check OUTPUT tab (Adapter Output) for output from qemu-system-arm
Launching server: "qemu-system-arm" "-cpu" "cortex-m7" "-machine" "mps2-an500"
"-nographic" "-semihosting-config" "enable=on,target=native" "-gdb"
"tcp::50000" "-S" "-kernel"
"Z:\vsf\example\template\project\cmake\mps2\build\vsf_template.elf"
Launching GDB: "arm-none-eabi-gdb.exe" "-q" "--interpreter=mi2"
Reading symbols from
Z:\vsf\example\template\project\cmake\mps2\build\vsf_template.elf...
Reset_Handler () at
Z:/vsf/source/hal/driver/arm/mps2/CMSDK_CM7/startup_ARMCM7.c:191
191     {
Not implemented stop reason (assuming exception): undefined
/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/src/gdb/gdb/gdbtypes.c:931:
internal-error: type* create_range_type(type*, type*, const dynamic_prop*,
const dynamic_prop*, LONGEST): Assertion `TYPE_LENGTH (index_type) > 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Quit this debugging session? 
(y or n) [answered Y; input not from terminal]

This is a bug, please report it.
  For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.

/mnt/workspace/workspace/GCC-10-pipeline/jenkins-GCC-10-pipeline-48_20201124_1606180641/src/gdb/gdb/gdbtypes.c:931:
internal-error: type* create_range_type(type*, type*, const dynamic_prop*,
const dynamic_prop*, LONGEST): Assertion `TYPE_LENGTH (index_type) > 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Create a core file of GDB? 
(y or n) [answered Y; input not from terminal]



And it seems to relate to some compiler options. I will do more test.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[vsfos at foxmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

--- Comment #5 from SimonQian <vsfos at foxmail dot com> ---
If the binary is build manually using cmake -GNinja .. %% ninja, the gdb works
fine. If the binary is build by vscode(using cmake tool), gdb will fail with
the assertion. I will check the dedicated option which make it fail.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[vsfos at foxmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

--- Comment #6 from SimonQian <vsfos at foxmail dot com> ---
I get the option which make it fail, it's -gstabs+.
And it's not a bug in gdb as displayed in gdb output.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[simark at simark dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

--- Comment #7 from Simon Marchi <simark at simark dot ca> ---
(In reply to SimonQian from comment #6)
> I get the option which make it fail, it's -gstabs+.
> And it's not a bug in gdb as displayed in gdb output.

It's technically a bug in GDB, since you hit an internal error (the
"internal-error: ..." message).

However, if the problem is due to using the stabs debug info format, I don't
think it's worth digging that much: the stabs format is pretty much a relic of
the past, you should really use DWARF.  Of course, if somebody volunteers to
fix the bug, I'm not against it, but I won't.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[kadler at us dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

Kevin Adler <kadler at us dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kadler at us dot ibm.com

--- Comment #8 from Kevin Adler <kadler at us dot ibm.com> ---
I'm also hitting this error on AIX. While DWARF is supported, the default
format is XCOFF (which I think is a variant of stabs) even with GCC. I'll try
to look in to fixing it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[kadler at us dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

--- Comment #9 from Kevin Adler <kadler at us dot ibm.com> ---
What I've found so far while debugging against emacs 27.2 on AIX, which builds
with -g3:

emacs.c has many include files, one of which is lisp.h which defines struct
Lisp_Subr:


Lisp_Subr:T714=s48header:691,0,64;function:715=u8a0:716=*717=f671,0,64;a1:718=*719=f671,0,64;a2:720=*721=f671,0,64;
a3:722=*723=f671,0,64;a4:724=*725=f671,0,64;a5:726=*727=f671,0,64;a6:728=*729=f671,0,64;a7:730=*731=f671,0,64;a8:732=*733=f671,0,64;aUNEVALLED:718,0,64;aMANY:734=*735=f671,0,64;;,64,64;min_
args:-3,128,16;max_args:-3,144,16;symbol_name:736=*737=k-2,192,64;intspec:736,256,64;doc:659,320,64;;

This struct contains the field symbol_name, which is a const char* and so type
736 is defined for it (736 is a pointer type of 737, which is a constant
version of builtin RS/600 type -2, which is char)

Later in emacs.c, usage_message is declared as static char const *const
usage_message[]. The following stabstring is defined for it by GCC:

usage_message:S1353=ar114;0;00000000000000000000014;1354=k736

We have then a global static (S) type 1353 which is an array (type 114) with
range 0-12 (14 octal) and the type of the array (1354) is a constant (k)
version of 736 (ie. const char*).

So this all seems fine, but when we try to look up the index type (736) in
dbx_alloc_type, it's not found and so a new type is allocated by calling
alloc_type, initialized to TYPE_CODE_UNDEF. This type is then passed to
create_range_type, causing the assertion to fail.

The question is: why is the 736 reference type not found? It seems that in this
case, there are 3 CSECTs for emacs.c and only the one containing main is
analyzed when the failure occurs so the 736 type hasn't been allocated.

>From the tracing I've done, scan_xcoff_symtab does read through all the CSECTs,
though it seems there's maybe a bug processing the first CSECT. Even after
making some changes to call xcoff_start_psymtab for this first CSECT (which
contains 736) read_xcoff_symtab is never called for this pst. I thought
possibly they were getting read in reverse order and so the assertion is hit
before it gets to reading the pst, but no even after disabling the assertion I
can see from my trace file that the pst containing type 736 is passed to
read_xcoff_symtab at all.

There is this comment in xcoffread.c that might hint at the problem here:

              /* A program csect is seen.  We have to allocate one
             symbol table for each program csect.  Normally gdb
             prefers one symtab for each source file.  In case
             of AIX, one source file might include more than one
             [PR] csect, and they don't have to be adjacent in
             terms of the space they occupy in memory.  Thus, one
             single source file might get fragmented in the
             memory and gdb's file start and end address
             approach does not work!  GCC (and I think xlc) seem
             to put all the code in the unnamed program csect.  */

But this comment is in read_xcoff_symtab, which we're not getting to anyway.

At this point, I'm still trying to figure out how we got in to this function.
>From there I could backtrack and figure out why it's not getting called for the
other symtab containing the definition. From what I can tell, possibly the only
caller of read_symtab is psymtab_to_symtab and the only caller of
expand_psymtab is expand_dependencies.

Side note: while looking at the latter, I noticed that scan_xcoff_symtab
allocates an array of up to 30 dependent psymtabs, but dependencies_used is
only ever set to 0 so psymtabs never have any dependents. I'm not sure if it's
a bug or some vestigial code due to refactoring. The code is like this going
back to c906108, which seems to be when the file was added to the repo, but I'm
not sure how the history was imported to git if some of that earlier history
was lost.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[kadler at us dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

--- Comment #10 from Kevin Adler <kadler at us dot ibm.com> ---
So it looks like GDB locates the specific psymtab that contains the symbol
being looked up and calls read_symtab() on it. This invokes xcoff_read_symtab
through the legacy_psymtab implementation. This then calls expand_psymtab,
which ends up invoking xcoff_expand_psymtab. This then calls
expand_dependencies (but there are never dependencies, based on my last
comment) and finally calls read_xcoff_symtab on the psymtab. So yeah, only the
psymtab containing the symbol will be loaded and if it depends on types defined
in other psymtabs it will blow up.

I modified the code to add dependencies on the prior psymtabs created for the
same file (only works if the csects are adjacent/contiguous, which comments
seem to indicate may not always be the case, but it's works for my testing).
The first csect for a file would have no dependencies, then the second would
depend on the first, the third depend on the second, and so on... I'm not sure
if this is what the dependencies are supposed to be fore, but it let me do some
testing. This still doesn't work because at the start of read_xcoff_symtab
(called for each dependency), start_stabs is called which sets type_vector to
NULL so all the types defined by the previous csect for the file are lost. :(

Seems like the stabs/xcoff code would need a large rewrite in order to make
this all work correctly since type_vector is a global variable and not
associated with a source file/psymtab/etc. And if the comments are true about
csects for the same file being fragmented, it makes it even more complicated
since you'd basically need a way to look up all the psymtabs associated with a
given filename. I do see that the psymtabs are all given the same name (the
filename), though I'm not sure how much them having the same name actually
helps.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[simon.marchi at polymtl dot ca]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

Simon Marchi <simon.marchi at polymtl dot ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |simon.marchi at polymtl dot ca

--- Comment #11 from Simon Marchi <simon.marchi at polymtl dot ca> ---
(In reply to Kevin Adler from comment #10)
> So it looks like GDB locates the specific psymtab that contains the symbol
> being looked up and calls read_symtab() on it. This invokes
> xcoff_read_symtab through the legacy_psymtab implementation. This then calls
> expand_psymtab, which ends up invoking xcoff_expand_psymtab. This then calls
> expand_dependencies (but there are never dependencies, based on my last
> comment) and finally calls read_xcoff_symtab on the psymtab. So yeah, only
> the psymtab containing the symbol will be loaded and if it depends on types
> defined in other psymtabs it will blow up.
> 
> I modified the code to add dependencies on the prior psymtabs created for
> the same file (only works if the csects are adjacent/contiguous, which
> comments seem to indicate may not always be the case, but it's works for my
> testing). The first csect for a file would have no dependencies, then the
> second would depend on the first, the third depend on the second, and so
> on... I'm not sure if this is what the dependencies are supposed to be fore,
> but it let me do some testing. This still doesn't work because at the start
> of read_xcoff_symtab (called for each dependency), start_stabs is called
> which sets type_vector to NULL so all the types defined by the previous
> csect for the file are lost. :(
> 
> Seems like the stabs/xcoff code would need a large rewrite in order to make
> this all work correctly since type_vector is a global variable and not
> associated with a source file/psymtab/etc.

I don't understand everything here, but it sounds like you need the type vector
of a previously built symtab to be accessible while reading a second symtab
that depends on the first one?

DWARF keeps some data associated to each compunit_symtab on the side, in the
dwarf2_per_objfile::m_symtabs field.  It sounds like you would need something
like that.  When symtab 2 depends on a type in symtab 1, then you could lookup
symtab 1's type vector in that per-compunit_symtab data.  Or maybe I completely
misunderstand the problem.

> And if the comments are true
> about csects for the same file being fragmented, it makes it even more
> complicated since you'd basically need a way to look up all the psymtabs
> associated with a given filename. I do see that the psymtabs are all given
> the same name (the filename), though I'm not sure how much them having the
> same name actually helps.

I don't know about that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type

[kadler at us dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28018

--- Comment #12 from Kevin Adler <kadler at us dot ibm.com> ---
> DWARF keeps some data associated to each compunit_symtab on the side, in the
> dwarf2_per_objfile::m_symtabs field.  It sounds like you would need something 
> like that.  When symtab 2 depends on a type in symtab 1, then you could lookup 
> symtab 1's type vector in that per-compunit_symtab data.  Or maybe I completely > misunderstand the problem.

Yeah, I think something like this will be necessary. I actually found a patches
the AIX team has in their build of GDB 8.1 that does something like this. That
was to address issues when using --function-sections/-qfuncsect, which makes
this problem worse by putting every function in to its own csect.

BTW, I actually confused myself initially. While we _are_ failing to look up
the element type of the array, the assertion is not on that type, but on the
type used to index the array. I didn't even realize that could or needed be
specified.  :) One hack around the assertion problem would be to check if we
got an undefined type when looking up the index type and in that case override
the type using the builtin type for unsigned long. Of course, that wouldn't fix
the larger issue and so the element type of the array would still be undefined.

-- 
You are receiving this mail because:
You are on the CC list for the bug.