Commit 1dfd89c739 (gdb: Remove stabs support from XCOFF inferiors) removed STABS handling from xcoffread.c.
While removing full symtab and compunit_symtab construction is appropriate when DWARF is available,
the change also removed recording of minimal symbols, which still provide value for XCOFF binaries that lack DWARF.
On AIX, system libraries such as libc and libpthread are built with STABS debug information up to AIX 7.3 TL4.
As a result, current GDB master is unable to record even minimal symbols for these libraries, leading to missing function names (e.g. printf) in common debugging scenarios.
Consider the example below,
int g_in_lib = 777;
int lib_func() {
return g_in_lib + 1;
}
int lib_func();
int main() {
printf ("lib_func() = %d \n", lib_func());
return 0;
}
We build libx and then link it to main.
When we compile this in GDB in AIX today in master branch we get,
Reading symbols from //gdb_tests/main...
(gdb) b main
Breakpoint 1 at 0x10000530: file //gdb_tests/main.c, line 5.
(gdb) r
Starting program: /gdb_tests/main
Breakpoint 1, main () at //gdb_tests/main.c:5
5 printf ("lib_func() = %d \n", lib_func());
(gdb) call printf()
No symbol "printf" in current context.
(gdb)
The issue is Without minimal symbols:
- Functions from system libraries are not visible in backtraces.
- Calls such as call printf() fail with no symbol in current context.
- This affects not only stepping, but also basic usability of backtraces on AIX systems without DWARF-enabled system libraries.
- Even when full debug information is unavailable, minimal symbols are still sufficient to:
- Identify function entry/exit points.
- Display meaningful backtraces involving system libraries.
This patch restores recording of minimal symbols in xcoffread.c, while keeping the removal of:
- STABS-based symtabs
- compunit_symtabs
The below function (read_xcoff_minimal_symbols) ensures that:
- record_minimal_symbol() is still invoked where appropriate.
- No attempt is made to rebuild full debug information from STABS.
- DWARF remains the sole source for full debugging information when available.
This keeps the original intent of the STABS removal intact, while restoring essential functionality for non-DWARF XCOFF binaries.
After applying the patch we get,
GNU gdb (GDB) 18.0.50.20260316-git
Copyright (C) 2026 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-ibm-aix7.2.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
+------------------------------------------------------------------------------+
| Find the GDB manual online at: |
| http://www.gnu.org/software/gdb/documentation/. |
| For help, type "help". |
| Type "apropos word" to search for commands related to "word". |
+------------------------------------------------------------------------------+
Reading symbols from //gdb_tests/main...
(gdb) b main
Breakpoint 1 at 0x10000530: file //gdb_tests/main.c, line 5.
(gdb) n
The program is not being run.
(gdb) r
Starting program: /gdb_tests/main
Breakpoint 1, main () at //gdb_tests/main.c:5
5 printf ("lib_func() = %d \n", lib_func());
(gdb) call (int)printf ("lib_func() = %d \n", lib_func())
lib_func() = 778
$1 = 18
(gdb)
Approved-By: Tom Tromey <tom@tromey.com>
Replace all occurrences of:
strcmp (...) == 0
strcmp (...) != 0
!strcmp (...)
0 == strcmp (...)
strcmp (...) directly used as a boolean predicate
with the equivalent expression using streq.
This is for consistency (we already use streq as some places in the
testsuite) but also for clarity. I think that streq is clearer on the
intent than strcmp. It's also a bit shorter.
Change-Id: Ibbf5261b1872c240bc0c982c147f6a5477275a91
Approved-By: Andrew Burgess <aburgess@redhat.com>
Do a few cleanups:
- declaring variables where they are used
- rename functions to be more precise
- add explicit comparison against nullptr or 0
- remove struct/union keywords
- remove or update outdated comments
Change-Id: I3f9e8604f79ee4d36cbe3d65079cb23051fcc703
Approved-By: Tom Tromey <tom@tromey.com>
Replace these 2 switches that have only one case with a single if
statement. It is highly unlikely that we'll ever need to check for
other values.
Change-Id: I6a48d4f27ba4d1d128aaa39d5f3d693a11e99fc9
Approved-By: Tom Tromey <tom@tromey.com>
The only remaining caller of xcoff_secnum_to_sections doesn't care about
the section index in the objfile, so remove that part.
Return the BFD section as the return value of the function, instead of
an output parameter. Remove the unnecessary default in the switch, to
avoid a "jump to label over variable initialization" warning.
Rename to xcoff_secnum_to_section (singular).
Change-Id: I464d8b0e1425ea2732b0d61355c5b0c66218122e
Approved-By: Tom Tromey <tom@tromey.com>
The symbol table content is only needed for the duration of
scan_xcoff_symtab, so it's not necessary to allocate it on the objfile
obstack. Switch to using a vector that is freed at the end of the
function.
Change-Id: Ib5acdea460969300a92816a3e71b7d82c80faebf
Approved-By: Tom Tromey <tom@tromey.com>
It is not necessary to save the symbol table content and number of
symbols in xcoff_symfile_info, because they are only needed for the
duration of scan_xcoff_symtab.
Move the reading of the symbol table content to scan_xcoff_symtab, and
keep everything as local variables.
Change-Id: I21e2b95a0b8df2255ba46904083658a4e8cb89f0
Approved-By: Tom Tromey <tom@tromey.com>
It is no longer necessary to get names of symbols. The only thing we
are interested in is the symbol to get the TOC offset, for which the
name doesn't matter.
Change-Id: I47e6009ed7600ea9c412fb25ed21a295cd0fec49
Approved-By: Tom Tromey <tom@tromey.com>
Inspection shows that xcoff_symfile_info::min_lineno_offset and
xcoff_symfile_info::max_lineno_offset are never really used. Removing
this then shows that find_linenos doesn't do any useful work. So,
remove the fields and this function.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The last user of sym_fns::sym_read_linetable was xcoffread.c. Now
that the code there has been removed, this callback can be removed as
well. This slightly simplifies buildsym.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
sym_finish::sym_finish isn't needed by any existing code, so this
patch removes it.
Note that it should never be needed again. It's much cleaner, IMO,
for symbol readers to attach data to the objfile or per-BFD via the
registry. Then, any cleanup will be automatic.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
sym_fns::sym_new_init has long been weird. There's even a comment in
symfile.c saying this.
After some recent changes, nothing needs this any more. So, this
patch removes it entirely.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
xcoffread.c is no longer really using the buildsym code. This removes
the last call, which should not be needed, and then removes the
include.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This removes a lot of obviously dead code from xcoffread.c. There are
some unused macros and types. A few globals can be removed because
they are never assigned to or really used for anything.
Co-authored-by: Simon Marchi <simon.marchi@polymtl.ca>
Closes https://sourceware.org/bugzilla/show_bug.cgi?id=33606
This is a patch to bring back certain XCOFF reading sections back to the GDB code which was removed during the STABS removal.
This patch also removes the legacy line table calculation for STABS since we no longer will support it.
The issue we removed code that will get us the TOC offset in AIX.
This will now cause regressions.
For example,Consider a code where we create a simple library x as below.
int g_in_lib = 777;
int lib_func() {
return g_in_lib + 1;
}
int lib_func();
Then we use this library X in main().
int main() {
printf ("lib_func() = %d \n", lib_func());
return 0;
}
If we as of today compile master branch in AIX and try to call lib_func() from GDB we get,
GNU gdb (GDB) 18.0.50.20251112-git
Breakpoint 1, main () at //gdb_tests/main.c:5
5 printf ("lib_func() = %d \n", lib_func());
(gdb) call lib_func()
$1 = 536875277
(gdb) q
which is a garbage value instead of 778.
DWARF will not have any information about TOC to maintain uniformity with other operating system.
TOC (Table Of Contents) is a part of XCOFF/AIX ABI and is required for:
1: Loading shared libraries as we need TOC that contain pointers to access global variables and functions entry points.
2: Function calls like the above call where AIX expects register r2 = pointer to TOC which gives fast access to global data plus an ofset
3: Large code model = TOC solves the fact that PPC64 can't embed large 64 bit addresses.
So we need to get GDB to fetch this even though we only read DWARF debug sections in the XCOFF binary. (AIX uses GCC-13 now which produces only DWARF now.).
In the above case since the toc_offset is not there now we cannot access lib_func() causing the regression.
The patch right now brings back the code required to fetch the same. Once this patch is applied we get,
GNU gdb (GDB) 18.0.50.20251204-git
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "powerpc64-ibm-aix7.2.0.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
+------------------------------------------------------------------------------+
| Find the GDB manual online at: |
| http://www.gnu.org/software/gdb/documentation/. |
| For help, type "help". |
| Type "apropos <word>" to search for commands related to <word> |
+------------------------------------------------------------------------------+
..
Reading symbols from //gdb_tests/main...
(gdb) b main
Breakpoint 1 at 0x10000530: file //gdb_tests/main.c, line 5.
(gdb) r
Starting program: /gdb_tests/main
Breakpoint 1, main () at //gdb_tests/main.c:5
5 printf ("lib_func() = %d \n", lib_func());
(gdb) call lib_func()
$1 = 778
(gdb) q
A debugging session is active.
Inferior 1 [process 7340312] will be killed.
Quit anyway? (y or n) y
Also some clean ups of code and additions, they are:
1: Replaced old APIs like bfd_map_over_sections with gdb_bfd_sections() and range-based loops.
2: Used helpers like obstack_strndup instead of manual allocation like changing p = (char *) obstack_alloc (&objfile->objfile_obstack, and strncpy (p, symbol->n_name, E_SYMNMLEN);
to *name = obstack_strndup(&objfile->objfile_obstack, symbol->n_name, E_SYMNMLEN);
3: Removed unused macros as unnecessary global variables as you mentioned
4: Replaced perror_with_name with error() and bfd_errmsg. See: error(_("reading symbol table: %s"), bfd_errmsg(bfd_get_error()));
5: Also used bfd_get_section_alloc_size().
6: Eliminated the xcoff_find_targ_sec_arg struct used in GDB 17 or earlier because it is no longer necessary for context handling.
7: Eliminated the find_targ_sec () used in GDB 17 or earlier since we find the bfd_sect in xcoff_secnum_to_sections().
Approved-By: Tom Tromey <tom@tromey.com>
This updates the copyright headers to include 2026. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
This commit is the second to last in the series fully removing support
for stabs in GDB, removing it from XCOFF inferiors. According to IBM's
AIX documentation[1], xcoff binaries can only have stabs or DWARF debug
info, meaning removing stabs seems pretty trivial, as anything that
isn't related to setting base information on the objfile or reading
dwarf can be removed.
The unfortunate part of this removal is that XCOFF minimal symbols are
encoded in stabs, so if an inferior has not been compiled with dwarf
debuginfo, GDB will only be able to do assembly-level debugging. Due to
this, the xcoff reader now emits a warning if no dwarf is read, saying:
"No usable debug information found". This change would also add a lot of
regressions to to AIX, so the gdb_compile proc has been changed to not
work when a test tries to compile a test with nodebug.
As a sidenote, gdb-stabs.h can just be removed from rs6000-aix-nat, as
none of the structs or macros defined in the header are used in the nat
file, so that is an unnecessary include.
This commit introduces some known regressions when testing GDB in AIX
systems. The main ones are:
* inferior function calls now crash with a corrupted stack. This seems
to be some fault of dwarf in explaining how to correctly set the frame
for a function.
* fortran tests can't runto_main: the fortran compiler does not add any
symbol for MAIN__ in the dwarf information, only in stabs, so the
fortran_runto_main proc can't set the breakpoint correctly.
* When dealing with c++ class methods, there are cases when we fail to
properly recognize a method call as a new function.
* When dealing with c++ virtual inheritance, GDB has issues finding a
derived class's members when it has been downcast to a base class.
[1] https://www.ibm.com/docs/en/aix/7.3?topic=formats-xcoff-object-file-format
Approved-By: Tom Tromey <tom@tromey.com>
I noticed my IDE (VSCode) starting to automatically trim trailing
whitespaces on save, despite the setting for it being disabled. I
realized that this is because the .editorconfig file now has
trim_trailing_whitespace = true
for many file types. If we have this EditorConfig setting forcing
editors to trim trailing whitespaces, I think it would make sense to
clean up trailing whitespaces from our files. Otherwise, people will
always get spurious whitespace changes when editing these files.
I did a mass cleanup using this command:
$ find gdb gdbserver gdbsupport -type f \( \
-name "*.c" -o \
-name "*.h" -o \
-name "*.cc" -o \
-name "*.texi" -o \
-name "*.exp" -o \
-name "*.tcl" -o \
-name "*.py" -o \
-name "*.s" -o \
-name "*.S" -o \
-name "*.asm" -o \
-name "*.awk" -o \
-name "*.ac" -o \
-name "Makefile*" -o \
-name "*.sh" -o \
-name "*.adb" -o \
-name "*.ads" -o \
-name "*.d" -o \
-name "*.go" -o \
-name "*.F90" -o \
-name "*.f90" \
\) -exec sed -ri 's/[ \t]+$//' {} +
I then did an autotools regen, because we don't actually want to change
the Makefile and Makefile.in files that are generated.
Change-Id: I6f91b83e3b8c4dc7d5d51a2ebf60706120efe691
PR ada/33217 points out that gdb incorrectly calls the <ctype.h>
functions. In particular, gdb feels free to pass a 'char' like:
char *str = ...;
... isdigit (*str)
This is incorrect as isdigit only accepts EOF and values that can be
represented as 'unsigned char' -- that is, a cast is needed here to
avoid undefined behavior when 'char' is signed and a character in the
string might be sign-extended. (As an aside, I think this API seems
obviously bad, but unfortunately this is what the standard says, and
some systems check this.)
Rather than adding casts everywhere, this changes all the code in gdb
that uses any <ctype.h> API to instead call the corresponding c-ctype
function.
Now, c-ctype has some limitations compared to <ctype.h>. It works as
if the C locale is in effect, so in theory some non-ASCII characters
may be misclassified. This would only affect a subset of character
sets, though, and in most places I think ASCII is sufficient -- for
example the many places in gdb that check for whitespace.
Furthermore, in practice most users are using UTF-8-based locales,
where these functions aren't really informative for non-ASCII
characters anyway; see the existing workarounds in gdb/c-support.h.
Note that safe-ctype.h cannot be used because it causes conflicts with
readline.h. And, we canot poison the <ctype.h> identifiers as this
provokes errors from some libstdc++ headers.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33217
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The enum address_class and related fields and methods seem misnamed to
me. Generalize it to "location_class". The enumerators in
address_class are already prefixed with LOC, so the new name seems
logical to me. Rename related fields and methods as well.
Plus, address_class could easily be mistaken for other unrelated things
named "address class" in GDB or DWARF.
Tested by rebuilding.
Change-Id: I0dca3738df412b350715286c608041b08e9b4d82
Approved-by: Kevin Buettner <kevinb@redhat.com>
This patch introduces a new macro, INIT_GDB_FILE. This is used to
replace the current "_initialize_" idiom when introducing a per-file
initialization function. That is, rather than write:
void _initialize_something ();
void
_initialize_something ()
{
...
}
... now you would write:
INIT_GDB_FILE (something)
{
...
}
The macro handles both the declaration and definition of the function.
The point of this approach is that it makes it harder to accidentally
cause an initializer to be omitted; see commit 2711e475 ("Ensure
cooked_index_entry self-tests are run"). Specifically, the regexp now
used by make-init-c seems harder to trick.
New in v2: un-did some erroneous changes made by the script.
The bulk of this patch was written by script.
Regression tested on x86-64 Fedora 41.
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
I ran codespell on gdb/*.[chyl] and fixed a bunch of simple typos.
Most of what remains is trickier, i.e., spots where a somewhat natural
name of something in the code is flagged as a typo.
Reviewed-By: Tom de Vries <tdevries@suse.de>
Now that stabs is deprecated, we should probably warn our users of it
before removing support, so that they have time to react and either make
themselves heard, or fix things on their end so that they can still debug
their applications.
This commit adds a new function that emits a warning whenever GDB does
stabs reading. Since there are several places where stabs is
re-invented, this warning had to be added to many places, but I think I
managed to warn everywhere relevant without duplicating warnings.
Also, the test gdb.stabs/weird.exp explicitly checks for GDB warnings
when reading stabs, so it had to be updated to account for the
deprecation warning. It is done generically, since it will be removed in
the next release anyway.
Approved-By: Tom Tromey <tom@tromey.com>
Move some declarations related to the "quit" machinery from defs.h to
event-top.h. Most of the definitions associated to these declarations
are in event-top.c. The exceptions are `quit()` and `maybe_quit()`,
that are defined in utils.c. For consistency, move these two
definitions to event-top.c.
Include "event-top.h" in many files that use these things.
Change-Id: I6594f6df9047a9a480e7b9934275d186afb14378
Approved-By: Tom Tromey <tom@tromey.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>
Starting with C++17, emplace_back returns a reference to the new
object. This patch changes code that uses emplace_back followed by a
call to back() to simply use this reference instead.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
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.
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>
Given that GDB now requires a C++17, replace all uses of
gdb::string_view with std::string_view.
This change has mostly been done automatically:
- gdb::string_view -> std::string_view
- #include "gdbsupport/gdb_string_view.h" -> #include <string_view>
One things which got brought up during review is that gdb::stging_view
does support being built from "nullptr" while std::sting_view does not.
Two places are manually adjusted to account for this difference:
gdb/tui/tui-io.c:tui_getc_1 and
gdbsupport/format.h:format_piece::format_piece.
The above automatic change transformed
"gdb::to_string (const gdb::string_view &)" into
"gdb::to_string (const std::string_view &)". The various direct users
of this function are now explicitly including
"gdbsupport/gdb_string_view.h". A later patch will remove the users of
gdb::to_string.
The implementation and tests of gdb::string_view are unchanged, they will
be removed in a following patch.
Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
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>
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 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
60ebc25751 ("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
I think objfile::sections makes sense as the name of the method to
iterate over an objfile's sections, so this patch renames the existing
field to objfile::sections_start in preparation for that.
GCC 13 points out that main_subfile has local function scope, but a
pointer to it is assigned to the global inclTable array subfile
element field:
In function ‘void process_linenos(CORE_ADDR, CORE_ADDR)’,
inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:727:19,
inlined from ‘void aix_process_linenos(objfile*)’ at xcoffread.c:720:1:
xcoffread.c:629:37: error: storing the address of local variable ‘main_subfile’ in ‘*inclTable.19_45 + _28._inclTable::subfile’ [-Werror=dangling-pointer=]
629 | inclTable[ii].subfile = &main_subfile;
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~
xcoffread.c: In function ‘void aix_process_linenos(objfile*)’:
xcoffread.c:579:18: note: ‘main_subfile’ declared here
579 | struct subfile main_subfile;
| ^~~~~~~~~~~~
xcoffread.c:496:19: note: ‘inclTable’ declared here
496 | static InclTable *inclTable; /* global include table */
| ^~~~~~~~~
Fix this by making main_subfile file static. And allocate and
deallocated together with inclTable in allocate_include_entry and
xcoff_symfile_finish. Adjust the use of main_subfile in
process_linenos to take a pointer to the subfile.
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.
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.
