Bug 27962 - Internal error when using binary from gdb.dwarf2/arr-stride.exp
Summary: Internal error when using binary from gdb.dwarf2/arr-stride.exp
Status: NEW
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-07 19:35 UTC by Simon Marchi
Modified: 2021-06-08 23:07 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Marchi 2021-06-07 19:35:54 UTC
I stumbled on this a bit randomly while trying to reproduce a failure.  With the binary from gdb.dwarf2/arr-stride.exp, with current master:

$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.dwarf2/arr-stride/arr-stride  -ex "print the_struct"
Reading symbols from testsuite/outputs/gdb.dwarf2/arr-stride/arr-stride...
$1 = {intfield = 1, arrayfield = {
/home/simark/src/binutils-gdb/gdb/value.c:851: internal-error: bool value_contents_bits_eq(const value*, int, const value*, int, int): Assertion `offset2 + length <= TYPE_LENGTH (val2->enclosing_type) * TARGET_CHAR_BIT' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) 



(top-gdb) p offset2
$1 = 32
(top-gdb) p length
$2 = 32
(top-gdb) p TYPE_LENGTH (val2->enclosing_type)
$3 = 4
(top-gdb) p TARGET_CHAR_BIT
$4 = 8
Comment 1 Simon Marchi 2021-06-07 19:38:04 UTC
If I use `-ex "set language ada"` before the print, as the test does, I don't hit an internal error.
Comment 2 Tom Tromey 2021-06-07 20:37:29 UTC
At first I thought this was because we're trying to print
an optimized-out array.  And, that still seems weird, maybe
common_val_print and common_val_print_checked should be merged

However, it's also the case that this array has a bit stride of 6.
So, this may just be a missing feature in value_print_array_elements.

I'm not sure how important this is.  Arrays like this can't be
created in most languages that gdb supports.  OTOH, it should be
safe to print a value, regardless of the current language.
Comment 3 Simon Marchi 2021-06-08 21:33:25 UTC
I don't have enough context nor time to dig into it.  But yeah, any way to trigger an internal error can be considered a bug.  So if there's just no sane way of printing the value for languages other than Ada, then at least erroring out would be better than an internal error.

But why is it needed to set the language explicitly, given that the CU provides:

  DW_AT_language @DW_LANG_Ada95

?
Comment 4 Tom Tromey 2021-06-08 23:07:05 UTC
(In reply to Simon Marchi from comment #3)

> But why is it needed to set the language explicitly, given that the CU
> provides:
> 
>   DW_AT_language @DW_LANG_Ada95
> 
> ?

The program's "main" isn't given a language.