| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Commit f89276a2f3e ("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>
|
|
>From what I can see, lookup_minimal_symbol doesn't have any dependencies
on the global current state other than the single reference to
current_program_space. Add a program_space parameter and make that
current_program_space reference bubble up one level.
Change-Id: I759415e2f9c74c9627a2fe05bd44eb4147eee6fe
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Most calls to lookup_minimal_symbol don't pass a value for sfile and
objf. Make these parameters optional (have a default value of
nullptr). And since passing a value to `objf` is much more common than
passing a value to `sfile`, swap the order so `objf` comes first, to
avoid having to pass a nullptr value to `sfile` when wanting to pass a
value to `objf`.
Change-Id: I8e9cc6b942e593bec640f9dfd30f62786b0f5a27
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
This is a simple find / replace from "struct bound_minimal_symbol" to
"bound_minimal_symbol", to make things shorter and more consisten
througout. In some cases, move variable declarations where first used.
Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Now that defs.h, server.h and common-defs.h are included via the
`-include` option, it is no longer necessary for source files to include
them. Remove all the inclusions of these files I could find. Update
the generation scripts where relevant.
Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837
Approved-By: Pedro Alves <pedro@palves.net>
|
|
This patch changes the DWARF reader to use the new symbol domains. It
also adjusts many bits of associated code to adapt to this change.
The non-DWARF readers are updated on a best-effort basis. This is
somewhat simpler since most of them only support C and C++. I have no
way to test a few of these.
I went back and forth a few times on how to handle the "tag"
situation. The basic problem is that C has a special namespace for
tags, which is separate from the type namespace. Other languages
don't do this. So, the question is, should a DW_TAG_structure_type
end up in the tag domain, or the type domain, or should it be
language-dependent?
I settled on making it language-dependent using a thought experiment.
Suppose there was a Rust compiler that only emitted nameless
DW_TAG_structure_type objects, and specified all structure type names
using DW_TAG_typedef. This DWARF would be correct, in that it
faithfully represents the source language -- but would not work with a
purely struct-domain implementation in gdb. Therefore gdb would be
wrong.
Now, this approach is a little tricky for C++, which uses tags but
also enters a typedef for them. I notice that some other readers --
like stabsread -- actually emit a typedef symbol as well. And, I
think this is a reasonable approach. It uses more memory, but it
makes the internals simpler. However, DWARF never did this for
whatever reason, and so in the interest of keeping the series slightly
shorter, I've left some C++-specific hacks in place here.
Note that this patch includes language_minimal as a language that uses
tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp,
which doesn't specify the language for a type unit. Arguably this
test case is wrong.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
This changes gdb to use the C++17 [[fallthrough]] attribute rather
than special comments.
This was mostly done by script, but I neglected a few spellings and so
also fixed it up by hand.
I suspect this fixes the bug mentioned below, by switching to a
standard approach that, presumably, clang supports.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159
Approved-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Pedro Alves <pedro@palves.net>
|
|
This changes main_type to hold a language, and updates the debug
readers to set this field. This is done by adding the language to the
type-allocator object.
Note that the non-DWARF readers are changed on a "best effort" basis.
This patch also reimplements type::is_array_like to use the type's
language, and it adds a new type::is_string_like as well. This in
turn lets us change the Python implementation of these methods to
simply defer to the type.
|
|
Add these two methods, rename the field to m_bitsize to make it pseudo
private.
Change-Id: Ief95e5cf106e72f2c22ae47b033d0fa47202b413
Approved-By: Tom Tromey <tom@tromey.com>
|
|
After finding this code in buildsym_compunit::finish_block_internal:
...
ftype->set_fields
((struct field *)
TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
...
and fixing PR30810 by using TYPE_ZALLOC, I wondered if there were more
locations that needed fixing.
I decided to make things easier to spot by factoring out a new function
alloc_fields:
...
/* Allocate the fields array of this type, with NFIELDS elements. If INIT,
zero-initialize the allocated memory. */
void
type::alloc_fields (unsigned int nfields, bool init = true);
...
where:
- a regular use would be "alloc_fields (nfields)", and
- an exceptional use that needed no initialization would be
"alloc_fields (nfields, false)".
Pretty soon I discovered that most of the latter cases are due to
initialization by memcpy, so I added two variants of copy_fields as well.
After this rewrite there are 8 uses of set_fields left:
...
gdb/coffread.c: type->set_fields (nullptr);
gdb/coffread.c: type->set_fields (nullptr);
gdb/coffread.c: type->set_fields (nullptr);
gdb/eval.c: type->set_fields
gdb/gdbtypes.c: type->set_fields (args);
gdb/gdbtypes.c: t->set_fields (XRESIZEVEC (struct field, t->fields (),
gdb/dwarf2/read.c: type->set_fields (new_fields);
gdb/dwarf2/read.c: sub_type->set_fields (sub_type->fields () + 1);
...
These fall into the following categories:
- set to nullptr (coffread.c),
- type not owned by objfile or gdbarch (eval.c), and
- modifying an existing fields array, like adding an element at the end or
dropping an element at the start (the rest).
Tested on x86_64-linux.
|
|
psympriv.h was intended for use by code that created partial symbols.
Now that no generic code needs psymtab.h any more, psympriv.h can be
merged into psymtab.h.
|
|
This changes psymbols themselves to use unrelocated_addr. This
transform is largely mechanical. I don't think it finds any bugs.
|
|
This changes partial symbol tables to use unrelocated_addr for the
text_high and text_low members. This revealed some latent bugs in
ctfread.c, which are fixed here.
|
|
This renames objfile_type to be an overload of builtin_type, in
preparation for their unification.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes the array type creation functions to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
placement of the index type of the array, which is what this patch
implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes the range type creation functions to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
underlying type of the range, which is what this patch implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_float_type and init_float_type by using a type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_boolean_type and init_boolean_type by using a type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_character_type and init_character_type by using a
type allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This unifies arch_integer_type and init_integer_type by using a type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This removes init_type, replacing all uses with the new type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This removes alloc_type, replacing all uses with the new type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Right now, the section index passed to end_compunit_symtab is always
SECT_OFF_TEXT. Remove this parameter and simply always use
SECT_OFF_TEXT.
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
Remove the macro, replace all uses with calls to type::length.
Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
|
|
Add the `length` and `set_length` methods on `struct type`, in order to remove
the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the
getter, so all the call sites of the macro that are used as a setter are
changed to use the setter method directly. The next patch will remove the
macro completely.
Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4
|
|
Remove the macro, replace all uses by calls to type::target_type.
Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
|
|
Add the `target_type` and `set_target_type` methods on `struct type`, in order
to remove the `TYPE_TARGET_TYPE` macro. In this patch, the macro is changed to
use the getter, so all the call sites of the macro that are used as a setter
are changed to use the setter method directly. The next patch will remove the
macro completely.
Change-Id: I85ce24d847763badd34fdee3e14b8c8c14cb3161
|
|
This changes struct objfile to use a gdb_bfd_ref_ptr. In addition to
removing some manual memory management, this fixes a use-after-free
that was introduced by the registry rewrite series. The issue there
was that, in some cases, registry shutdown could refer to memory that
had already been freed. This help fix the bug by delaying the
destruction of the BFD reference (and thus the per-bfd object) until
after the registry has been shut down.
|
|
This rewrites registry.h, removing all the macros and replacing it
with relatively ordinary template classes. The result is less code
than the previous setup. It replaces large macros with a relatively
straightforward C++ class, and now manages its own cleanup.
The existing type-safe "key" class is replaced with the equivalent
template class. This approach ended up requiring relatively few
changes to the users of the registry code in gdb -- code using the key
system just required a small change to the key's declaration.
All existing users of the old C-like API are now converted to use the
type-safe API. This mostly involved changing explicit deletion
functions to be an operator() in a deleter class.
The old "save/free" two-phase process is removed, and replaced with a
single "free" phase. No existing code used both phases.
The old "free" callbacks took a parameter for the enclosing container
object. However, this wasn't truly needed and is removed here as
well.
|
|
Remove all macros related to getting and setting some symbol value:
#define SYMBOL_VALUE(symbol) (symbol)->value.ivalue
#define SYMBOL_VALUE_ADDRESS(symbol) \
#define SET_SYMBOL_VALUE_ADDRESS(symbol, new_value) \
#define SYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes
#define SYMBOL_VALUE_COMMON_BLOCK(symbol) (symbol)->value.common_block
#define SYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block
#define SYMBOL_VALUE_CHAIN(symbol) (symbol)->value.chain
#define MSYMBOL_VALUE(symbol) (symbol)->value.ivalue
#define MSYMBOL_VALUE_RAW_ADDRESS(symbol) ((symbol)->value.address + 0)
#define MSYMBOL_VALUE_ADDRESS(objfile, symbol) \
#define BMSYMBOL_VALUE_ADDRESS(symbol) \
#define SET_MSYMBOL_VALUE_ADDRESS(symbol, new_value) \
#define MSYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes
#define MSYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block
Replace them with equivalent methods on the appropriate objects.
Change-Id: Iafdab3b8eefc6dc2fd895aa955bf64fafc59ed50
|
|
It's a bit confusing because we have both "compunit_symtab" and "symtab"
types, and many methods and functions containing "start_symtab" or
"end_symtab", which actually deal with compunit_symtabs. I believe this
comes from the time before compunit_symtab was introduced, where
symtab did the job of both.
Rename everything I found containing start_symtab or end_symtab to use
start_compunit_symtab or end_compunit_symtab.
Change-Id: If3849b156f6433640173085ad479b6a0b085ade2
|
|
I noticed that the CTF symbol reader passes the objfile's name to all
buildsym_compunit instances it creates. The result is that all
compunit_symtabs created have the same name, that of the objfile:
{ objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00)
{ ((struct compunit_symtab *) 0x621000286760)
debugformat ctf
producer (null)
name libbabeltrace2.so.0.0.0
dirname (null)
blockvector ((struct blockvector *) 0x6210003911d0)
user ((struct compunit_symtab *) (null))
{ symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003911f0)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
{ ((struct compunit_symtab *) 0x621000275c10)
debugformat ctf
producer (null)
name libbabeltrace2.so.0.0.0
dirname (null)
blockvector ((struct blockvector *) 0x621000286710)
user ((struct compunit_symtab *) (null))
{ symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x621000286730)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
Notice the two "name libbabeltrace2.so.0.0.0".
Change it to pass the partial_symtab's filename instead. The output
becomes:
{ objfile /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct objfile *) 0x613000005d00)
{ ((struct compunit_symtab *) 0x621000295610)
debugformat ctf
producer (null)
name libbabeltrace2.so.0.0.0
dirname (null)
blockvector ((struct blockvector *) 0x6210003a15d0)
user ((struct compunit_symtab *) (null))
{ symtab /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0 ((struct symtab *) 0x6210003a15f0)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
{ ((struct compunit_symtab *) 0x621000288700)
debugformat ctf
producer (null)
name current-thread.c
dirname (null)
blockvector ((struct blockvector *) 0x6210002955c0)
user ((struct compunit_symtab *) (null))
{ symtab /home/simark/src/babeltrace/src/lib/current-thread.c ((struct symtab *) 0x6210002955e0)
fullname (null)
linetable ((struct linetable *) 0x0)
}
}
Note that the first compunit_symtab still has libbabeltrace2.so.0.0.0 as
its name. This is because the CTF symbol reader really creates a
partial symtab named like this. It appears to be because the debug info
contains information that has been factored out of all CUs and is at the
"top-level" of the objfile, outside any real CU. So it creates a
partial symtab and an artificial CU that's named after the objfile.
Change-Id: I576316bab2a3668adf87b4e6cebda900a8159b1b
|
|
I am trying to do some changes to buildsym_compunit, so I am auditing
the current uses. Something seems odd with this use of
buildsym_compunit (that this patch removes).
A buildsym_compunit is normally used when building a compunit_symtab.
That is, when expanding a partial symtab into a full compunit symtab.
In ctfread.c, a buildsym_compunit is created in ctf_start_archive, which
is only used when creating partial symtabs. At this moment, I don't
see how that's useful. ctf_start_archive creates a new
buildsym_compunit and starts a subfile. But that buildsym_compunit is
never used again. It's just overriden in ctf_start_symtab, which means
we leak the old buildsym_compunit, I suppose.
Remove ctf_start_archive completely. Add an assert in
ctf_start_symtab to verify that we are not overwriting an existing
buildsym_compunit (meaning we'd leak the existing one). This assert
triggers without the other part of the fix. When doing:
$ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
...
(gdb) maintenance expand-symtabs
/home/simark/src/binutils-gdb/gdb/ctfread.c:1255: internal-error: ctf_start_symtab: Assertion `!ccp->builder' failed.
Change-Id: I666d146454a019f08e7305f3a1c4a974d27b4592
|
|
I built a random project with -gctf, in order to test the CTF support in
GDB. With my ASan/UBSan/etc-enabled build of GDB, I get:
$ ./gdb --data-directory=data-directory /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0
...
Reading symbols from /tmp/babeltrace-ctf/src/lib/.libs/libbabeltrace2.so.0.0.0...
/home/simark/src/binutils-gdb/gdb/ctfread.c:1545:31: runtime error: member call on misaligned address 0xbebebebebebebebe for type 'struct buildsym_compunit', which requires 8 byte alignment
0xbebebebebebebebe: note: pointer points here
The 0xbebebebebebebebe value is a sign that the ctf_context::builder
field is uninitialized. The problem probably goes under the radar if
the field happens to be zero-initialized, because ctf_start_archive
contains this code:
if (ccx->builder == nullptr)
{
ccx->builder = new buildsym_compunit (of,
of->original_name, nullptr, language_c, 0);
If the field was zero-initialized (by chance), this will create a new
buildsym_compunit. But if the field was purposely filled with random
bytes by one of the sanitizers, we won't create a buildsym_compunit here
and we'll continue with ccx->builder equal to 0xbebebebebebebebe.
Fix this the easy way by initializing ccx->builder where the other
ctf_context fields are initialized (yeah, this code could be made nicer
C++, but I am going for the obvious fix here).
With this patch, this passes cleanly on my system:
$ make check TESTS="gdb.ctf/*.exp" RUNTESTFLAGS="CC_FOR_TARGET=/opt/gcc/git/bin/gcc"
# of expected passes 40
... where /opt/gcc/git/bin/gcc is a gcc with CTF support, given my
system gcc does not have it.
Change-Id: Idea1b0cf3e3708b72ecb16b1b60222439160f9b9
|
|
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions. This is done under the name
"gdb_printf". Most of this patch was written by script.
|
|
Add a getter and a setter for a symbol's type. Remove the corresponding
macro and adjust all callers.
Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
|
|
Add a getter and a setter for a symbol's domain. Remove the
corresponding macro and adjust all callers.
Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
|
|
Add a getter and a setter for a symbol's aclass index. Remove the
corresponding macro and adjust all callers.
Change-Id: Ie8c8d732624cfadb714aba5ddafa3d29409b3d39
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
A bug was filed against the incorrect underlying type setting for
an enumeration type, which was caused by a copy and paste error.
This patch fixes the problem by setting it by calling objfile_int_type,
which was originally dwarf2_per_objfile::int_type, with ctf_type_size bits.
Also add error checking on ctf_func_type_info call.
|
|
Add accessors for the various location values in struct field. This
lets us assert that when we get a location value of a certain kind (say,
bitpos), the field's location indeed contains a value of that kind.
Remove the SET_FIELD_* macros, instead use the new setters directly.
Update the FIELD_* macros used to access field locations to go through
the getters. They will be removed in a subsequent patch.
There are places where the FIELD_* macros are used on call_site_target
structures, because it contains members of the same name (loc_kind and
loc). For now, I have replicated the getters/setters in
call_site_target. But we could perhaps eventually factor them in a
"location" structure that can be used at both places.
Note that the field structure, being zero-initialized, defaults to a
bitpos location with value 0. While writing this patch, I tried to make
it default to an "unset" location, to catch places where we would miss
setting a field's location. However, I found that some places relied on
the default being "bitpos 0", so I left it as-is. This change could
always be done as follow-up work, making these places explicitly set the
"bitpos 0" location.
I found two issues to fix:
- I got some failures in the gdb.base/infcall-nested-structs-c++.exp
test. They were caused by two functions in amd64-tdep.c using
TYPE_FIELD_BITPOS before checking if the location is of the bitpos
kind, which they do indirectly through `field_is_static`. Simply
move getting the bitpos below the field_is_static call.
- I got a failure in gdb.xml/tdesc-regs.exp. It turns out that in
make_gdb_type_enum, we set enum field values using SET_FIELD_BITPOS,
and later access them through FIELD_ENUMVAL. Fix that by using
set_loc_enumval to set the value.
Change-Id: I53d3734916c46457576ba11dd77df4049d2fc1e8
|
|
Add the `name` and `set_name` methods on `struct field`, in order to
remove `FIELD_NAME` and `TYPE_FIELD_NAME` macros. In this patch, the
macros are changed to use `field::name`, so all the call sites that are
used to set the field's name are changed to use `field::set_name`.
The next patch will remove the macros completely.
Note that because of the name clash between the existing field named
`name` and the new method, I renamed the field `m_name`. It is not
private per-se, because we can't make `struct field` a non-POD yet, but
it should be considered private anyway (not accessed outside `struct
field`).
Change-Id: If16ddbca4e0c39d0ff9da420bb5cdebe5b9b0896
|
|
Now gdb is capable of debugging executable, which consists of multiple
compilation units (CUs) with the CTF debug info. An executable could
potentially have one or more archives, which, in CTF context, contain
conflicting types.
all changes were made in ctfread.c in which elfctf_build_psymtabs was
modified to handle archives, via the ctf archive iterator and its callback
build_ctf_archive_member and scan_partial_symbols was modified to scan
archives, which are treated as subfiles, to build the psymtabs.
Also changes were made to handle CTF's data object section and function
info section which now share the same format of their contents - an array
of type IDs. New functions ctf_psymtab_add_stt_entries, which is called by
ctf_psymtab_add_stt_obj and ctf_psymtab_add_stt_func, and add_stt_entries,
which is called by add_stt_obj and add_stt_func when setting up psymtabs
and full symtab, respectively.
|
|
I wrote a small script to spot a pattern of indentation mistakes I saw
happened in breakpoint.c. And while at it I ran it on all files and
fixed what I found. No behavior changes intended, just indentation and
addition / removal of curly braces.
gdb/ChangeLog:
* Fix some indentation mistakes throughout.
gdbserver/ChangeLog:
* Fix some indentation mistakes throughout.
Change-Id: Ia01990c26c38e83a243d8f33da1d494f16315c6e
|
|
The problems can be illustrated, with any program, below:
(gdb) print main
$1 = {main} 0x0
The return type was incorrectly set in read_func_kind_type, with
the name of the function, which leads c_type_print_base_1 to print
it. In addition, the address of a new function needs to be set with
that info in its minimal symtab entry, when the new function is added.
After the fix:
(gdb) print main
$1 = {int ()} 0x4004b7 <main>
A new test, gdb.ctf/funcreturn.exp, is added to the testsuite.
gdb/ChangeLog:
* ctfread.c (new_symbol): Set function address.
(read_func_kind_type): Remove incorrect type name setting.
Don't copy name returned from ctf_type_ame_raw throughout file.
gdb/testsuite/ChangeLog:
* gdb.ctf/funcreturn.exp: New file.
* gdb.ctf/whatis.c: Copy from gdb.base.
|
|
Added function fetch_tid_type which calls get_tid_type and will set up
the type, associated with a tid, if it is not read in yet. Also implement
function read_forward_type which handles the CTF_K_FORWARD kind.
Expanded gdb.base/ctf-ptype.exp to add cases with forward references.
gdb/ChangeLog:
* ctfread.c (fetch_tid_type): New function, use throughout file.
(read_forward_type): New function.
(read_type_record): Call read_forward_type.
gdb/testsuite/ChangeLog:
* gdb.base/ctf-ptype.c: Add struct link containing a forward
reference type.
* gdb.base/ctf-ptype.exp: Add "ptype struct link".
|
|
Since partial_symtab is supposed to be objfile-independent (since series
[1]), I think it would make sense for partial_symtab to not take an
objfile as a parameter in its constructor.
This patch replaces that parameter with an objfile_per_bfd_storage
parameter.
The objfile is used for two things:
- to get the objfile_name, for debug messages. We can get that name
from the bfd instead.
- to intern the partial symtab filename. Even though it goes through
an objfile method, the request is actually forwarded to the
underlying objfile_per_bfd_storage. So we can ask the new
objfile_per_bfd_storage instead.
In order to get a reference to the BFD from the objfile_per_bfd_storage,
the BFD is saved in the objfile_per_bfd_storage object.
[1] https://sourceware.org/pipermail/gdb-patches/2021-February/176625.html
gdb/ChangeLog:
* psympriv.h (struct partial_symtab) <partial_symtab>: Change
objfile parameter for objfile_per_bfd_storage, adjust callers.
(struct standard_psymtab) <standard_psymtab>: Likewise.
(struct legacy_psymtab) <legacy_psymtab>: Likewise.
* psymtab.c (partial_symtab::partial_symtab): Likewise.
* ctfread.c (struct ctf_psymtab): Likewise.
* dwarf2/read.h (struct dwarf2_psymtab): Likewise.
* dwarf2/read.c (struct dwarf2_include_psymtab): Likewise.
(dwarf2_create_include_psymtab): Likewise.
* objfiles.h (struct objfile_per_bfd_storage)
<objfile_per_bfd_storage>: Add bfd parameter, adjust callers.
<get_bfd>: New method.
<m_bfd>: New field.
* objfiles.c (get_objfile_bfd_data): Adjust.
Change-Id: I2ed3ab5d2e6f27d034bd4dc26ae2fae7b0b8a2b9
|
|
This patch finally changes gdb so that an objfile can have multiple
sources of partial symbols (or mixed partial symbols and other kinds
of indices).
This is done by having each symbol reader create its own
psymbol_functions object and add it to the 'qf' list in the objfile.
gdb/ChangeLog
2021-03-20 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_initial_scan): Create partial symtabs.
* symfile.c (syms_from_objfile_1, reread_symbols): Update.
* psymtab.h (make_psymbol_functions): Don't declare.
* psymtab.c (make_psymbol_functions): Remove.
(maintenance_print_psymbols): Update.
* psympriv.h (struct psymbol_functions): Add no-argument
constructor.
* objfiles.h (struct objfile) <reset_psymtabs>: Remove.
<partial_symtabs>: Remove.
* mdebugread.c (mdebug_build_psymtabs): Create partial symtabs.
* elfread.c (read_partial_symbols): Update.
(elf_symfile_read): Remove check for existing partial symbols.
Don't clear "qf".
* dwarf2/read.c (dwarf2_has_info): Remove check for existing
partial symbols.
(dwarf2_build_psymtabs): Add psymbol_functions parameter. Create
partial symtabs.
* dwarf2/public.h (dwarf2_build_psymtabs): Add psymbol_functions
parameter.
* dbxread.c (dbx_symfile_read): Create partial symtabs.
* ctfread.c (elfctf_build_psymtabs): Create partial symtabs.
|
