* [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type
2021-06-27 11:00 [Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type vsfos at foxmail dot com
@ 2021-06-27 11:03 ` simark at simark dot ca
2021-06-27 11:13 ` vsfos at foxmail dot com
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: simark at simark dot ca @ 2021-06-27 11:03 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type
2021-06-27 11:00 [Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type vsfos at foxmail dot com
2021-06-27 11:03 ` [Bug breakpoints/28018] " simark at simark dot ca
@ 2021-06-27 11:13 ` vsfos at foxmail dot com
2021-06-27 23:57 ` vsfos at foxmail dot com
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: vsfos at foxmail dot com @ 2021-06-27 11:13 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type
2021-06-27 11:00 [Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type vsfos at foxmail dot com
2021-06-27 11:03 ` [Bug breakpoints/28018] " simark at simark dot ca
2021-06-27 11:13 ` vsfos at foxmail dot com
@ 2021-06-27 23:57 ` vsfos at foxmail dot com
2021-06-30 7:17 ` vsfos at foxmail dot com
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: vsfos at foxmail dot com @ 2021-06-27 23:57 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type
2021-06-27 11:00 [Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type vsfos at foxmail dot com
` (2 preceding siblings ...)
2021-06-27 23:57 ` vsfos at foxmail dot com
@ 2021-06-30 7:17 ` vsfos at foxmail dot com
2021-06-30 8:14 ` vsfos at foxmail dot com
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: vsfos at foxmail dot com @ 2021-06-30 7:17 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type
2021-06-27 11:00 [Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type vsfos at foxmail dot com
` (3 preceding siblings ...)
2021-06-30 7:17 ` vsfos at foxmail dot com
@ 2021-06-30 8:14 ` vsfos at foxmail dot com
2021-06-30 11:28 ` vsfos at foxmail dot com
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: vsfos at foxmail dot com @ 2021-06-30 8:14 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type
2021-06-27 11:00 [Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type vsfos at foxmail dot com
` (4 preceding siblings ...)
2021-06-30 8:14 ` vsfos at foxmail dot com
@ 2021-06-30 11:28 ` vsfos at foxmail dot com
2021-06-30 12:41 ` simark at simark dot ca
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: vsfos at foxmail dot com @ 2021-06-30 11:28 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type
2021-06-27 11:00 [Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type vsfos at foxmail dot com
` (5 preceding siblings ...)
2021-06-30 11:28 ` vsfos at foxmail dot com
@ 2021-06-30 12:41 ` simark at simark dot ca
2021-10-19 2:01 ` kadler at us dot ibm.com
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: simark at simark dot ca @ 2021-06-30 12:41 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type
2021-06-27 11:00 [Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type vsfos at foxmail dot com
` (6 preceding siblings ...)
2021-06-30 12:41 ` simark at simark dot ca
@ 2021-10-19 2:01 ` kadler at us dot ibm.com
2021-10-25 18:05 ` kadler at us dot ibm.com
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: kadler at us dot ibm.com @ 2021-10-19 2:01 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type
2021-06-27 11:00 [Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type vsfos at foxmail dot com
` (7 preceding siblings ...)
2021-10-19 2:01 ` kadler at us dot ibm.com
@ 2021-10-25 18:05 ` kadler at us dot ibm.com
2021-10-28 19:10 ` kadler at us dot ibm.com
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: kadler at us dot ibm.com @ 2021-10-25 18:05 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type
2021-06-27 11:00 [Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type vsfos at foxmail dot com
` (8 preceding siblings ...)
2021-10-25 18:05 ` kadler at us dot ibm.com
@ 2021-10-28 19:10 ` kadler at us dot ibm.com
2021-10-28 19:41 ` simon.marchi at polymtl dot ca
2021-10-28 21:16 ` kadler at us dot ibm.com
11 siblings, 0 replies; 13+ messages in thread
From: kadler at us dot ibm.com @ 2021-10-28 19:10 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type
2021-06-27 11:00 [Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type vsfos at foxmail dot com
` (9 preceding siblings ...)
2021-10-28 19:10 ` kadler at us dot ibm.com
@ 2021-10-28 19:41 ` simon.marchi at polymtl dot ca
2021-10-28 21:16 ` kadler at us dot ibm.com
11 siblings, 0 replies; 13+ messages in thread
From: simon.marchi at polymtl dot ca @ 2021-10-28 19:41 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread* [Bug breakpoints/28018] internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type
2021-06-27 11:00 [Bug breakpoints/28018] New: internal-error: Assertion 'TYPE_LENGTH(index_type) > 0' failed in create_range_type vsfos at foxmail dot com
` (10 preceding siblings ...)
2021-10-28 19:41 ` simon.marchi at polymtl dot ca
@ 2021-10-28 21:16 ` kadler at us dot ibm.com
11 siblings, 0 replies; 13+ messages in thread
From: kadler at us dot ibm.com @ 2021-10-28 21:16 UTC (permalink / raw)
To: gdb-prs
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.
^ permalink raw reply [flat|nested] 13+ messages in thread