| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: Ifb80557187c12822bdea7ad400c32c3dce968a7f
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that check-include-guards.py doesn't error in certain
situations -- but in situations where the --update flag would cause a
file to be changed.
This patch changes the script to issue an error for any discrepancy.
It also fixes the headers that weren't correct.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Check for target_fileio_read_alloc failure in linux_fill_prpsinfo
before dereferencing buffer. This fixes a segfault in the 'gcore'
command when attached to certain remote targets.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32441
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
When running test-case gdb.base/step-over-syscall.exp with target board
unix/-m32 on an AMD processor, I run into:
...
(gdb) x/2i $pc^M
=> 0xf7fc9575 <__kernel_vsyscall+5>: syscall^M
0xf7fc9577 <__kernel_vsyscall+7>: int $0x80^M
(gdb) PASS: $exp: fork: displaced=off: pc before/after syscall instruction
stepi^M
[Detaching after fork from child process 65650]^M
0xf7fc9579 in __kernel_vsyscall ()^M
1: x/i $pc^M
=> 0xf7fc9579 <__kernel_vsyscall+9>: pop %ebp^M
(gdb) $exp: fork: displaced=off: stepi fork insn
print /x $pc^M
$2 = 0xf7fc9579^M
(gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: pc after stepi
FAIL: $exp: fork: displaced=off: pc after stepi matches insn addr after syscall
...
The problem is that the syscall returns at the "pop %ebp" insn, while the
test-case expects it to return at the "int $0x80" insn.
This is similar to the problem I fixed in commit 14852123287 ("[gdb/testsuite]
Fix gdb.base/step-over-syscall.exp with -m32"), just that the syscall sequence
used there used the "sysenter" insn instead of the "syscall" insn.
Fix this by extending the fix for commit 14852123287 to also handle the
"syscall" insn.
Tested on x86_64-linux, both using an AMD and Intel processor.
PR testsuite/32439
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32439
|
|
dw2_get_file_names
PR 32742 shows this failing:
$ make check TESTS="gdb.ada/access_to_unbounded_array.exp" RUNTESTFLAGS="--target_board=fission"
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.ada/access_to_unbounded_array.exp ...
FAIL: gdb.ada/access_to_unbounded_array.exp: scenario=all: gdb_breakpoint: set breakpoint at foo.adb:23 (GDB internal error)
Or, interactively:
$ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.ada/access_to_unbounded_array/foo-all -ex 'b foo.adb:23' -batch
/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:19567: internal-error: set_lang: Assertion `old_value == language_unknown || old_value == language_minimal || old_value == lang' failed.
The symptom is that for a given dwarf2_per_cu, the language gets set
twice. First, set to `language_ada`, and then, to `language_minimal`.
It's unexpected for the language of a CU to get changed like this.
The CU at offset 0x0 in the main file looks like:
0x00000000: Compile Unit: length = 0x00000030, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000034)
0x0000000b: DW_TAG_compile_unit
DW_AT_low_pc [DW_FORM_addr] (0x000000000000339a)
DW_AT_high_pc [DW_FORM_data8] (0x0000000000000432)
DW_AT_stmt_list [DW_FORM_sec_offset] (0x00000000)
DW_AT_GNU_dwo_name [DW_FORM_strp] ("b~foo.dwo")
DW_AT_comp_dir [DW_FORM_strp] ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array")
DW_AT_GNU_pubnames [DW_FORM_flag_present] (true)
DW_AT_GNU_addr_base [DW_FORM_sec_offset] (0x00000000)
DW_AT_GNU_dwo_id [DW_FORM_data8] (0x277aee54e7bd47f7)
This refers to the DWO file b~foo.dwo, whose top-level DIE is:
.debug_info.dwo contents:
0x00000000: Compile Unit: length = 0x00000b63, format = DWARF32, version = 0x0004, abbr_offset = 0x0000, addr_size = 0x08 (next unit at 0x00000b67)
0x0000000b: DW_TAG_compile_unit
DW_AT_producer [DW_FORM_GNU_str_index] ("GNU Ada 14.2.1 20250207 -fgnat-encodings=minimal -gdwarf-4 -fdebug-types-section -fuse-ld=gold -gnatA -gnatWb -gnatiw -gdwarf-4 -gsplit-dwarf -ggnu-pubnames -gnatws -mtune=generic -march=x86-64")
DW_AT_language [DW_FORM_data1] (DW_LANG_Ada95)
DW_AT_name [DW_FORM_GNU_str_index] ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array/b~foo.adb")
DW_AT_comp_dir [DW_FORM_GNU_str_index] ("/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.ada/access_to_unbounded_array")
DW_AT_GNU_dwo_id [DW_FORM_data8] (0xdbeffefab180a2cb)
The thing to note is that the language attribute is only present in the
DIE in the DWO file, not on the DIE in the main file.
The first time the language gets set is here:
#0 dwarf2_per_cu::set_lang (this=0x50f0000044b0, lang=language_ada, dw_lang=DW_LANG_Ada95) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:20788
#1 0x0000555561666af6 in cutu_reader::prepare_one_comp_unit (this=0x7ffff10bf2b0, cu=0x51700008e000, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:21029
#2 0x000055556159f740 in cutu_reader::cutu_reader (this=0x7ffff10bf2b0, this_cu=0x50f0000044b0, per_objfile=0x516000066080, abbrev_table=0x510000004640, existing_cu=0x0, skip_partial=false, pretend_language=language_minimal, cache=0x7ffff11b95e0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3371
#3 0x00005555615a547a in process_psymtab_comp_unit (this_cu=0x50f0000044b0, per_objfile=0x516000066080, storage=0x7ffff11b95e0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3799
#4 0x00005555615a9292 in cooked_index_worker_debug_info::process_cus (this=0x51700008dc80, task_number=0, first=std::unique_ptr<dwarf2_per_cu> = {...}, end=std::unique_ptr<dwarf2_per_cu> = {...}) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4122
In this code path (particularly this specific cutu_reader constructir),
the work is done to find and read the DWO file. So the language is
properly identifier as language_ada, all good so far.
The second time the language gets set is:
#0 dwarf2_per_cu::set_lang (this=0x50f0000044b0, lang=language_minimal, dw_lang=0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:20788
#1 0x0000555561666af6 in cutu_reader::prepare_one_comp_unit (this=0x7ffff0f42730, cu=0x517000091b80, pretend_language=language_minimal) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:21029
#2 0x00005555615a1822 in cutu_reader::cutu_reader (this=0x7ffff0f42730, this_cu=0x50f0000044b0, per_objfile=0x516000066080, pretend_language=language_minimal, parent_cu=0x0, dwo_file=0x0) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3464
#3 0x000055556158c850 in dw2_get_file_names (this_cu=0x50f0000044b0, per_objfile=0x516000066080) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:1956
#4 0x000055556158f4f5 in dw_expand_symtabs_matching_file_matcher (per_objfile=0x516000066080, file_matcher=...) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2157
#5 0x00005555616329e2 in cooked_index_functions::expand_symtabs_matching (this=0x50200002ab50, objfile=0x516000065780, file_matcher=..., lookup_name=0x0, symbol_matcher=..., expansion_notify=..., search_flags=..., domain=..., lang_matcher=...) at /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:15912
#6 0x0000555562ca8a14 in objfile::map_symtabs_matching_filename (this=0x516000065780, name=0x50200002ad90 "break pck.adb", real_path=0x0, callback=...) at /home/smarchi/src/binutils-gdb/gdb/symfile-debug.c:207
#7 0x0000555562d68775 in iterate_over_symtabs (pspace=0x513000005600, name=0x50200002ad90 "break pck.adb", callback=...) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:727
Here, we use the other cutu_reader constructor, the one that does not
look up the DWO file for the passed CU. If a DWO file exists for this
CU, the caller is expected to pass it as a parameter. That cutu_reader
constructor also ends up setting the language of the CU. But because it
didn't read the DWO file, it didn't figure out the language is
language_ada, so it tries to set the language to the default,
language_minimal.
A question is: why do we end up trying to set the CU's language is this
context. This is completely unrelated to what we're trying to do, that
is get the file names from the line table. Setting the language is a
side-effect of just constructing a cutu_reader, which we need to look up
attributes in dw2_get_file_names_reader. There are probably some
cleanups to be done here, to avoid doing useless work like looking up
and setting the CU's language when all we need is an object to help
reading the DIEs and attributes. But that is future work.
The same cutu_reader constructor is used in
`dwarf2_per_cu::ensure_lang`. Since this is the version of cutu_reader
that does not look up the DWO file, it will conclude that the language
is language_minimal and set that as the CU's language. In other words,
`dwarf2_per_cu::ensure_lang` will get the language wrong, pretty ironic.
Fix this by using the other cutu_reader constructor in those two spots.
Pass `per_objfile->get_cu (this_cu)`, as the `existing_cu` parameter. I
think this is necessary, because that constructor has an assert to check
that if `existing_cu` is nullptr, then there must not be an existing
`dwarf2_cu` in the per_objfile.
To avoid getting things wrong like this, I think that the second
cutu_reader constructor should be reserved for the spots that do pass a
non-nullptr dwo_file. The only spot at the moment in
create_cus_hash_table, where we read multiple units from the same DWO
file. In this context, I guess it makes sense for efficiency to get the
dwo_file once and pass it down to cutu_reader. For that constructor,
make the parameters non-optional, add "non-nullptr" asserts, and update
the code to assume the passed values are not nullptr.
What I don't know is if this change is problematic thread-wise, if the
functions I have modified to use the other cutu_reader constructor can
be called concurrently in worker threads. If so, I think it would be
problematic.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32742
Change-Id: I980d16875b9a43ab90e251504714d0d41165c7c8
Approved-By: Tom Tromey <tom@tromey.com>
|
|
PR symtab/31010 points out that something like "ptype INT" will expand
all CUs in a typical program. The OP further points out that the
original patch for PR symtab/30520:
https://sourceware.org/pipermail/gdb-patches/2024-January/205924.html
... did solve the problem, but the patch changed after (my) review and
reintroduced the bug.
In cooked_index_functions::expand_symtabs_matching, the final
component of a split name is compared with the entry's name using the
usual method of calling get_symbol_name_matcher.
This code iterates over languages and tries to split the original name
according to each style. But, the Ada splitter uses the decoded name
-- "int". This causes every C or C++ CU to be expanded.
Clearly this is wrong. And, it seems to me that looping over
languages and trying to guess the splitting style for the input text
is probably bad. However, fixing the problem is not so easy (again
due to Ada). I've filed a follow-up bug, PR symtab/32733, for this.
Meanwhile, this patch changes the code to be closer to the
originally-submitted patch. This works because the comparison is now
done between the full name and the "lookup_name_without_params"
object, which is a less adulterated variant of the original input.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31010
Tested-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Currently, lookup_name_info::match_any symbol_name_match_type::FULL.
However, this seems wrong. Consider the expand_symtabs_matching
implementation of the cooked index: it compares name components, and
then if all the components match, it checks:
if ((match_type == symbol_name_match_type::FULL
|| (lang != language_ada
&& match_type == symbol_name_match_type::EXPRESSION)))
{
if (parent != nullptr)
continue;
That is, if the component-matching loop did not finish, and a full
match is requested, then fail to match. This handles cases where the
index is asked to look up "b::c" but finds "a::b::c".
However, match_any should match, well, any. So, it seems to me that
checking any parent matches is irrelevant -- and therefore this should
use wild matching.
|
|
I noticed that a certain name didn't work correctly when trying to
remove the parameters. I put this into lookup_name_info-selftests.c.
I tracked this down to the fact that cp-name-parser.y doesn't handle
">>" to end templates. This patch fixes this in a simple way --
accepting the "RSH" token where appropriate and then un-pushing a ">".
|
|
This changes cpname_state to have a constructor and some inline
initializers.
|
|
Move the cooked_indexer class declaration to a new cooked-indexer.h
file, and the implementation to cooked-indexer.c.
Change-Id: Ibff3b06045b2af65fa9516097acf732d7c2d9414
Approved-By: Tom Tromey <tom@tromey.com>
|
|
cooked_index_storage is currently declared in `cooked-index.h` and
implemented in `read.c`. Move all that to new
`cooked-index-storage.{h,c}` files.
Change-Id: I2a07eb446d8a07b15c5664dfe01e3a820cdd45be
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In order to move some things outside of read.c, cutu_reader needs to be
in a header file.
Change-Id: Ib26d7949c55867848d109332caf2efb1a6e72923
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The following amd64 insn:
...
0: 67 d5 44 8d 3d 00 00 00 00 lea 0x0(%eip),%r31d
...
uses the REX2 prefix [1], which is currently not supported in
amd64_get_insn_details.
Add the missing support in amd64_get_insn_details, as well as a corresponding
unit test.
Likewise for an amd64 insn using an EVEX prefix [2]:
...
0: 62 f1 7c 48 28 05 00 fc ff ff vmovaps -0x400(%rip),%zmm0
...
Tested on x86_64-linux.
PR tdep/32725
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32725
[1] https://en.wikipedia.org/wiki/VEX_prefix
[2] https://en.wikipedia.org/wiki/EVEX_prefix
|
|
PR tdep/31952 reports that displaced stepping over an instruction pointer
relative insn "vmovdqu 0x20(%rip),%ymm1" gives the wrong results.
This is caused by misclassification of the insn in amd64_get_insn_details,
which results in details.modrm_offset == -1, while the instruction in fact
does have a modrm byte.
The instruction is encoded as follows:
...
400557: c5 fe 6f 0d 20 00 00 00 vmovdqu 0x20(%rip),%ymm1
...
where:
- "0xc5 0xfe" is the vex2 prefix,
- "0x6f" is the opcode,
- "0x0d" is the modrm byte, and
- "0x20 0x00 0x00 0x00" is a 32-bit displacement.
The problem is related to details.opcode_len, which is 1.
While it is true that the length of the opcode in the insn (0x6f) is 1 byte,
the vex2 prefix implies that we're encoding an 2-byte opcode beginnning
with 0x0f [1].
Consequently, we should be using the twobyte_has_modrm map rather than the
onebyte_has_modrm map.
Fix this in amd64_get_insn_details, and add a selftest to check this.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31952
[1] https://en.wikipedia.org/wiki/VEX_prefix
|
|
In amd64_get_insn_details, I found this code with a comment explaining why
enc_prefix_offset is not set:
...
else if (vex2_prefix_p (*insn))
{
/* Don't record the offset in this case because this prefix has
no REX.B equivalent. */
insn += 2;
}
...
which I didn't understand until I looked at the only use of enc_prefix_offset,
in fixup_riprel:
...
/* REX.B should be unset (VEX.!B set) as we were using rip-relative
addressing, but ensure it's unset (set for VEX) anyway, tmp_regno
is not r8-r15. */
if (insn_details->enc_prefix_offset != -1)
{
gdb_byte *pfx = &dsc->insn_buf[insn_details->enc_prefix_offset];
if (rex_prefix_p (pfx[0]))
pfx[0] &= ~REX_B;
else if (vex3_prefix_p (pfx[0]))
pfx[1] |= VEX3_NOT_B;
else
gdb_assert_not_reached ("unhandled prefix");
}
...
Fix this by:
- setting enc_prefix_offset for the vex2 case in amd64_get_insn_details,
making the function more regular and easier to understand, and
- handling the vex2 case in the "enc_prefix_offset != -1" clause in
fixup_riprel.
Tested on x86_64-linux.
|
|
After I posted a tentative patch for PR31952, Alexander Monakov pointed out
that the patch broke instruction decoding for instructions vzeroall and
vzeroupper.
Add selftests for these two instructions in amd64-insn-decode, both using
vex2 and vex3 prefixes.
Tested on x86_64-linux.
|
|
I noticed here [1] that the vex2 prefix is essentially a special case of the
vex3 prefix, meaning it's possible to rewrite any insn with a vex2 prefix into
an equivalent one with a vex3 prefix.
Add function vex2_to_vex3 that does precisely that, in the selftests
namespace.
Add a selftest that exercises this function.
Tested on x86_64-linux.
[1] https://en.wikipedia.org/wiki/VEX_prefix
|
|
Factor out the part of fixup_riprel that patches the insn, and use it in a
unit test.
Tested on x86_64-linux.
|
|
I wanted to add a unit test for an an rip-relative amd64 insn, so I did:
...
$ gcc -fPIE hello.c
...
and used an rip-relative insn from main:
...
4005db: 48 8d 3d 1e 00 00 00 lea 0x1e(%rip),%rdi
...
While writing the unit test, I found that amd64_get_used_input_int_reg returns
rbp as input register.
Fix this by using rip_relative_p in amd64_get_used_input_int_reg to handle
this case.
Tested on x86_64-linux.
|
|
Factor out rip_relative_p, and rewrite it to use MODRM_MOD_FIELD and
MODRM_RM_FIELD.
No functional changes.
Tested on x86_64-linux.
|
|
Add a selftest that checks the results of amd64_get_insn_details and related
functions for two basic instructions.
Add a parameter assumptions to amd64_get_used_input_int_regs, to make sure
that this selftest:
...
/* INSN: add %eax,(%rcx). */
...
SELF_CHECK (amd64_get_used_input_int_regs (&details, false)
== ((1 << EAX_REG_NUM) | (1 << ECX_REG_NUM)));
...
passes because it found the "%eax" in the insn, rather than passing because of
this assumption:
...
/* Assume RAX is used. If not, we'd have to detect opcodes that implicitly
use RAX. */
used_regs_mask |= 1 << EAX_REG_NUM;
...
Tested on x86_64-linux.
|
|
The function amd64_get_unused_input_int_reg consists of two parts:
- finding the used int registers in an insn, and
- picking an unused int register.
Factor out the first part as new function amd64_get_used_input_int_regs.
No functional changes.
Tested on x86_64-linux.
|
|
While reading amd64_get_unused_input_int_reg, I noticed that it avoids picking
RSP, which has to do with how the result of the only call to it is going to be
used.
Likewise for picking a register in the RAX ... RDI range.
Fix this by:
- adding an allowed_regs_mask parameter to amd64_get_unused_input_int_reg, and
- properly documenting the value of the corresponding argument in fixup_riprel.
No functional changes.
Tested on x86_64-linux.
|
|
I noticed that amd64_get_unused_input_int_reg uses a signed int for a bit
mask:
...
/* 1 bit for each reg */
int used_regs_mask = 0;
...
There's an assert:
...
gdb_assert (used_regs_mask < 256);
...
which is meant to assert on register numbers >= 8, but if for instance
sizeof (used_regs_mask) == 4 and used_regs_mask == (1 << 31), then that is not
caught because of the signedness.
We could fix this by changing the type to unsigned int, but that only
guarantees 16 bits in the reg mask. Intel CPUs with the APX extension support
32 int registers.
The implementation of amd64_get_unused_input_int_reg doesn't support analyzing
registers with register number >= 8 yet, but now that we're changing the type,
it seems like a good idea to anticipate this.
Fix this by using uint32_t.
Likewise, update the loop over the reg mask:
...
for (i = 0; i < 8; ++i)
{
if (! (used_regs_mask & (1 << i)))
return i;
...
to handle any used_regs_mask value rather than just those for
register number < 8.
Tested on x86_64-linux.
|
|
While reading amd64_get_unused_input_int_reg, I noticed that it first asserts,
then throws an internal_error if no unused register can be found.
Looking at the documentation of gdbarch_displaced_step_copy_insn, it seems
that a failure can be indicated less abruptly, by returning a nullptr.
Fix this by:
- returning -1 in case of failure to find an unused register in
amd64_get_unused_input_int_reg, and
- propagating this to amd64_displaced_step_copy_insn.
Tested on x86_64-linux.
|
|
Fix typos:
...
mainenance ==> maintenance
epilgoue ==> epilogue
commnds ==> commands
readibility ==> readability
informations ==> information
throwed ==> threw
compiletime ==> compile time
namepace ==> namespace
reqired ==> required
explicity ==> explicitly
reqired ==> required
...
|
|
Fix typos:
...
gdb/python/py-framefilter.c:749: indention ==> indentation
gdb/python/py-framefilter.c:837: indention ==> indentation
gdb/python/py-lazy-string.c:35: sting ==> string
gdb/python/py-progspace.c:119: Retun ==> Return
gdb/python/py-progspace.c:139: Retun ==> Return
...
|
|
Fix typos:
...
gdb/python/lib/gdb/disassembler.py:84: dissables ==> disables
gdb/python/lib/gdb/command/xmethods.py:40: experession ==> expression
...
|
|
Fix typos:
...
gdb/guile/scm-lazy-string.c:41: sting ==> string
gdb/guile/lib/gdb/iterator.scm:65: satify ==> satisfy
...
|
|
Fix typos:
...
preprend -> prepend
wth -> with
Connnections -> Connections
...
|
|
Fix typos:
...
Dependant ==> Dependent
...
|
|
Fix typos:
...
atribute ==> attribute
...
|
|
Fix typos:
...
exising ==> existing
afer ==> after
...
|
|
Fix typos:
...
gdb/tui/tui.c:64: releated ==> related
gdb/tui/tui-io.c:50: releated ==> related
...
|
|
Fix typos:
...
gdb/cli/cli-utils.h:85: fuction ==> function
gdb/cli/cli-decode.c:2457: Ambigous ==> Ambiguous
...
|
|
Fix typos in gdbarch_components.py:
...
tranformations ==> transformations
charater ==> character
Noe -> Note
...
and regenerate gdb/gdbarch-gen.h.
|
|
With the hierarchical name patches to GNAT, ada_add_block_renamings
must now be updated as well -- the comment there about the supported
forms of DW_TAG_imported_declaration is no longer correct, and now
full names must sometimes be constructed during the lookup process.
|
|
In the near future, GNAT will start emitting DWARF names in a more
standard way -- specifically, the package structure will be indicated
by nested DW_TAG_module DIEs and a given entity will be nested in its
package and only have a simple name.
This patch changes gdb to understand this style of naming, while still
supporting the existing GNAT output.
A few special cases are needed. I've commented them.
The name-computing code for the full DWARF reader is very complicated
-- much too complicated, in my opinion. There are already several
bugs in bugzilla about this (search for "physname"... but there are
others as well), so I haven't filed any new ones.
When I started this project, I thought it would solve some memory
overuse issues we sometimes see from how the index-sharding code
interacts with the GNAT-specific post-pass. However, to my surprise,
the Ada code in gdb relies on some details of symbol naming, and so
I've had to add code here to synthesize "linkage" names in some cases.
This is unfortunate, but I think can eventually be fixed; I will file
a bug to track this issue.
|
|
Unfortunately, due to some details of how the Ada support in gdb
currently works, the DWARF reader will still have to synthesize some
"full name" entries after the cooked index has been constructed.
You can see one particular finding related to this in:
https://sourceware.org/bugzilla/show_bug.cgi?id=32142
This patch adds a new flag to cooked_index_entry::full_name to enable
the construction of these names.
I hope to redo this part of the Ada support eventually, so that this
code can be removed and the full-name entries simply not created.
|
|
handle_gnat_encoded_entry might create synthetic cooked index entries
for Ada packages. These aren't currently kept in m_entries, but it
seems to me that they should be, particularly because a forthcoming
GNAT will emit explicit DW_TAG_module for these names -- with this
change, the indexes will be roughly equivalent regardless of which
compiler was used.
|
|
This updates read_module_type to turn DW_TAG_module into a
TYPE_CODE_NAMESPACE when the CU represents Ada code.
Note that the GNAT that generates this isn't generally available yet
and so this shouldn't have an impact on current code.
|
|
Currently, gdb will synthesize DW_TAG_module entries for Ada names.
These entries are treated specially by the index writer,
When GNAT starts emitting DW_TAG_module, the special case will be
incorrect, because there will be non-synthetic DW_TAG_module entries
in the index.
This patch arranges to mark the synthetic entries and changes the
index writer to follow.
|
|
In GCC we decided to use DW_TAG_module to represent Ada packages, so
make this same decision in gdb. This also updates tag_matches_domain
to handle this case.
|
|
This changes a few spots in the DWARF reader to use dwarf2_full_name
when computing the name of a type. This gives the correct name when a
type is nested in a namespace. This oddity probably wasn't noticed
before because some of the types in question are either normally
anonymous in C++ (e.g, array type) or do not appear in a namespace
(base type).
|
|
With the coming changes to GNAT, gdb must compare the unqualified
names of two enum types.
Currently, GNAT will fully-qualify enumeration constant names, so for
instance one might see "enum_with_gap__lit4" as the name.
GNAT also may emit a copy of an enumeration type when a newtype is
involved. E.g., in the arr_acc_idx_w_gap.exp test case, this can
occur for the base type of this subtype:
type Enum_Subrange is new Enum_With_Gaps range Lit1 .. Lit3;
(Note that the base type of this subrange is anonymous.)
With some forthcoming changes to GNAT, these names will no longer be
qualified -- and because the newtype is anonymous, they can't be
identically qualified. But, in gdb we still want "lit4" to resolve
without ambiguity in this scenario.
The fix is to change ada_identical_enum_types_p to compare unqualified
enum names. This will work correctly with both variants of the
compiler, and with -fgnat-encodings=all as well.
|
|
With the coming changes to GNAT, we may see two distinct but
equivalent enum types in the DWARF. In this case, it's better to use
ada_identical_enum_types_p rather than types_equal when comparing
these types... something that matters when using 'Enum_Rep.
|
|
This patch applies a few fixes to gdb.ada/fun_overload_menu.exp.
It adds some comments to the source and uses this to extract line
numbers. This is used to ensure that two otherwise-equivalent results
are in fact different, so that the test really checks that the result
is correct.
It also changes the test_menu proc to accept a list of possible
results. This lets the test work regardless of the order in which the
menu items are presented by gdb.
Finally, like an earlier patch, it changes the test to optionally
accept unqualified names from gdb.
|
|
With some forthcoming changes to GNAT, the two Get_Value functions in
this test case will end up with the same name (with the current GNAT,
one ends up with a "__2" suffix). This change will cause one test to
set multiple breakpoints; this patch changes the test to work with
either version of the compiler.
|
|
The "Rec" type in ptype-o.exp is currently named "prog__rec" by the
compiler. However, with my changes to GNAT, the type will no longer
have a prefix, as it is local to a procedure.
Changing this to just use "rec" works fine with the new compiler, but
then fails with older compilers. To allow correct operation with both
compilers, this patch simply moves the type into a new package. This
doesn't affect the meaning of the test, which is just ensuring that
ptype/o works in a certain case.
Note that the more obvious fix of just using "ptype/o rec" does not
work with the current GNAT. I haven't investigated this but I did
file a bug to track it:
https://sourceware.org/bugzilla/show_bug.cgi?id=32169
|
|
Currently, when a type is declared in a subprogram that isn't part of
a package, gdb will give this type a qualified name. E.g., in the
program for gdb.ada/arr_arr.exp:
procedure Foo is
type Array2_First is array (24 .. 26) of Integer;
gdb will name this type 'foo.array2_first'.
However, with some coming changes to GNAT (and with the remainder of
this series applied as well), this will no longer happen. Instead,
such types will be given their local name. IMO this makes more sense
anyway.
This patch updates most of the Ada tests to allow either form in the
spots where it matters. Both are accepted so that the tests continue
to work with older versions of GNAT. (A few tests are handled in
separate patches; this patch only contains the straightforward
changes.)
|
