| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
dwarf2_has_info and dwarf2_initialize_objfile are only separate
because the DWARF reader implemented lazy psymtab reading. However,
now that this is gone, we can simplify the public DWARF API again.
|
|
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 commit merges the code that looks for and loads the separate
debug symbol files from coffread.c and elfread.c. The factored out
code is moved into a new objfile::find_and_add_separate_symbol_file()
method.
For the elfread.c path there should be no user visible changes after
this commit.
For the coffread.c path GDB will now attempt to perform a debuginfod
lookup for the missing debug information, assuming that GDB can find a
build-id in the COFF file.
I don't know if COFF files can include a build-id, but I the existing
coffread.c code already includes a call to
find_separate_debug_file_by_build-id, so I know that it is at least OK
for GDB to ask a COFF file for a build-id. If the COFF file doesn't
include a build-id then the debuginfod lookup code will not trigger
and the new code is harmless.
If the COFF file does include a build-id, then we're going to end up
asking debuginfod for the debug file. As build-ids should be unique,
this should be harmless, even if debuginfod doesn't contain any
suitable debug data, it just costs us one debuginfod lookup, so I'm
not too worried about this for now.
As with the previous commit, I've done some minimal testing using the
mingw toolchain on a Linux machine, GDB seems to still access the
split debug information just fine.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In this commit:
commit 8a92335bfca80cc9b4cd217505ea0dcbfdefbf07
Date: Fri Feb 1 19:39:04 2013 +0000
the logic for when we try to load a separate debug file in elfread.c
was extended. The new code checks that the objfile doesn't already
have a separate debug objfile linked to it, and that the objfile isn't
itself a separate debug objfile for some other objfile.
The coffread code wasn't extended at the same time.
I don't know if it's possible for the coffread code to get into the
same state where these checks are needed, but I don't see why having
these checks would be a problem. In a later commit I plan to merge
this part of the elfread and coffread code, so bringing these two
pieces of code into line first makes that job easier.
I've tested this with a simple test binary compiled with the mingw
toolchain on a Linux host. After compiling the binary and splitting
out the debug info GDB still finds and loads the separate debug info.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed a comment by an include and remembered that I think these
don't really provide much value -- sometimes they are just editorial,
and sometimes they are obsolete. I think it's better to just remove
them. Tested by rebuilding.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
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>
|
|
Now that we've introduced type::{alloc_fields,copy_fields}, the places where
no zero-initialization of allocated fields is done are easy to spot:
...
$ find gdb* -type f | grep -v ChangeLog | xargs grep alloc_fields | grep false
gdb/coffread.c: type->alloc_fields (nfields, false);
gdb/coffread.c: type->alloc_fields (nsyms, false);
gdb/stabsread.c: ftype->alloc_fields (nsemi, false);
gdb/gdbtypes.c: resolved_type->alloc_fields (nfields, false);
gdb/gdbtypes.c: alloc_fields (nfields, false);
gdb/gdbtypes.c: alloc_fields (nfields, false);
gdb/mdebugread.c: t->alloc_fields (nfields, false);
gdb/mdebugread.c: ftype->alloc_fields (nparams, false);
...
All hits in gdbtypes.c are ok. There are two hits in the two variants of
copy_fields, and there's already a comment for the third.
AFAICT, the other ones are not ok, so fix those by dropping the "false"
argument.
Tested on x86_64-linux.
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.
|
|
The getsymname function uses PRIxPTR to print and uintptr_t value in
an error message. Use hex_string instead.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The getsymname function tries to emit an error using %ld for an
uintptr_t argument. Use PRIxPTR instead. Which works on any architecture
for uintptr_t.
|
|
This patch addresses an issue with malformed/fuzzed debug information that
was recently reported in gdb/30639. That bug specifically deals with
an ASAN issue, but the reproducer provided by the reporter causes a
another failure outside of ASAN:
$ ./gdb --data-directory data-directory -nx -q UAF_2
Reading symbols from /home/keiths/UAF_2...
Fatal signal: Segmentation fault
----- Backtrace -----
0x59a53a gdb_internal_backtrace_1
../../src/gdb/bt-utils.c:122
0x59a5dd _Z22gdb_internal_backtracev
../../src/gdb/bt-utils.c:168
0x786380 handle_fatal_signal
../../src/gdb/event-top.c:889
0x7864ec handle_sigsegv
../../src/gdb/event-top.c:962
0x7ff354c5fb6f ???
0x611f9a process_coff_symbol
../../src/gdb/coffread.c:1556
0x611025 coff_symtab_read
../../src/gdb/coffread.c:1172
0x60f8ff coff_read_minsyms
../../src/gdb/coffread.c:549
0x60fe4b coff_symfile_read
../../src/gdb/coffread.c:698
0xbde0f6 read_symbols
../../src/gdb/symfile.c:772
0xbde7a3 syms_from_objfile_1
../../src/gdb/symfile.c:966
0xbde867 syms_from_objfile
../../src/gdb/symfile.c:983
0xbded42 symbol_file_add_with_addrs
../../src/gdb/symfile.c:1086
0xbdf083 _Z24symbol_file_add_from_bfdRKN3gdb7ref_ptrI3bfd18gdb_bfd_ref_policyEEPKc10enum_flagsI16symfile_add_flagEPSt6vectorI14other_sectionsSaISC_EES8_I12objfile_flagEP7objfile
../../src/gdb/symfile.c:1166
0xbdf0d2 _Z15symbol_file_addPKc10enum_flagsI16symfile_add_flagEPSt6vectorI14other_sectionsSaIS5_EES1_I12objfile_flagE
../../src/gdb/symfile.c:1179
0xbdf197 symbol_file_add_main_1
../../src/gdb/symfile.c:1203
0xbdf13e _Z20symbol_file_add_mainPKc10enum_flagsI16symfile_add_flagE
../../src/gdb/symfile.c:1194
0x90f97f symbol_file_add_main_adapter
../../src/gdb/main.c:549
0x90f895 catch_command_errors
../../src/gdb/main.c:518
0x9109b6 captured_main_1
../../src/gdb/main.c:1203
0x910fc8 captured_main
../../src/gdb/main.c:1310
0x911067 _Z8gdb_mainP18captured_main_args
../../src/gdb/main.c:1339
0x418c71 main
../../src/gdb/gdb.c:39
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible. GDB will now terminate.
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
Segmentation fault (core dumped)
The issue here is that the COFF offset for the fuzzed symbol's
name is outside the string table. That is, the offset is greater
than the actual string table size.
coffread.c:getsymname actually contains a FIXME about this, and that's
what I've chosen to address to fix this issue, following what is done
in the DWARF reader:
$ ./gdb --data-directory data-directory -nx -q UAF_2
Reading symbols from /home/keiths/UAF_2...
COFF Error: string table offset (256) outside string table (length 0)
(gdb)
Unfortunately, I haven't any idea how else to test this patch since
COFF is not very common anymore. GCC removed support for it five
years ago with GCC 8.
|
|
Spotted a few places where a char is being treated as a bool. The GDB
style is to use explicit comparisons, so fix things up.
There should be no user visible changes after this commit.
|
|
Some places matching the first char of a string against
bfd_get_symbol_leading_char, which may be zero, didn't check for "".
This could lead to accesses past the end of the string and potential
buffer overruns. Fix that, and also get rid of a stupid optimisation
in dbxread when looking for "__DYNAMIC" that also might access past
the end of a string.
|
|
I found that most spots including psymtab.h do not need it. This
patch removes these includes, and also one unnecessary include of
psympriv.h.
|
|
This fixes the compilation warnings introduced by my bfdio.c patch.
The removed bfd_seeks in coff_symfile_read date back to 1994, commit
7f4c859520, prior to which the file used stdio rather than bfd to read
symbols. Since it now uses bfd to read the file there should be no
need to synchronise to bfd's idea of the file position. I also fixed
a potential uninitialised memory access.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
These were renamed from bfd_read and bfd_write back in 2001 when they
lost an unnecessary parameter. Rename them back, and get rid of a few
casts that are only needed without prototyped functions (K&R C).
|
|
When building gdb with -O2 -fsanitize-threads, I ran into
a Werror=stringop-truncation.
The problem is here in coff_getfilename in coffread.c:
...
strncpy (buffer, aux_entry->x_file.x_n.x_fname, FILNMLEN);
buffer[FILNMLEN] = '\0';
...
The constant FILNMLEN is expected to designate the size of
aux_entry->x_file.x_n.x_fname, but that's no longer the case since commit
60ebc257517 ("Fixes a buffer overflow when compiling assembler for the MinGW
targets.").
Fix this by using "sizeof (aux_entry->x_file.x_n.x_fname)" instead.
Likewise in xcoffread.c.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/30669
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30669
|
|
After the commit:
commit 6647f05df023b63bbe056e9167e9e234172fa2ca
Date: Tue Jan 24 18:13:38 2023 +0100
gdb: defer warnings when loading separate debug files
It was pointed out[1] that the warnings being deferred and then later
emitted lacked styling. The warnings lacked styling before the above
commit, but it was suggested that the filenames in these warnings
should be styled, and this commit does this.
There were a couple of previous attempts[2][3][4] to solve this
problem, but these all tried to extend the mechanism introduced in the
above commit, the deferred warnings were placed directly into a
std::vector, but now we tried to, when appropriate, style these
warnings. The review feedback that this approach looked too complex.
So instead, this revision adds a new helper class 'deferred_warnings'
which can be used to collect a set of deferred warnings, and then emit
these deferred warnings later, if needed. This helper class hides the
complexity, so at the point the deferred warning is created no extra
logic is required.
The deferred_warnings class will style the deferred warnings only if
gdb_stderr supports styling. GDB's warnings are sent to gdb_stderr,
so this should ensure we only style when expected.
There was also review feedback[5] that all of the warnings should be
bundled into a single string_file, this has not been done. I feel
pretty strongly that separate warnings should be emitted using
separate "warning" calls. If we do end up with multiple warnings in
this case they aren't really related, one will be about looking up
debug via .gnu_debuglink, while the other will be about build-id based
lookup. So I'd really rather keep the warnings separate.
[1] https://inbox.sourceware.org/gdb-patches/87edr9pcku.fsf@tromey.com/
[2] https://inbox.sourceware.org/gdb-patches/20230216195604.2685177-1-ahajkova@redhat.com/
[3] https://inbox.sourceware.org/gdb-patches/20230217123547.2737612-1-ahajkova@redhat.com/
[4] https://inbox.sourceware.org/gdb-patches/20230320145638.1202335-1-ahajkova@redhat.com/
[5] https://inbox.sourceware.org/gdb-patches/87o7nh1g8h.fsf@tromey.com/
Co-Authored-By: Alexandra Hájková <ahajkova@redhat.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes minimal symbols to use unrelocated_addr. I believe this
detected a latent bug in add_pe_forwarded_sym.
|
|
long is a poor choice of type to store 32-bit values read from
objects files by H_GET_32. H_GET_32 doesn't sign extend so tests like
that in gdb/coffread.c for "negative" values won't work if long is
larger than 32 bits. If long is 32-bit then code needs to be careful
to not accidentally index negative array elements. (I'd rather see a
segfault on an unmapped 4G array index than silently reading bogus
data.) long is also a poor choice for x_sect.s_scnlen, which might
have 64-bit values. It's better to use unsigned exact width types to
avoid surprises.
I decided to change the field names too, which makes most of this
patch simply renaming. Besides that there are a few places where
casts are no longer needed, and where printf format strings or tests
need adjusting.
include/
* coff/internal.h (union internal_auxent): Use unsigned stdint
types. Rename l fields to u32 and u64 as appropriate.
bfd/
* coff-bfd.c,
* coff-rs6000.c,
* coff64-rs6000.c,
* coffcode.h,
* coffgen.c,
* cofflink.c,
* coffswap.h,
* peXXigen.c,
* xcofflink.c: Adjust to suit internal_auxent changes.
binutils/
* rdcoff.c: Adjust to suit internal_auxent changes.
gas/
* config/obj-coff.h,
* config/tc-ppc.c: Adjust to suit internal_auxent changes.
gdb/
* coffread.c,
* xcoffread.c: Adjust to suit internal_auxent changes.
ld/
* pe-dll.c: Adjust to suit internal_auxent changes.
|
|
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 removes alloc_type, replacing all uses with the new type
allocator.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Simon pointed out a line table regression, and after a couple of false
starts, I was able to reproduce it by hand using his instructions.
The bug is that most of the code in do_mixed_source_and_assembly uses
unrelocated addresses, but one spot does:
pc = low;
... after the text offset has been removed.
This patch fixes the problem by introducing a new type to represent
unrelocated addresses in the line table. This prevents this sort of
bug to some degree (it's still possible to manipulate a CORE_ADDR in a
bad way, this is unavoidable).
However, this did let the compiler flag a few spots in that function,
and now it's not possible to compare an unrelocated address from a
line table with an ordinary CORE_ADDR.
Regression tested on x86-64 Fedora 36, though note this setup never
reproduced the bug in the first place. I also tested it by hand on
the disasm-optim test program.
|
|
This changes linetables to not add the text offset to the addresses
they contain. I did this in a few steps, necessarily combined
together in one patch: I renamed the 'pc' member to 'm_pc', added the
appropriate accessors, and then recompiled. Then I fixed all the
errors. Where possible I generally chose to use the raw_pc accessor,
as it is less expensive.
Note that this patch discounts the possibility that the text section
offset might cause wraparound in the addresses in the line table.
However, this was already discounted -- in particular,
objfile_relocate1 did not re-sort the table in this scenario. (There
was a bug open about this, but as far as I can tell this has never
happened, it's not even clear what inspired that bug.)
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
OBJF_REORDERED is set for nearly every object format. And, despite
the ominous warnings here and there, it does not seem very expensive.
This patch removes the flag entirely.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
This removes ALL_BLOCK_SYMBOLS in favor of foreach.
|
|
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.
|
|
Currently, when GDB loads debug information from a separate debug
file, there are a couple of warnings that could be produced if things
go wrong.
In find_separate_debug_file_by_buildid (build-id.c) GDB can give a
warning if the separate debug file doesn't include any actual debug
information, and in separate_debug_file_exists (symfile.c) we can warn
if the CRC checksum in the separate debug file doesn't match the
checksum in the original executable.
The problem here is that, when looking up debug information, GDB will
try several different approaches, lookup by build-id, lookup by
debug-link, and then a lookup from debuginfod. GDB can potentially
give a warning from an earlier attempt, and then succeed with a later
attempt. In the cases I have run into this is primarily a warning
about some out of date debug information on my machine, but then GDB
finds the correct information using debuginfod. This can be confusing
to a user, they will see warnings from GDB when really everything is
working just fine.
For example:
warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug" \
does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
This diagnostic was printed on Fedora 33 even when the correct
debuginfo was downloaded.
In this patch I propose that we defer any warnings related to looking
up debug information from a separate debug file. If any of the
approaches are successful then GDB will not print any of the warnings.
As far as the user is concerned, everything "just worked". Only if
GDB completely fails to find any suitable debug information will the
warnings be printed.
The crc_mismatch test compiles two executables: crc_mismatch and
crc_mismatch-2 and then strips them of debuginfo creating separate
debug files. The test then replaces crc_mismatch-2.debug with
crc_mismatch.debug to trigger "CRC mismatch" warning. A local
debuginfod server is setup to supply the correct debug file, now when
GDB looks up the debug info no warning is given.
The build-id-no-debug-warning.exp is similar to the previous test. It
triggers the "separate debug info file has no debug info" warning by
replacing the build-id based .debug file with the stripped binary and
then loading it to GDB. It then also sets up local debuginfod server
with the correct debug file to download to make sure no warnings are
emitted.
|
|
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.
|
|
Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:
internal_error (__FILE__, __LINE__, "foo %d", var);
The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability. We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.
So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.
The result is that we now should call internal_error like so:
internal_error ("foo %d", var);
Likewise for internal_warning.
The patch adjusts all calls sites. 99% of the adjustments were done
with a perl/sed script.
The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
|
|
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
|
|
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.
|
|
"struct find_targ_sec_arg" is defined in multiple .c files, causing
ODR warnings. This patch renames the types.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
|
|
This changes coffread.c to avoid re-reading minimal symbols when
possible. This only works when there are no COFF symbols to be read,
but at least for my mingw builds of gdb, this seems to be the case.
Tested using the AdaCore internal test suite on Windows. I also did
some local builds to ensure that no warnings crept in.
|
|
Replace with calls to blockvector::blocks, and the appropriate method
call on the returned array_view.
Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
|
|
Internally we noticed that some tests would fail like so on Windows:
warning: Section .debug_aranges in [...] has duplicate debug_info_offset 0x0, ignoring .debug_aranges.
Debugging showed that, in fact, a second CU was being created at this
offset. We tracked this down to the fact that, while the ELF reader
is careful to re-use the per-BFD data, other readers are not, and
could re-read the DWARF data multiple times.
However, since the change to allow an objfile to have multiple "quick
symbol" implementations, there's no reason for this approach -- it's
safe and easy for all symbol readers to reuse the per-BFD data when
reading DWARF.
This patch implements this idea, simplifying dwarf2_build_psymtabs and
making it private, and then switching to dwarf2_initialize_objfile as
the sole way to start the DWARF reader.
Note that, while I think the call to dwarf2_build_frame_info in
machoread.c is also obsolete, I haven't attempted to remove it here.
|
|
Add a getter and a setter for a minimal symbol's type. Remove the
corresponding macro and adjust all callers.
Change-Id: I89900df5ffa5687133fe1a16b2e0d4684e67a77d
|
|
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
|
|
symtab::blockvector is a wrapper around compunit_symtab::blockvector.
It is a bit misleadnig, as it gives the impression that a symtab has a
blockvector. Remove it, change all users to fetch the blockvector
through the compunit instead.
Change-Id: Ibd062cd7926112a60d52899dff9224591cbdeebf
|
|
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
|
|
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 whether a symbol is an argument. Remove
the corresponding macro and adjust all callers.
Change-Id: I71b4f0465f3dfd2ed8b9e140bd3f7d5eb8d9ee81
|
|
Add a getter and a setter for a symbol's domain. Remove the
corresponding macro and adjust all callers.
Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
|
|
Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
|
