In DWARF CFI an "undefined" register rule for the return address (RA)
register indicates that there is no return address and the stack trace
is complete.
Represent DW_CFA_undefined as SFrame FRE without any offsets, so that a
stack tracer implementation can use this as indication that an outermost
frame has been reached and the stack trace is complete.
This representation is backward compatible, as existing stack tracers
should already deal with the case, that an SFrame FRE a so far invalid
offset count of zero and stop the trace.
include/
* sframe.h (SFRAME_V2_FRE_RA_UNDEFINED_P): New macro to test
FRE info word for RA undefined (FRE without any offsets).
binutils/
* NEWS: Mention SFrame can represent an undefined RA as FRE
without any offsets.
gas/
* gen-sframe.h (struct sframe_row_entry): Add ra_undefined_p
flag.
* gen-sframe.c (sframe_row_entry_new): Initialize ra_undefined_p
flag to not set.
(sframe_row_entry_initialize): Treat ra_undefined_p flag as
sticky.
(sframe_fre_set_ra_track): Reset ra_undefined_p flag.
(sframe_xlate_do_restore): Reset ra_undefined_p flag to saved
state.
(sframe_xlate_do_same_value): Reset ra_undefined_p flag.
(sframe_xlate_do_cfi_undefined): For RA set ra_undefined_p flag.
(output_sframe_row_entry): Represent RA undefined as SFrame FRE
without any offsets and FRE info word fields zeroed.
* NEWS: Mention assembler represents .cfi_undefined RA in SFrame
as FRE without any offsets.
libsframe/
* doc/sframe-spec.texi (Changes from Version 1 to Version 2):
Mention that a SFrame FRE without any offsets flag indicates an
outermost frame with an undefined RA.
(fre_offset_count): Document that a FRE offset count of zero
indicates an outermost frame with an undefined RA.
* sframe.c (sframe_get_fre_ra_undefined_p): Use macro
SFRAME_V2_FRE_RA_UNDEFINED_P.
(sframe_fre_get_fp_offset, sframe_fre_get_ra_offset): Do not
return fixed FP/RA offset if RA undefined.
* sframe-dump.c (dump_sframe_func_with_fres): Show FRE without
any offsets as "RA undefined".
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp: Run tests for .cfi_undefined RA
on AArch64, s390x, and x86-64.
* gas/cfi-sframe/cfi-sframe-aarch64-ra-undefined-1.d: Add test
for .cfi_undefined RA on AArch64.
* gas/cfi-sframe/cfi-sframe-aarch64-ra-undefined-1.s: Likewise.
* as/cfi-sframe/cfi-sframe-s390x-ra-undefined-1.d: Add test
for .cfi_undefined RA on s390x.
* gas/cfi-sframe/cfi-sframe-s390x-ra-undefined-1.s: Likewise.
* gas/cfi-sframe/cfi-sframe-x86_64-ra-undefined-1.d: Add test
for .cfi_undefined RA on x86-64.
* gas/cfi-sframe/cfi-sframe-x86_64-ra-undefined-1.s: Likewise.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
SFrame FREs without any offsets will later be used to represent an
undefined return address (RA) in SFrame. This API can then be used,
for instance by libsframe when dumping SFrame stack trace information
(e.g. in objdump and readelf), to test for RA undefined. Other users
of libsframe need the same capability.
include/
* sframe-api.h (sframe_fre_get_ra_undefined_p): New declaration.
libsframe/
* libsframe.ver (sframe_fre_get_ra_undefined_p): List new API.
* sframe.c (sframe_fre_get_ra_undefined_p): New definition.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
SFrame FREs without any offsets will later be used to represent
.cfi_undefined RA in SFrame.
As a result the API to get the CFA offset can return an error value, if
there are no offsets. Do not apply the s390x-specific decoding of CFA
offset on the error return value.
libsframe/
* sframe.c (sframe_fre_get_cfa_offset): Do not apply s390x-
specific decoding to error return value.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Allow SFrame sections without any FREs, that can occur if they solely
contain FDEs without any FREs. For FDEs without and FREs set the
offset to the first FRE to zero.
libsframe/
* sframe.c (sframe_encoder_write_sframe): Allow SFrame sections
without any FREs. For FDEs without any FREs set the offset to
the first FRE to zero.
gas/
* gen-sframe.c (output_sframe_funcdesc): For FDEs without any
FREs set the offset to the first FRE to zero.
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Today, GDB links against the Python library using the unstable API. This
approach causes portability issues of the generated GDB artifact. Indeed
the built artifact is tighly coupled with the specific version of Python
that it was compiled with. Using a slighly minor version of Python can
cause unpredictable crashes at runtime due to ABI instability between
the Python versions, even minor ones.
The solution would consist in restricting the usage of Python functions
to the limited C API controlled via Py_LIMITED_API that must be defined
before the inclusion of <Python.h>.
This patch does not aim at porting the whole GDB codebase to the Python
limited C API, but rather enabling a development mode where developers
can experiment with the Python limited C API, and fix issues.
This development mode is accessible with the configure option
--enable-py-limited-api which is set by default to 'no'.
Note: the version of the Python limited API is currently set to 3.11
because of PyBuffer_FillInfo and PyBuffer_Release. This choice is not
frozen, and could be reviewed later on depending on newly discovered
issues during the migration.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830
Approved-By: Tom Tromey <tom@tromey.com>
The current test to check the support of '--dynamic-list' linker flag
uses PyRun_SimpleString (), which is part of the unstable API. As it is
now, the test will systematically fail due to the undefined symbol
rather than testing the import of ctypes.
This patch replaces PyRun_SimpleString () by an equivalent code relying
on the limited C API, and compatible with Python 3.4.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830
Approved-By: Tom Tromey <tom@tromey.com>
Return an optional, instead of a bool + the actual value by parameter.
I think this makes it a bit easier to understand what's going on.
Change-Id: Idf65f4a026cab6eebfb81c4efda406aeb65d0813
Approved-By: Tom Tromey <tom@tromey.com>
Change the `sal` parameter of add_sal_to_sals to be a reference. This
will make things a bit cleaner in a following patch (and it would be a
good change on its own anyway).
Change the `sals` parameter to a reference as well, while at it, which
trickles up to minsym_found.
Change-Id: I348414308940c14fa6030bc41c52f507aa6d1c12
Approved-By: Tom Tromey <tom@tromey.com>
create_sals_line_offset uses a symtab_and_line essentially just to hold
a line number and pass it down to decode_digits_list_mode. Change the
local variable to be an int, and change decode_digits_list_mode to
accept an int, instead of a symtab_and_line. I think this makes the
code a bit simpler.
Change-Id: I445d2473f042693c3a4f2693877408f85100cd1f
Approved-By: Tom Tromey <tom@tromey.com>
I'm currently looking at this function, and think it makes it easier to
process if the variables are declared when actually used.
I turned one while loop into a for, in order to be able to declare the
loop variable in the for loop.
Change-Id: I70258a94f39acb3d56e5b8e85cdfadc2f7687bc4
Approved-By: Tom Tromey <tom@tromey.com>
I'm currently looking at this function, and think it makes it easier to
process if the variables are declared when actually used.
Change-Id: Ie950fc3a7241e55e66ae96a578f79df3a9b45c69
Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries noticed that with .gdb_index, the "main" marker would
sometimes seemingly be ignored.
I tracked this down to an interaction between the rewritten reader and
the "main"-finding code in cooked_index. With the ordinary DWARF
scanner, a C "main" won't be marked as IS_MAIN; whereas with
.gdb_index this can happen. In this case, the code thinks that C
requires canonicalization (which is only true for types), and skips
using the symbol.
This patch fixes the problem and adds some comments explaining what is
going on.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33441
On riscv64-linux, I ran into:
...
(gdb) print the_array.all^M
Cannot access memory at address 0x0^M
(gdb) FAIL: gdb.ada/extended-access.exp: print the_array.all
...
The problem is that the_array.p_array is set by a dynamic relocation:
...
0000000000002010 <array_data>:
...
0000000000002028 <the_array>:
...
2028: R_RISCV_RELATIVE *ABS*+0x2010
...
which doesn't seem to get its value until we arrive in main.
Fix this by running to main before trying to print the_array.
Tested on riscv64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
On ppc64-linux (debian 14) I run into:
...
(gdb) print p_record^M
$1 = (kind => five, i => <error reading variable: \
access outside bounds of object>^M
(gdb) gdb_do_cache: get_compiler_info_1 ( c )
get_compiler_info: gcc-15-2-0
gdb_do_cache: get_compiler_info_1 ( c )
FAIL: gdb.ada/variant_record_field.exp: print p_record
...
The test-case contains an xfail for "[gcc_major_version] <= 14", which doesn't
trigger because gcc has version 15.2.0, while gnatmake does have version
14.3.0:
...
$ gcc --version
gcc (Debian 15.2.0-4) 15.2.0
...
$ gnatmake --version
GNATMAKE 14.3.0
...
Fix this by using "[gnat_version_compare < 15]" instead.
Tested on ppc64-linux and x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
A recent refactor (fc8e5a565b -- gdb: make structured core file
mappings processing global) in gdb/corelow.c:gdb_read_core_file_mappings
introduced a use-after-free bug detected by address sanitizer.
In this change, a cache is built which holds addresses to elements of a
std::vector. However, as elements as inserted in the vector, the
addresses in the cache should be invalidated, but are not, leading to
the use-after-free issue.
This patch proposes to store the index in the vector in the cache
instead of the address of the element, solving the invalidation issue.
An alternative approach could be to use a std::list which does not need
invalidation of addresses/references/iterators as the container is
grown.
Change-Id: Ib57d87c5d0405ffa3b7d38557fb33f7283c5d063
Approved-By: Andrew Burgess <aburgess@redhat.com>
Following commit 1ad8737b3c ("gdb: change inf_threads_iterator to yield
references"), we're running into a build breaker on x86_64-freebsd, in
gdb/fbsd-nat.c.
Fix this.
Tested by completing a build on x86_64-freebsd and running the TUI test-cases.
When running test-case gdb.tui/corefile-run.exp on x86_64-freebsd, we run into
PR tdep/33176:
...
PASS: gdb.tui/corefile-run.exp: load corefile
run<SNIP>gdb/fbsd-nat.c:1381: internal-error: wait_1: \
Assertion `fbsd_inf != nullptr || pl.pl_flags & PL_FLAG_CHILD' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
ERROR: FIXME scroll
...
Skip the ERROR by:
- running the test-case twice, once with CLI and once with TUI, and
- only running the TUI variant if the CLI one succeeds.
While we're at it, add a KFAIL for the PR.
Tested on x86_64-freebsd and x86_64-linux.
The recent patch to heap-allocate compunit_symtabs introduced a
use-after-free that can occur when destroying an objfile. The bug
here is that the objfile obstack is destroyed before compunit_symtabs;
but the compunit_symtabs destructor refers to the symtabs, which are
allocated on the obstack.
This patch fixes the problem. This was reported using ASAN, but I
reproduced it with valgrind and verified that this fixes the problem.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33435
Support for ECOFF MIPS targets, including `mips*-*-pe*' among others,
has been removed from GAS and LD with commit e8044f355d ("Remove gas
and ld support for MIPS ECOFF"),
<https://inbox.sourceware.org/binutils/8761x65bzx.fsf@talisman.default/>.
However bits in PEI-format DLL support code have been left behind.
Remove the relevant pieces then, originally from commit 344a211f99
("Add support for WinCE based toolchains."), including MIPS architecture
parts and HIGHADJ relocation support in particular. Retain code for LOW
relocation however, even though included with said commit, as it remains
usable by ARM, i386 and x86-64 targets.
Add test cases for LOW, HIGHLOW, and DIR64 relocations handled by code
being modified. The MCore target currently fails to produce a .reloc
image section owing to missing support, so XFAIL the HIGHLOW test.
Convert internal PE architecture identifiers from macros to enumeration
constants so as to make any further updates less disruptive to code.
Add a PE_ARCH_none dummy placeholder so as to start the numbering of
actual architectures from 1 without the need to specify the numeric
value for any of the constants.
No functional change. Suggested by Richard Earnshaw.
Recent commit c1950dcc04 ("gdb/testsuite: fix failure from
gdb.python/py-corefile.exp") introduced proc expect_build_id_in_core_file,
which detects the problem that:
...
... some versions of the linker didn't place the build-id within the first
page of an ELF. As a result, the Linux kernel would not include the
build-id in the generated core file, ...
...
Use this proc in a few more test-cases, to deal with the same problem.
Tested on x86_64-linux, openSUSE Tumbleweed with ld 2.43.1.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR testsuite/33528
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33528
This changes the compunit_symtab iterator to return references rather
than pointers, following the style of some other recent changes.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Now that compunit_symtab can have a destructor, it can use
std::unique_ptr rather than an explicit 'delete'.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
This patch changes compunit_symtab to be allocated on the heap, using
'new'. It also changes the container that holds these in the objfile.
I chose to use an intrusive_list to store compunit_symtab because I
think pointer stability is needed here.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33435
Approved-By: Simon Marchi <simon.marchi@efficios.com>
All 2 callers of this overload pass NULL. Remove the parameter and pass
nullptr explicitly to find_function_start_sal_1.
Change-Id: Ie20e7c8ad980cd7af99b6ba9c23f4da19febc1bc
While working on new Python API to create new function types I realized
that there's no easy way to create a new function type and control where
it is going to be allocated (whether in gdbarch's obstack or objfile's).
Functions lookup_function_type and lookup_function_type_with_arguments
always allocate at the same obstack as its return type.
This is not sufficient for the new Python API - the user may use any
type it can get hold of. For example, one may want to create a function
returning arch-owned type and taking one argument of objfile-owned type.
In that case we need to allocate the new type on that very objfile's
obstack.
This commit introduces new function - create_function_type - that takes
type_allocator as first parameter, allowing caller to control the
allocation. Existing functions (lookup_function_type and
lookup_function_type_with_arguments) are reimplemented by means of new
create_function_type.
Approved-By: Tom Tromey <tom@tromey.com>
... and const. There's no reason to have the compiler copy an anonymous
.rodata object onto the stack. And there's also no reason to allow the
array to be modifiable.
While in the common case sections like .reloc don't need to be accessed
by a binary (that's the job of the loader), there are rare cases where
the situation is different. Unconditionally forcing the discardable flag
is therefore unhelpful. Avoid doing so when SEC_ALLOC is set, which
would in particular be the case when .reloc isn't (solely) linker-
generated.
While adjusting the comment, drop the wrong (stale?) following sentence:
.rsrc, as per its table entry, doesn't need to be writable. And
commenting on it wanting to be readable would then need to be repeated
for all other sections as well.
Without SEC_READONLY, even the default .text section would end up with
the IMAGE_SCN_MEM_WRITE flag, which is clearly wrong. (Afaict the flag,
oddly enough, doesn't affect the final linked binary, so there likely
are more anomalies.)
However, as suggested by Richard Earnshaw, PE's requirements are really
target independent. Consolidate SEC_CODE, SEC_DATA, SEC_READONLY,
SEC_LINK_ONCE, and SEC_LINK_DUPLICATES into target-independent code. Yet
of course targets not using CREATE_*_COFF_TARGET_VEC() won't benefit.
Note that in coff-arm.c the EXTRA_S_FLAGS conditional was also stale
(leftover from EPOC removal), and hence can go away.
This is once again just so the target won't need excluding in a
forthcoming new testcase, which requires no padding at the end of at
least some of the sections.
Even when !DLL_SUPPORT, an executable may still want to have base
relocations created. Avoid doing so by default, though, to not alter
prior behavior.
With this, an xfail can (and actually should) go away (or else we end up
with an XPASS).
M*Core uses pe-dll.c, but has no entry in the table. Add both big and
little endian ones. Many of the entries aren't relevant when targeting
PE+; move the #endif accordingly. The MIPS entry is actually
questionable altogether: No mips*-*-* target uses pe-dll.c or pep-dll.c.
As I lack sufficient knowledge of the target, introduction of
jmp_mcore_bytes[] will need to be handled by someone else.
This is just so the target won't need excluding in a forthcoming new
testcase. Without doing so objdump would fail saying "option -P/--private
not supported by this file".
_bfd_XXi_swap_scnhdr_out() will want to use the section's flags. Some
call sites don't have a BFD section available, and hence pass NULL. Code
using the parameter will therefore need to apply appropriate care.
Before teaching _bfd_XXi_swap_scnhdr_out() to respect SEC_ALLOC when
considering whether to force IMAGE_SCN_MEM_DISCARDABLE for a section,
make sure we won't "invert" present wrong behavior when transforming an
incoming object's section attributes to an outgoing one's (objcopy or
"ld -r"): Right now, IMAGE_SCN_MEM_DISCARDABLE would appear out of the
blue for certain sections. We don't want the opposite, though, i.e. we
want avoid silently dropping IMAGE_SCN_MEM_DISCARDABLE when it's present
for an incoming object's section.
In line with bfd's styp_to_sec_flags(), set SEC_ALLOC for code/data
sections. Tie the setting to SEC_LOAD, not avoid inadvertently producing
a .bss-like section.
Both really want to be SEC_DATA, even if _bfd_XXi_swap_scnhdr_out()
makes sure that IMAGE_SCN_CNT_INITIALIZED_DATA is set in the final
section header. Otoh, .reloc - being IMAGE_SCN_MEM_DISCARDABLE at least
by default - shouldn't have SEC_ALLOC set.
In an early form of the patch I also dropped SEC_ALLOC for .reloc. While
I've undone that, I think the then necessary testsuite adjustments still
want retaining:
1) I can't explain why the removal of _both_ SEC_ALLOC and SEC_LOAD for
.reloc causes ld-scripts/provide-8 to XPASS on PE targets. Placing a
symbol outside of the image isn't well-defined in PE anyway though, so
convert the xfail-s to notarget-s.
2) The ld-pe/pe-aarch64 fragility is now dealt with in a separate patch.
Recently AIX internal CI is broken.
The error is as follows:
--------------------------------
aix-thread.c: In function 'void sync_threadlists(pid_t)':
aix-thread.c:857:53: error: cannot convert 'thread_info' to 'thread_info*' in initialization
857 | for (struct thread_info *it : all_threads_safe ())
| ^
aix-thread.c: In lambda function:
aix-thread.c:899:61: warning: declaration of 'thread' shadows a previous local [-Wshadow=compatible-local]
899 | thread = iterate_over_threads ([&] (struct thread_info *thread)
----------------------------------
This patch is similar to the commit https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceware.org_git_-3Fp-3Dbinutils-2Dgdb.git-3Ba-3Dcommitdiff-3Bh-3D675a17a8a5cde1d8be86536df2ae6366ef0ec759&d=DwIDAg&c=BSDicqBQBDjDI9RkVyTcHQ&r=f-oUQ8ByG1nZ71OI9p76qywCPh7mxzU69hBYnkP9Nis&m=qpgW6gyN_lC_b0fBRhcWkqlvNDmUtHBTvyqGcCZxnuN6vnvJaehZ2WVuFVicJ9oD&s=UtdzAKmXnBH1ZTFOUTmFC9vTwxxralJIDjbYWsCsLYA&e=
all_threads_safe() returns an all_threads_safe_range which is like an iterator to iterate for loops.
AIX is adjusting its code in aix-thread.c for the same.
After applying this patch,
Sample test case output:
------------
gmake check RUNTESTFLAGS='gdb.threads/thread_events.exp CC_FOR_TARGET="/opt/freeware/bin/gcc" CXX_FOR_TARGET="/opt/freeware/bin/g++" CXXFLAGS_FOR_TARGET="-O0 -w -g -gdwarf -maix64" CFLAGS_FOR_TARGET="-O0 -w -g -gdwarf -maix64"'
gmake check-single
gmake[1]: Entering directory '/upstream_gdb/binutils-gdb/gdb/testsuite'
rm -f *core* gdb.sum gdb.log
=== gdb tests ===
Schedule of variations:
unix
Running target unix
Using /opt/freeware/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /opt/freeware/share/dejagnu/config/unix.exp as generic interface file for target.
Using /upstream_gdb/binutils-gdb/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file.
Running /upstream_gdb/binutils-gdb/gdb/testsuite/gdb.threads/thread_events.exp ...
=== gdb Summary ===
/upstream_gdb/binutils-gdb/gdb/gdb version 18.0.50.20251010-git -nw -nx -q -iex "set height 0" -iex "set width 0" -data-directory /upstream_gdb/binutils-gdb/gdb/data-directory -iex "set interactive-mode on"
=== gdb Summary ===
/upstream_gdb/binutils-gdb/gdb/gdb version 18.0.50.20251010-git -nw -nx -q -iex "set height 0" -iex "set width 0" -data-directory /upstream_gdb/binutils-gdb/gdb/data-directory -iex "set interactive-mode on"
gmake[1]: Leaving directory '/upstream_gdb/binutils-gdb/gdb/testsuite'
Approved By: Ulrich Weigand <ulrich.weigand@de.ibm.com>
For one, all PadLock insns depend on CR4.FXSR to be enabled, which means
they ought to be taking FXSR as a prereq.
Furthermore none of them permits a REPNE prefix; such forms are documented
to cause #UD. (This is mainly relevant for XSTORE, which doesn't include a
REP prefix in its base encoding. For the others this merely is a change in
what diagnostic is issued.)
Finally it is documented that an operand size prefix also causes #UD.
