On aarch64-linux (debian testing) with test-case
gdb.base/empty-host-env-vars.exp I ran into:
...
(gdb) show index-cache directory^M
The directory of the index cache is "/home/linux/.cache/gdb".^M
(gdb) FAIL: $exp: env_var_name=HOME: show index-cache directory
...
Without changing any environment variables, the value of the index-cache dir
is:
...
$ gdb -q -batch -ex "show index-cache directory"
The directory of the index cache is "/home/linux/.cache/gdb".
...
and the expectation of the test-case is that setting HOME to empty will
produce an empty dir, but what it actually produces is:
...
$ HOME= gdb -q -batch -ex "show index-cache directory"
The directory of the index cache is "/home/linux/.cache/gdb".
...
There's nothing wrong with that behaviour, the dir is simply constructed using
XDG_CACHE_HOME which happens to be explictly set to its default value
$HOME/.cache [1]:
...
$ echo $XDG_CACHE_HOME
/home/linux/.cache
...
and indeed also setting that variable to empty gets us the expected empty dir:
...
$ XDG_CACHE_HOME= HOME= gdb -q -batch -ex "show index-cache directory"
gdb: warning: Couldn't determine a path for the index cache directory.
The directory of the index cache is "".
...
Furthermore, the test-case assumption that setting variables to empty either
produces the original dir or an empty dir is incorrect.
Say that XDG_CACHE_HOME has a non-default value:
...
$ echo $XDG_CACHE_HOME
/home/linux/my-xdg-cache-home
$ gdb -q -batch -ex "show index-cache directory"
The directory of the index cache is "/home/linux/my-xdg-cache-home/gdb".
...
then setting that variable to empty:
...
$ XDG_CACHE_HOME= gdb -q -batch -ex "show index-cache directory"
The directory of the index cache is "/home/linux/.cache/gdb".
...
does change the value of the dir.
Fix this by making the test-case less specific.
While we're at it, factor out regexps re_pre and re_post to make regexps more
readable, and use string_to_regexp to reduce quoting.
Tested on aarch64-linux.
PR testsuite/32132
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32132
[1] https://specifications.freedesktop.org/basedir-spec/latest/index.html#variables
With test-case gdb.base/attach-deleted-exec.exp I ran into:
...
(gdb) attach 121552^M
Attaching to process 121552^M
Reading symbols .../attach-deleted-exec/.nfs00000000044ff2ef00000086...^M
Reading symbols from /lib64/libm.so.6...^M
(No debugging symbols found in /lib64/libm.so.6)^M
Reading symbols from /lib64/libc.so.6...^M
(No debugging symbols found in /lib64/libc.so.6)^M
Reading symbols from /lib64/ld64.so.2...^M
(No debugging symbols found in /lib64/ld64.so.2)^M
0x00007fff947cc838 in clock_nanosleep@@GLIBC_2.17 () from /lib64/libc.so.6^M
(gdb) FAIL: $exp: attach to process with deleted executable
....
The .nfs file indicates:
- that the file has been removed on the NFS server, and
- that the file is still open on the NFS client.
Fix this by detecting this situation, and declaring the test for filename
/proc/PID/exe unsupported.
Tested on:
- x86_64-linux (setup without NFS)
- ppc64le-linux (setup with NFS)
PR testsuite/32130
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32130
On aarch64-linux, with test-case gdb.mi/mi-multi-commands.exp once in a while
I run into (edited for readability):
...
(gdb) ^M
<LOTS-OF-SPACES>-data-evaluate-expression $a^M
-data-evaluate-^done,value="\"FIRST COMMAND\""^M
expression $b(gdb) ^M
^M
^done,value="\"TEST COMPLETE\""^M
(gdb) ^M
PASS: $exp: args=: look for first command output, command length 236
FAIL: $exp: args=: look for second command output, command length 236 (timeout)
...
This is more likely to trigger when running the test-case using
taskset -c <cpu> (where in a big.little setup we pick a little cpu).
The setup here is that the test-case issues these two commands at once:
...
-data-evaluate-expression $a
-data-evaluate-expression $b
...
where the length of the first command is artificially increased by prefixing
it with spaces, show as <LOTS-OF-SPACES> above.
What happens is that gdb, after parsing the first command, executes it.
Then the output of the first command intermixes with the echoing of the second
command, which produces this line containing the first prompt:
...
expression $b(gdb) ^M
...
which doesn't match the \r\n prefix of the regexp supposed to consume the
first prompt:
...
-re "\r\n$mi_gdb_prompt" {
...
Fix this by dropping the \r\n prefix.
Tested on aarch64-linux.
PR testsuite/29781
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29781
commit 292676c15a
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Thu Feb 13 13:44:17 2020 -0800
x86: Resolve PLT32 reloc aganst local symbol to section
resolved PLT32 relocation against local symbol to section and
commit 2585b7a5ce
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Sun Jul 19 06:51:19 2020 -0700
x86: Change PLT32 reloc against section to PC32
turned PLT32 relocation against section into PC32 relocation. But these
transformations are valid only for PC-relative relocations. Add fx_pcrel
check for PC-relative relocations when performing these transformations
to keep PLT32 relocation in `movq $foo@PLT, %rax`.
gas/
PR gas/32196
* config/tc-i386.c (tc_i386_fix_adjustable): Return fixP->fx_pcrel
for PLT32 relocations.
(i386_validate_fix): Turn PLT32 relocation into PC32 relocation
only if fixp->fx_pcrel is set.
* testsuite/gas/i386/reloc32.d: Updated.
* testsuite/gas/i386/reloc64.d: Likewise.
* testsuite/gas/i386/reloc32.s: Add PR gas/32196 test.
* testsuite/gas/i386/reloc64.s: Likewise.
ld/
PR gas/32196
* testsuite/ld-x86-64/plt3.s: New file.
* testsuite/ld-x86-64/x86-64.exp: Run plt3.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Test-case gdb.ada/call_pn.exp contains an unconditional xfail, which is only
necessary for gcc 8 and 9.
Fix this by limiting the xfail to those releases.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
With test-case gdb.ada/call_pn.exp and glibc debug info installed, I ran into
this timeout:
...
(gdb) maint expand-symtabs^M
FAIL: gdb.ada/call_pn.exp: maint expand-symtabs (timeout)
...
The timeout was related to running the cpu at base frequency of 400Mhz instead
of boost frequency of 3.5Ghz (efficiency core) or 4.7Ghz (performance core).
But when investigating the test-case I realized that the maint expand-symtabs
could be limited to the source files, so use that to speed up the test-case.
Tested on x86_64-linux.
Co-Authored-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/32177
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32177
When running the testsuite in an enviroment simulating a stressed system, I
ran into timeouts in three test-cases in gdb.dwarf2:
- gdb.dwarf2/count.exp,
- gdb.dwarf2/implptrconst.exp, and
- gdb.dwarf2/implptrpiece.exp.
In all three cases, -readnow is used which results in symtabs being expanded for
the executable, /lib64/libc.so.6 and /lib64/ld-linux-x86-64.so.2.
We could address this by limiting the scope of -readnow to the executable, but
after reviewing the test-cases there doesn't seem to be a clear reason to use
-readnow.
Fix this by dropping the -readnow.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Assembler shouldn't accept invalid TLS instructions, TLS relocations
can only be used with specific instructions as specified in TLS psABI
and linker issues an error when TLS relocations are used with wrong
instructions or format. Since it is inconvenient for gcc to rely on
linker to report errors, adding TLS check in the assembler stage so
that gcc can know TLS errors earlier.
gas/ChangeLog:
PR gas/32022
* config.in: Regenerate.
* config/tc-i386.c
*(enum x86_tls_error_type): New.
*(struct _i386_insn): Added has_gotrel to indicate whether TLS
relocations need to be checked.
(x86_check_tls_relocation): Added a new function to check TLS
relocation.
(x86_report_tls_error): Created a new function to report TLS error.
(i386_assemble): Handle x86_check_tls_relocation.
(lex_got): Set i.has_gotrel.
(OPTION_MTLS_CHECK): Added a new option to contrl TLS check.
(struct option): Ditto.
(md_parse_option): Ditto.
(md_show_usage): Ditto.
* configure.ac: Added a new option to check TLS relocation by
default.
* configure: Regenerated.
* doc/c-i386.texi: Document -mtls-check=.
* testsuite/gas/i386/i386.exp: Added new tests.
* testsuite/gas/i386/ilp32/ilp32.exp: Ditto.
* testsuite/gas/i386/ilp32/reloc64.d: Disable TLS check for it.
* testsuite/gas/i386/ilp32/x32-tls.d: Ditto.
* testsuite/gas/i386/inval-tls.l: Added more test cases.
* testsuite/gas/i386/inval-tls.s: Ditto.
* testsuite/gas/i386/reloc32.d: Disable TLS check for it.
* testsuite/gas/i386/reloc64.d: Ditto.
* testsuite/gas/i386/x86-64-inval-tls.l: Added more test cases.
* testsuite/gas/i386/x86-64-inval-tls.s: Ditto.
* testsuite/gas/i386/x86-64.exp: Added new tests.
* testsuite/gas/i386/ilp32/x32-inval-tls.l: New test.
* testsuite/gas/i386/ilp32/x32-inval-tls.s: Ditto.
* testsuite/gas/i386/ilp32/x86-64-tls.d: Ditto.
* testsuite/gas/i386/tls.d: Ditto.
* testsuite/gas/i386/tls.s: Ditto.
* testsuite/gas/i386/x86-64-tls.d: Ditto.
* testsuite/gas/i386/x86-64-tls.s: Ditto.
ld/ChangeLog:
PR gas/32022
* testsuite/ld-i386/tlsgdesc1.d: Disable TLS check for it.
* testsuite/ld-i386/tlsgdesc2.d: Ditto.
* testsuite/ld-i386/tlsie2.d: Ditto.
* testsuite/ld-i386/tlsie3.d: Ditto.
* testsuite/ld-i386/tlsie4.d: Ditto.
* testsuite/ld-i386/tlsie5.d: Ditto.
* testsuite/ld-i386/tlsgdesc3.d: Ditto.
* testsuite/ld-x86-64/tlsdesc3.d: Ditto.
* testsuite/ld-x86-64/tlsdesc4.d: Ditto.
* testsuite/ld-x86-64/tlsie2.d: Ditto.
* testsuite/ld-x86-64/tlsie3.d: Ditto.
* testsuite/ld-x86-64/tlsie5.d: Ditto.
* testsuite/ld-x86-64/tlsdesc5.d: Ditto.
The commit
bf6d7087de ld: Move the .note.build-id section to near the start of the memory map
moves the .note.build-id section before text sections. When --rosegment
and -z separate-code are used together, the .note.gnu.property section
is placed between the .note.build-id section and text sections in the
same PT_LOAD segment by orphan placement. Pass --no-rosegment to ld for
PR ld/22393 tests to avoid linker test failures.
PR ld/32190
* testsuite/ld-elf/pr22393-2a.rd: Pass --no-rosegment to ld.
* testsuite/ld-elf/pr22393-2b.rd: Likewise.
* testsuite/ld-elf/shared.exp: Pass --no-rosegment to ld when
building pr22393-2 tests.
* testsuite/ld-x86-64/pr22393-3a.rd: Pass --no-rosegment to ld.
* testsuite/ld-x86-64/pr22393-3b.rd: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Pass --no-rosegment to ld when
building pr22393-3 tests.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
With the previous commits, the only thing entangling elf and coff file
reading with dbx file reading is the functions
{elf|coff}stab_build_psymtabs, defined in dbxread.c. These functions
depend on dbx_symfile_read.
To solve this, I renamed read_stabs_symtab to read_stabs_symtab_1, and
created a function with the original name that does what
dbx_symfile_read used to do.
This way, dbx_symfile_read can just call read_stabs_symtab, and the elf
and coff psymtab builders can also call it directly, fully disentangling
the readers, which would allow us to selectively not compile dbxread in
the future.
Approved-By: Tom Tromey <tom@tromey.com>
Despite the name, read_dbx_symtab is not only used for the dbx file
format (also called the aout format). It is used by elf and coff
implicitly as well. So I think it makes more sense to have this function
in the generic stabsread file, so that reading elf files or coff files
depends less on GDB's ability to read dbx files.
There were 11 static functions in dbxread that were onlyl helper
functions, they were moved and kept as static in stabsread.c. Notably,
dbx_read_symtab - which is installed as a callback on legacy_psymtab
for aout, elf and coff at least - has been moved to stabsread.c and
renamed as well; the function that is specific to aout is
dbx_symfile_read, and that hasn't been moved.
Some macros had to be moved as well, but since they are still used
in dbxread, they were moved to the .h file that the struct symloc
is declared, so anyone can properly use the struct.
Approved-By: Tom Tromey <tom@tromey.com>
This function is used by multiple stabs readers (even if not all), and
the comment in stabsread.h even acknowledges it. I believe that the
comment is incorrect in saying that the function should be in dbxread
because not everyone uses it. If any one reader other than dbx uses
it, the function should be in stabsread, in my opinion.
This commit makes also renames the function to stabs_end_psymtab since,
again, this is not specific to dbx/aout format.
struct symloc had to be moved because stabs_end_psymtab dereferences
symloc objects, so stabsread.c must be aware of the full struct.
Approved-By: Tom Tromey <tom@tromey.com>
The function process_one_symbol was defined in the file dbxread.c, but
this function is used by all file formats that handle stabs debug
information. It makes much more sense for it to be in the stabsread.c
file instead.
To move that function, many other static functions had to be moved from
dbxread. A few were only used by process_one_symbol, so they're still
static, but most were used by other functions still in dbxread, so they
are being exported by stabsread.h
Finally, the registry entry has been moved as well, seeing as it was
already exported by gdb-stabs.h, and stabsread.c will need it to
properly use the newly added function.
With this change, reading mdebug files is totally independent of reading
dbx.
Approved-By: Tom Tromey <tom@tromey.com>
The file dbxread.c, which is responsible for reading stabs information
for multiple file formats, relies heavily on setting and using global
variables over the course of reading symbols.
Future patches aim to make stabs reading more file format independent,
and this patch starts that change by introducing a stabs_context struct,
that will hold all the relevant variables. This context struct is saved
on the registry key inside the objfile being read. Some of those global
variables have been deemed irrelevant:
* dbxread_objfile - Since we're saving in an objfile, this is redundant
* symfile_bfd - It is trivial to get the bfd pointer from the objfile,
so also unnecessary
* string_table_offset - was never initialized, just used to set a value.
That usage was substituted by a hardcoded 0
* next_file_string_table_offset - was only used by read_dbx_symtab, so
it was turned into a local variable there.
As I was moving variables, I also couldn't think of a good reason for
the bincl_list to be a pointer, so it was changed to just be an
std::vector.
Approved-By: Tom Tromey <tom@tromey.com>
The test gdb.base/bp-cond-failure is implicitly expecting that the
function foo will be inlined twice and gdb will be able to find 2
locations to place a breakpoint. When clang is used, gdb only finds
one location which causes the test to fail. Since the test is not
worried about handling breakpoints on inlined functions, but rather on
the format of the message on a breakpoint condition fail, this seems
like a false fail report.
This commit reworks the test to be in c++, and uses function overloading
to ensure that 2 locations will always be found. Empirical testing
showed that, for clang, we will land on location 2 with the currest exp
commands, no matter the order of the functions declared, whereas for gcc
it depends on the order that functions were declared, so they are
ordered to always land on the second location, this way we are able to
hardcode it and check for it.
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
There is no such linker command-line option, -z one-rosegment. Replace
it with --rosegment in comments.
* genscripts.sh: Change -z one-rosegment to --rosegment in
comments.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Disable PIE on PR gas/32189 test, which contains the non-PIE assembly
source, to support GCC defaulted to PIE.
PR gas/32189
* testsuite/ld-x86-64/x86-64.exp: Pass $NOPIE_LDFLAGS to linker
on PR gas/32189 test.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
R_X86_64_GOT64 relocation should never be made section relative. Change
tc_i386_fix_adjustable to return 0 for BFD_RELOC_X86_64_GOT64.
gas/
PR gas/32189
* config/tc-i386.c (tc_i386_fix_adjustable): Return 0 for
BFD_RELOC_X86_64_GOT64.
* testsuite/gas/i386/reloc64.d: Updated.
* testsuite/gas/i386/reloc64.s: Add more tests for R_X86_64_GOT64
and R_X86_64_GOTOFF64.
ld/
PR gas/32189
* testsuite/ld-x86-64/x86-64.exp: Run PR gas/32189 test.
* testsuite/ld-x86-64/pr32189.s: New file.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
This helps GDB to locate the debug information associated with a core dump.
Core dumps include the first page of an executable's image, and if this
page include the .note.build-id section then GDB can find it and then track
down a debug info file for that build-id.
Fixed UBSAN runtime errors such as:
- member call on address which does not point to an object of type 'Vector'
- load of misaligned address 0x623e5a670173 for type 'int', which requires 4 byte alignment
gprofng/ChangeLog
2024-09-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
PR gprofng/32096
* libcollector/unwind.c: Fix UBSAN runtime errors.
* src/CallStack.cc (add_stack_java, add_stack_java_epilogue):
Change argument type to Vector<Histable*>*.
* src/Experiment.cc (update_ts_in_maps): Change variable type.
* src/Experiment.h: Change field type to Vector<Histable*>*.
V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} aren't promoted
to support EGPR in APX spec. Don't promote them out of APX spec. This
commit effectively reverted:
ec3babb8c1 x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed
5a635f1f59 x86/APX: VROUND{P,S}{S,D} encodings require AVX512{F,VL}
eea4357967 x86/APX: VROUND{P,S}{S,D} can generally be encoded
gas/
PR gas/32171
* testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: Add
V{BROADCAST,EXTRACT,INSERT}{F,I}128 tests with EGPR.
* testsuite/gas/i386/x86-64-apx-evex-promoted.s: Remove
V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} tests
with EGPR.
* testsuite/gas/i386/x86-64-apx-egpr-inval.l: Updated.
* testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: Likewise.
* testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Likewise.
* testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Likewise.
* testsuite/gas/i386/x86-64-apx-evex-promoted.d: Likewise.
opcodes/
PR gas/32171
* i386-opc.tbl: Remove V{BROADCAST,EXTRACT,INSERT}{F,I}128 and
VROUND{P,S}{S,D} entries with EGPR.
* i386-tbl.h: Regenerated.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
The test gdb.mi/dw2-ref-missing-frame.exp uses the old-school way to set
debug information by hand, using a .S file and assembly labels to get
addresses. Unfortunately, clang will always re-arrange the global labels
to be side by side, making high and low PC for CUs and functions be the
same, and thus they will all be empty ranges. This makes the test fail,
since we never technically enter the functions that we want to check.
This commit skips that test when using clang. If we ever port this test
to use the dwarf assembler, we can reenable it with clang.
Approved-By: Tom Tromey <tom@tromey.com>
The inline tests in gdb.mi/mi-var-cp.cc were failing when using clang to
run the test. This happened because inline tests want to step past the C
statements and then run the TCL tests, but in mi-var-cp.cc the statement
to be stepped past is "return s2.i;". Since clang links the epilogue
information to the return statement, not the closing brace,
single-stepping past return had us exiting the function - which made the
expressions invalid.
This commit fixes this by making the function have 2 C statements, and
the return one be after all inline tests, so we know GDB won't leave the
function before running the create_varobj tests.
Approved-By: Tom Tromey <tom@tromey.com>
Clang adds line table information for a try/catch block differently to
gcc. Instead of linking the instructions related to __cxa_begin_catch to
the line containing the "catch" statement in the source code, it links
to the closing brace of the try block.
This was causing gdb.mi/mi-catch-cpp-exceptions.exp to fail when tested
with clang. The test was updated to have the catch in the same line as
the closing brace so it passes with no additional modifications with
clang.
Approved-By: Tom Tromey <tom@tromey.com>
A sequence such as:
li at,-1
bne xx,at,0f
li at,1
dsll32 at,at,0x1f
is produced in the expansion of the DDIV and DREM assembly macros, where
a redundant `li at,1' instruction is used to load an intermediate value
of 1 into $at, which is then left-shifted by 63 with `dsll32 at,at,0x1f'
yielding 0x8000000000000000. However this value likewise results from
left-shifting the value of -1, already present in $at at this point.
Remove the extraneous instruction then, shortening the sequence emitted.
Adjust dumps in the testsuite accordingly.
Add `--show-raw-insn' to division tests so as to verify branch offsets
without the need to know actual offsets into the text section individual
instructions have been assembled at. Add `-z' where applicable to make
interlock NOP instructions appear in output so as to verify them without
the need to know the offsets too. Replace individual offsets to match
against with generic patterns so that a change in the expansion of an
assembly macro does not affect code that follows.
Rewrite the inline documentation for the characters used in the `args'
member of `struct mips_opcode' to make it consistent in terms of style
and formatting. Discard references to inexistent macros.
Following
commit 6cce025114
Date: Fri Mar 3 19:03:15 2023 +0000
gdb: only insert thread-specific breakpoints in the relevant inferior
... when building amd-dbgapi-target.c:
CXX amd-dbgapi-target.o
/home/smarchi/src/binutils-gdb/gdb/amd-dbgapi-target.c:486:8: error: ‘void amd_dbgapi_target_breakpoint::re_set()’ marked ‘override’, but does not override
486 | void re_set () override;
| ^~~~~~
Update the signature to match the base.
Change-Id: Ie8bd71a63284917180f3e67eead58bea74bb0692
After adding dwarf assembly to test-case gdb.dwarf2/enum-type.exp that adds
this debug info:
...
<1><11f>: Abbrev Number: 3 (DW_TAG_enumeration_type)
<120> DW_AT_specification: <0x130>
<2><124>: Abbrev Number: 4 (DW_TAG_enumerator)
<125> DW_AT_name : val1
<12a> DW_AT_const_value : 1
<2><12b>: Abbrev Number: 0
<1><12c>: Abbrev Number: 5 (DW_TAG_namespace)
<12d> DW_AT_name : ns
<2><130>: Abbrev Number: 6 (DW_TAG_enumeration_type)
<131> DW_AT_name : e
<133> DW_AT_type : <0x118>
<137> DW_AT_declaration : 1
...
I run into an assertion failure:
...
(gdb) file enum-type^M
Reading symbols from enum-type...^M
cooked-index.h:214: internal-error: get_parent: \
Assertion `(flags & IS_PARENT_DEFERRED) == 0' failed.^M
...
This was reported in PR32160 comment 1.
This is a regression since commit 4e417d7bb1 ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").
Fix this by reverting the commit.
[ Also drop the kfails for PR31900 and PR32158, which are regressions by that
same commit. ]
That allows us to look at the output of "maint print objfiles", and for val1
we get an entry without parent:
...
[27] ((cooked_index_entry *) 0x7fbbb4002ef0)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x124
parent: ((cooked_index_entry *) 0)
...
which is incorrect, as noted in that same comment, but an improvement over the
assertion failure, and I don't think that ever worked. This is to be
addressed in a follow-up patch.
Reverting the commit begs the question: what was it trying to fix in the first
place, and do we need a different fix? I've investigated this and filed
PR32160 to track this.
My guess is that the commit was based on a misunderstand of what we track
in cooked_indexer::m_die_range_map.
Each DIE has two types of parent DIEs:
- a DIE that is the parent as indicated by the tree structure in which DIEs
occur, and
- a DIE that represent the parent scope.
In most cases, these two are the same, but some times they're not.
The debug info above demonstrates such a case. The DIE at 0x11f:
- has a tree-parent: the DIE representing the CU, and
- has a scope-parent: DIE 0x12c representing namespace ns.
In cooked_indexer::m_die_range_map, we track scope-parents, and the commit
tried to add a tree-parent instead.
So, I don't think we need a different fix, and propose we backport the reversal
for gdb 15.2.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32160
Consider test-case:
...
namespace ns {
enum class ec {
val2 = 2
};
}
int main () {
return (int)ns::ec::val2;
}
...
compiled with debug info:
...
$ g++ test.c -g
...
When looking at the cooked index entry for val2 using "maint print objfiles",
we get:
...
[7] ((cooked_index_entry *) 0x7f8ecc002ef0)
name: val2
canonical: val2
qualified: ns::val2
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xe9
parent: ((cooked_index_entry *) 0x7f8ecc002e90) [ns]
...
which is wrong, there is no source level entity ns::val2.
This is PR symtab/32158.
This is a regression since commit 4e417d7bb1 ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").
Reverting the commit on current trunk fixes the problem, and gets us instead:
...
[7] ((cooked_index_entry *) 0x7fba70002ef0)
name: val2
canonical: val2
qualified: ns::ec::val2
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xe9
parent: ((cooked_index_entry *) 0x7fba70002ec0) [ec]
...
Add a regression test for this PR in test-case gdb.dwarf2/enum-type-c++.exp.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158
Consider the following test-case:
...
$ cat a.h
namespace ns {
class A {
public:
enum {
val1 = 1
};
};
}
$ cat main.c
ns::A a;
int
main (void)
{
return 0;
}
$ cat val1.c
int u1 = ns::A::val1;
...
compiled with debug info:
...
$ g++ main.c val1.c -g
...
When trying to print ns::A::val with current trunk and gdb 15.1 we get:
...
$ gdb -q -batch a.out -ex "print ns::A::val1"
There is no field named val1
...
This PR c++/31900.
With gdb 14.2 we get the expected:
...
$ gdb -q -batch a.out -ex "print ns::A::val1"
$1 = ns::A::val1
...
This is a regression since commit 4e417d7bb1 ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").
Reverting the commit on current trunk fixes the problem.
So how does this problem happen?
First, let's consider the current trunk, with the commit reverted.
Gdb looks for the entry ns::A::val1, and find this entry:
...
[29] ((cooked_index_entry *) 0x7f7830002ef0)
name: val1
canonical: val1
qualified: ns::A::val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x15a
parent: ((cooked_index_entry *) 0x7f7830002ec0) [A]
...
and expands the corresponding CU val1.c containing this debug info:
...
<2><14a>: Abbrev Number: 3 (DW_TAG_class_type)
<14b> DW_AT_name : A
<14d> DW_AT_byte_size : 1
<3><150>: Abbrev Number: 4 (DW_TAG_enumeration_type)
<151> DW_AT_encoding : 7 (unsigned)
<152> DW_AT_byte_size : 4
<153> DW_AT_type : <0x163>
<159> DW_AT_accessibility: 1 (public)
<4><15a>: Abbrev Number: 5 (DW_TAG_enumerator)
<15b> DW_AT_name : val1
<15f> DW_AT_const_value : 1
<4><160>: Abbrev Number: 0
<3><161>: Abbrev Number: 0
<2><162>: Abbrev Number: 0
...
after which it finds ns::A::val1 in the expanded symtabs.
Now let's consider the current trunk as is (so, with the commit present).
Gdb looks for the entry ns::A::val1, but doesn't find it because the val1
entry is missing its parent:
...
[29] ((cooked_index_entry *) 0x7f5240002ef0)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x15a
parent: ((cooked_index_entry *) 0)
...
Then gdb looks for the entry ns::A, and finds this entry:
...
[3] ((cooked_index_entry *) 0x7f5248002ec0)
name: A
canonical: A
qualified: ns::A
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0xdd
parent: ((cooked_index_entry *) 0x7f5248002e90) [ns]
...
which corresponds to this debug info, which doesn't contain val1
due to -fno-eliminate-unused-debug-types:
...
<2><dd>: Abbrev Number: 3 (DW_TAG_class_type)
<de> DW_AT_name : A
<e0> DW_AT_byte_size : 1
<2><e3>: Abbrev Number: 0
...
Gdb expands the corresponding CU main.c, after which it doesn't find
ns::A::val1 in the expanded symtabs.
The root cause of the problem is the missing parent on the val1
cooked_index_entry, but this only becomes user-visible through the
elaborate scenario above.
Add a test-case gdb.dwarf2/enum-type-c++.exp that contains a regression test
for this problem that doesn't rely on expansion state or
-feliminate-unused-debug-types, but simply tests for the root cause by
grepping for ns::A::val1 in the output of "maint print objfile".
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900
Commit f89276a2f3 ("change type of `general_symbol_info::m_section`
to int") did what it says in the title -- changed the type of the
section index from short to int. However, it seems incomplete, in
that there are uses of the section index that use the type 'short'.
This patch fixes the ones I found, first by searching for
"short.*sect" and then by looking at all the callers of section_index
(and then functions called with the resulting value) just to try to be
more sure.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
When the filename quoting change was merged into the AdaCore tree, we
saw a regression in a test setup that uses the DWARF 5 index (that is
running gdb-add-index), and a filename with a space in it.
Initially I thought this was a change in the 'file' command -- but
looking again, I found out that 'file' has worked this way for a
while, and our immediate error was caused by the (documented) change
to "save gdb-index".
While I'm not sure why this test was working previously, it seems to
me that gdb-add-index.sh requires a change to quote the arguments to
"file" and "save gdb-index".
While working on this, though, it seemed to me that multiple other
spots needed quoting for the script to work correctly. And, I was
unable to get quoting working correctly in the objcopy calls, so I
split it into multiple different invocations.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Oleg Tolmatcev noticed that DAP launch and attach requests don't
properly handle Windows filenames, because "file" doesn't handle the
backslash characters correctly. This patch adds quoting to the
command in an attempt to fix this.
Functions implementing `solib_ops::current_sos` return a list of solib
object, transferring the ownership to their callers. However, the
return type, `intrusive_list<solib>`, does not reflect that.
Also, some of these functions build these lists incrementally, reading
this from the target for each solib. If a target read were to throw,
for instance, the already created solibs would just be leaked.
Change `solib_ops::current_sos` to return an owning_intrusive_list to
address that. Change `program_space::so_list` to be an
owning_intrusive_list as well. This also saves us doing a few manual
deletes.
Change-Id: I6e4071d49744874491625075136c59cce8e608d4
Reviewed-by: Keith Seitz <keiths@redhat.com>
