| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
bfd_elfNN_loongarch_set_data_segment_info can be called from the target
after_allocation function with a non-ELF hash table. This is seen in
the ld-elf pr21884 testcase. Fix the problem by first checking the
hash table type before writing to a loongarch_elf_hash_table field.
(cherry picked from commit 59ba00f21f7d48780e92a9fb66ed4abbedc3bd28)
|
|
Restores ihex get_symtab_upper_bound to what it was prior to commit
394a3f4f8d. This will enable objcopy of other no-sym formats too.
PR 32599
* libbfd-in.h (_bfd_nosymbols_get_symtab_upper_bound): Define
as _bfd_long_bfd_0.
* libbfd.h: Regenerate.
(cherry picked from commit fd45211245d0f1027a0c3ab606e3253eda779e68)
|
|
|
|
|
|
|
|
PR ld/32572
There are two problems addressed in this PR. Firstly, the choice of
whether or not a PLT stub needs a BTI on entry was too strict,
resulting in non-pie executables not having a BTI on their stub. But
secondly, the logic to handle each stub types did not agree across the
various places where this information is used.
The first issue is fixed by using bfd_link_executable rather than
bfd_link_pde. The second is addressed by recording a delta for PLT
stub alongside the stub itself. This is then used without needing
additional logic later on since it has been pre-calculated.
A more comprehensive fix would involve creating a data structure to
describe each fixup, including a call-back function to apply any
relocations. But that's a fairly large change and not appropriate for
backporting.
|
|
|
|
When pure-code option is activated. The linker creates for M-profile architecures
a 2-bytes branch instruction. This causes the section alignment to be set to 2-byte
alignment instead of 4-byte alignment. This is a problem for long branch stub
without pure-code section as it contains a 32-bit address as data, which is expected
to be 4-byte aligned. Hence creating a long branch stub for PureCode section followed
by a long branch stub will result in a misalignment for the 32-bit address.
An easy fix is to add a nop instruction after the branch to keep the section alignment
to 4 bytes.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Co-authored-by: Guillaume VACHERIAS <guillaume.vacherias@st.com>
(cherry picked from commit 014a7c0fa36ecc41918e5793052dd3ae8372efe5)
|
|
ld/
PR ld/32580
* scripttempl/elf.sc: Fix '==' bashism.
(cherry picked from commit 6999916e6c7fe6ba3a7661d852757f59223416a3)
|
|
|
|
After commit:
commit bd32be01c997f686ab0b53f0640eaa0aeb61fbd3
Date: Fri Dec 3 00:23:20 2021 -0500
bfd: merge doc subdir up a level
And the follow-up commit:
commit 98b1464bdf6306a8ab4614b5e9f76cdb2dd00b33
Date: Wed Oct 2 22:58:08 2024 +0300
bfd: fix unnecessary bfd.info regen
There is still a problem building the bfd docs from a release tar
file.
As the release tar file contains the pre-generated .texi files we
expect the bfd/doc build stage to symlink to the pre-existing .texi
files in the source tree.
However, this is still not working as expected if $(srcdir) is
relative. The problem is this line in REGEN_TEXI:
test -e $$texi || test ! -f $(srcdir)/$$texi || $(LN_S) $(srcdir)/$$texi $$texi; \
This is executed from the build/bfd/ directory, so if $(srcdir) is
relative, then this will get you from the bfd/ directory in the build
tree to the corresponding bfd/ directory in the src tree. However,
the symlink is created in the bfd/doc/ build directory. The relative
path will then fail to take you to the bfd/ directory in the src
tree.
Fix this by using $(abs_srcdir) when creating the symlink.
Approved-By: Nick Clifton <nickc@redhat.com>
|
|
PR gas/32579
The deprecated .s (swapped operand encoding) functionality got in the
way of properly recognizing this specific form. Move the Solaris-
specific code ahead of that.
|
|
I have missed @tab for .gmiccs and .padlockphe2, so fix this doc error.
gas/ChangeLog:
* doc/c-i386.texi: Add the missing @tab for .gmiccs and
.padlockphe2
|
|
|
|
On casual reading of older gcc configure scripts it might be supposed
that the test for gas string merge support tries with %progbits after
a fail on ARM with @progbits. It doesn't succeed due to a bug. So to
support building of older gcc's for ARM without users having to edit
gcc sources, add a hack to gas. The hack can disappear in a few years
when building older gcc's likely requires other work too.
I've changed the docs to reflect what we actually allow for .section
syntax prior to this patch. (No way should this hack be documented as
allowed!)
PR 32491
* config/obj-elf.c (obj_elf_section): Allow missing entsize
for ARM gcc configure bug.
* doc/as.texi: Correct syntax of ELF .section directive.
* testsuite/gas/elf/string.s,
* testsuite/gas/elf/string.d: Test it.
(cherry picked from commit 6427e777b99ec6505509a68de6d460ff772bee6a)
|
|
This allows you to specify a run_dump_test warning that may or may not
be present using
warning: (warning_text_goes_here)?
ie. the regexp matches an empty string.
(cherry picked from commit 592819f7188509713f3db6dbe6bc7d0b7e3af89e)
|
|
|
|
|
|
Delete an extra 2.44 NEWS marker that has crept in by chance.
(cherry picked from commit 17973a4feeec604307e915f1df9e5593bfd09717)
|
|
|
|
Commit af3394d97a8c5187085c0eec5fb03e8da88db5fb allowed sections
declared with "S" (SHF_STRING) to specify the entity size, but then
would warn if the entity size was omitted, as with the old syntax.
Unfortunately, since specifying the entity size is incompatible with
binutils 2.43 or earlier, this makes it impossible to specify a
strings section in source code without generating an assembly warning
(the new syntax isn't supported in older assemblers and the old syntax
generates warnings).
Nevertheless, the old code was wrong in that it did not set the entity
size at all, in contravention of the ELF specification (though to date
there are no known cases where this mattered outside of mergeable
sections).
Fix this by permitting the original syntax without a warning again,
but by defaulting the entity size to 1. This is compatible with the
most common case of strings being byte-based.
Added some tests for the various flavours of declaration that we
support.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The "of course to free outsymbols" turned out to be wrong. outsymbols
belongs to objcopy which frees them, so commit 6ca01b0bdd59 introduced
a double free.
* srec.c (srec_write_symbols): Don't free outsymbols.
* tekhex.c (tekhex_write_object_contents): Likewise.
|
|
|
|
This simplifies get_frame_unwind_table, changing it to use the
registry 'emplace' method and to pass the initialization iterators to
the constructor. This fixes a build problem on x86 -- reported by the
auto-builder -- as a side effect.
Tested-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Tom de Vries reported that some of the test for the vmov[u|a]p[s|d] were
failing. In my machine xmm3 was consistently set to 0x54, but apparently
that is different depending on the system. This commit zeroes out xmm3
at the start of the test instead.
While debugging the test failures, I also noticed an issue where the
recording wasn't saving all the required memory. That happened because
vmovs[s|d] shares its opcode with vmovap[s|d], meaning they seem to
share code paths, but the latter encodes memory modification size on
VEX.L whereas the former encodes in VEX.pp. So this commit fixed that,
and made the relevant tests more robust and complete.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32561
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
My earlier changes introduced a self-test crash. This patch fixes the
bug by introducing a new method overload into mock_mapped_index.
|
|
After some recent discussions on the mailing list, I've made some
changes to the README to (I hope) provide more clarity.
The changes I made are:
1. Removed the use of a lone 'HOST' on the configure line. I tried
this and 'configure' gave me a warning:
configure: WARNING: you should use --build, --host, --target
So I don't think this is approved practice any more. We should
encourage users to use `--host` instead.
2. Added and reworded the --host, --target, and --enable-targets
descriptions in the 'configure options' section. My goals here are
to clarify that 'cross-debugging' is really the same as 'remote
debugging', and also to make it clearer what the defaults are.
3. Added some additional text to the 'Remote debugging' section
mentioning that 'remote debugging' is basically the same as 'cross
debugging', given that we use 'cross-debugging' in the text above.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
This commit fixes an issue with the commit:
commit d3d13bf876aae425ae0eff2ab0f1af9f7da0264a
Date: Thu Apr 25 09:36:43 2024 +0100
gdb: add gdbarch method to get execution context from core file
The above commit improves GDB's ability to display inferior arguments
when opening a core file, however, if an argument includes white
space, then this is not displayed as well as it should be. For
example:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e e e e e'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
(gdb) show args
Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e".
(gdb)
Notice the 'Core was generated by ...' line. In this case it is not
clear if the "e e e e e" is a single argument containing white space,
or 5 single arguments.
But when we 'show args' it is immediately clear that this is a single
argument, as the white space is now escaped.
This problem was caused by the above commit building the argument
string itself, and failing to consider white space escaping.
This commit changes things around, first we place the arguments into
the inferior, then, to print the 'Core was generated by ...' line, we
ask the inferior for the argument string. In this way the quoting is
handled just as it is for 'show args'. The initial output is now:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f4f007af625 in raise () from /lib64/libc.so.6
(gdb)
Much better. The existing test is extended to cover this case.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
ChangeLog
2025-01-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* binutils/NEWS: Updated.
|
|
The bug was filed against gprofng-gui (https://savannah.gnu.org/bugs/?66560).
gprofng/ChangeLog
2025-01-16 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* src/Hist_data.cc (DbeInstr::mapPCtoLine): Check for null pointer.
|
|
Many FEAT_SVE2p1 instructions need to be enabled by either of two
different features (one for streaming mode, and one for non-streaming
mode). This patch adds correct gating conditions for these
instructions.
There were also a few sve2p1 instructions missing altogether, so add
those as well.
The testsuite is modified to check for all alternative enablement
conditions. In many cases this is done by adding an alternative
assembler commands to existing test files. For some SME/SME2 tests,
only some of the instructions are enabled by +sve2p1, so these are
copied into a separate test. For original SVE2p1 tests, the non-SME2p1
instructions have been moved to a separate test file.
There are also new tests for the newly added instructions. These
include a couple of fixme comments relating to bad error reporting,
which should be investigated later.
|
|
The base class mapped_index_base is no longer needed. Previously it
was used by both the .gdb_index and .debug_names readers, but the
latter now uses the cooked index instead.
This patch removes mapped_index_base, merging it into
mapped_gdb_index. Supporting code that is specific to .gdb_index is
also moved into read-gdb-index.c. This shrinks dwarf2/read.c a bit,
which is nice.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32504
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
gdb_index_unpack is not used and can be removed. The include of
extract-store-integer.h is also no longer needed by this file.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I found a number of .c files that need to include
extract-store-integer.h but that were only including it indirectly.
This patch adds the missing includes. This change enables the next
patch.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Fedora has been carrying this test since back in the Project Archer
days. A change back then caused GDB to stop being able to backtrace when
only some of the object files had debug information. Even though the
changed code never seems to have made its way into the main GDB project,
I think it makes sense to bring the test along to ensure something like
this doesn't pass unnoticed.
Co-Authored-By: Jan Kratochvil <jan@jankratochvil.net>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Sometimes, in the GDB testsuite, we want to test the ability of specific
unwinders to handle some piece of code. Usually this is done by trying
to outsmart GDB, or by coercing the compiler to remove information that
GDB would rely on. Both approaches have problems as GDB gets smarter
with time, and that compilers might differ in version and behavior, or
simply introduce new useful information. This was requested back in 2003
in PR backtrace/8434.
To improve our ability to thoroughly test GDB, this patch introduces a
new maintenance command that allows a user to disable some unwinders,
based on either the name of the unwinder or on its class. With this
change, it will now be possible for GDB to not find any frame unwinders
for a given frame, which would previously cause GDB to assert. GDB will
now check if any frame unwinder has been disabled, and if some has, it
will just error out instead of asserting.
Unwinders can be disabled or re-enabled in 3 different ways:
* Disabling/enabling all at once (using '-all').
* By specifying an unwinder class to be disabled (option '-class').
* By specifying the name of an unwinder (option '-name').
If you give no options to the command, GDB assumes the input is an
unwinder class. '-class' would make no difference if used, is just here
for completeness.
This command is meant to be used once the inferior is already at the
desired location for the test. An example session would be:
(gdb) start
Temporary breakpoint 1, main () at omp.c:17
17 func();
(gdb) maint frame-unwinder disable ARCH
(gdb) bt
\#0 main () at omp.c:17
(gdb) maint frame-unwinder enable ARCH
(gdb) cont
Continuing.
This commit is a more generic version of commit 3c3bb0580be0,
and so, based on the final paragraph of the commit message:
gdb: Add switch to disable DWARF stack unwinders
<...>
If in the future we find ourselves adding more switches to disable
different unwinders, then we should probably move to a more generic
solution, and remove this patch.
this patch also reverts 3c3bb0580be0
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8434
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
temp adding completion
|
|
Frame unwinders have historically been a structure populated with
callback pointers, so that architectures (or other specific unwinders)
could install their own way to handle the inferior. However, since
moving to C++, we could use polymorphism to get the same functionality
in a more readable way. Polymorphism also makes it simpler to add new
functionality to all frame unwinders, since all that's required is
adding it to the base class.
As part of the changes to add support to disabling frame unwinders,
this commit makes the first baby step in using polymorphism for the
frame unwinders, by making frame_unwind a virtual class, and adds a
couple of new classes. The main class added is frame_unwind_legacy,
which works the same as the previous structs, using function pointers
as callbacks. This class was added to allow the transition to happen
piecemeal. New unwinders should instead follow the lead of the other
classes implemented.
2 of the others, frame_unwind_python and frame_unwind_trampoline, were added
because it seemed simpler at the moment to do that instead of reworking
the dynamic allocation to work with the legacy class, and can be used as
an example to future implementations.
Finally, the cygwin unwinder was converted to a class since it was most
of the way there already.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
