The recent gnulib import caused a build failure of libinproctrace.so
on PPC:
alloc.c:(.text+0x20): undefined reference to `rpl_malloc'
alloc.c:(.text+0x70): undefined reference to `rpl_realloc'
This patch fixes the problem using the same workaround that was
previously used for free.
Update
commit ebb191adac4ab45498dec0bfaac62f0a33537ba4
Author: H.J. Lu <hjl.tools@gmail.com>
Date: Wed Feb 9 15:51:22 2022 -0800
x86: Disallow invalid relocation against protected symbol
to allow function pointer reference and make sure that PLT entry isn't
used for function reference due to function pointer reference.
bfd/
PR ld/29087
* elf32-i386.c (elf_i386_scan_relocs): Don't set
pointer_equality_needed nor check non-canonical reference for
function pointer reference.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
ld/
PR ld/29087
* testsuite/ld-x86-64/x86-64.exp: Run PR ld/29087 tests.
* testsuite/ld-x86-64/protected-func-3.c: New file.
The DWARF index code currently uses 'stat' to see if an objfile
represents a real file. However, I think it's more correct to check
OBJF_NOT_FILENAME instead.
Regression tested on x86-64 Fedora 34.
I noticed a few spots in GDB that use "typedef enum". However, in C++
this isn't as useful, as the tag is automatically entered as a
typedef. This patch removes most uses of "typedef enum" -- the
exceptions being in some nat-* code I can't compile, and
glibc_thread_db.h, which I think is more or less a copy of some C code
from elsewhere.
Tested by rebuilding.
This commit:
commit f5cb8afdd297dd68273d98a10fbfd350dff918d8
Date: Sun Feb 6 22:27:53 2022 -0500
gdb: remove BLOCK_RANGES macro
introduces a potential nullptr dereference in block::ranges, this is
breaking most tests, e.g. gdb.base/break.exp is failing for me.
In the above patch BLOCK_CONTIGUOUS_P is changed from this:
#define BLOCK_CONTIGUOUS_P(bl) (BLOCK_RANGES (bl) == nullptr \
|| BLOCK_NRANGES (bl) <= 1)
to this:
#define BLOCK_CONTIGUOUS_P(bl) ((bl)->ranges ().size () == 0 \
|| (bl)->ranges ().size () == 1)
So, before the commit we checked for the block ranges being nullptr,
but afterwards we just call block::ranges() in all cases.
The problem is that block::ranges() looks like this:
/* Return a view on this block's ranges. */
gdb::array_view<blockrange> ranges ()
{ return gdb::make_array_view (m_ranges->range, m_ranges->nranges); }
where m_ranges is:
struct blockranges *m_ranges;
And so, we see that the nullptr check has been lost, and we might end
up dereferencing a nullptr.
My proposed fix is to move the nullptr check into block::ranges, and
return an explicit empty array_view if m_ranges is nullptr.
After this, everything seems fine again.
In static-pie case, there are IRELATIVE-relocs in
.rela.iplt (htab->irelplt), which will later be grouped
to .rela.plt. On s390, the IRELATIVE relocations are
always located in .rela.iplt - even for non-static case.
Ensure that DT_JMPREL, DT_PLTRELA, DT_PLTRELASZ is added
to the dynamic section even if htab->srelplt->size == 0.
See _bfd_elf_add_dynamic_tags in bfd/elflink.c.
bfd/
elf64-s390.c (elf_s390_size_dynamic_sections):
Enforce DT_JMPREL via htab->elf.dt_jmprel_required.
No dynamic relocs are needed for TLS defined in an executable, the
TP relative offset is known at link time.
Fixes
FAIL: Build pr22263-1
bfd/
PR ld/22263
* elf64-s390.c (elf_s390_tls_transition): Use bfd_link_dll
instead of bfd_link_pic for TLS.
(elf_s390_check_relocs): Likewise.
(allocate_dynrelocs): Likewise.
(elf_s390_relocate_section): Likewise.
When two types conflict and they are not types which can have forwards
(say, two arrays of different sizes with the same name in two different
TUs) the CTF deduplicator uses a popularity contest to decide what to
do: the type cited by the most other types ends up put into the shared
dict, while the others are relegated to per-CU child dicts.
This works well as long as one type *is* most popular -- but what if
there is a tie? If several types have the same popularity count,
we end up picking the first we run across and promoting it, and
unfortunately since we are working over a dynhash in essentially
arbitrary order, this means we promote a random one. So multiple
runs of ld with the same inputs can produce different outputs!
All the outputs are valid, but this is still undesirable.
Adjust things to use the same strategy used to sort types on the output:
when there is a tie, always put the type that appears in a CU that
appeared earlier on the link line (and if there is somehow still a tie,
which should be impossible, pick the type with the lowest type ID).
Add a testcase -- and since this emerged when trying out extern arrays,
check that those work as well (this requires a newer GCC, but since all
GCCs that can emit CTF at all are unreleased this is probably OK as
well).
Fix up one testcase that has slight type ordering changes as a result
of this change.
libctf/ChangeLog:
* ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Use
cd_output_first_gid to break ties.
ld/ChangeLog:
* testsuite/ld-ctf/array-conflicted-ordering.d: New test, using...
* testsuite/ld-ctf/array-char-conflicting-1.c: ... this...
* testsuite/ld-ctf/array-char-conflicting-2.c: ... and this.
* testsuite/ld-ctf/array-extern.d: New test, using...
* testsuite/ld-ctf/array-extern.c: ... this.
* testsuite/ld-ctf/conflicting-typedefs.d: Adjust for ordering
changes.
Specifically, tell users what to pass to those functions that accept raw
section content, since it's fairly involved and easy to get wrong.
(.dynsym / .dynstr when CTF_F_DYNSTR is set, otherwise .symtab / .strtab).
include/ChangeLog:
* ctf-api.h (ctf_*open): Improve comment.
gprofng/ChangeLog
2022-04-27 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
PR gprofng/29065
* testsuite/lib/Makefile.skel: Search parent dir for libs too.
addrmap_find shouldn't need to modify the addrmap, so constify the
addrmap parameter. This helps for the following patch, where getting
the map of a const blockvector will return a const addrmap.
Change-Id: If670e425ed013724a3a77aab7961db50366dccb2
Replace with calls to blockvector::blocks, and the appropriate method
call on the returned array_view.
Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
There are some subtle differences between architectures, like the size
of a "long" type, and this isn't currently accounted for in
gdb.base/parse_number.exp.
For example, on aarch64 a long type is 8 bytes, whereas a long type is
4 bytes for x86_64. This causes the following FAIL's:
FAIL: gdb.base/parse_number.exp: lang=asm: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=auto: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=c: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=c++: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=fortran: p/x 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=fortran: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=go: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=local: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=minimal: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=objective-c: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=opencl: ptype 0xffffffffffffffff
FAIL: gdb.base/parse_number.exp: lang=pascal: ptype 0xffffffffffffffff
There are some fortran-specific divergences as well, where 32-bit
architectures show "unsigned int" for both 32-bit and 64-bit integers
and 64-bit architectures show "unsigned int" and "unsigned long" for
32-bit and 64-bit integers.
There might be a bug that 32-bit fortran truncates 64-bit values to
32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff".
Here's what we get for aarch64:
(gdb) ptype 0xffffffff
type = unsigned int
(gdb) ptype 0xffffffffffffffff
type = unsigned long
(gdb) p sizeof (0xffffffff)
$1 = 4
(gdb) p sizeof (0xffffffffffffffff)
quit
$2 = 8
(gdb) ptype 0xffffffff
type = unsigned int
(gdb) ptype 0xffffffffffffffff
type = unsigned long
And for arm:
(gdb) ptype 0xffffffff
type = unsigned int
(gdb) ptype 0xffffffffffffffff
quit
type = unsigned long long
(gdb) p sizeof (0xffffffff)
quit
$1 = 4
(gdb) p sizeof (0xffffffffffffffff)
quit
$2 = 8
(gdb) ptype 0xffffffff
type = unsigned int
(gdb) ptype 0xffffffffffffffff
type = unsigned long
This patch...
* Makes the testcase iterate over all architectures, thus covering all
the different combinations of types/sizes every time.
* Adjusts the expected values and types based on the sizes of long
long, long and int.
A particularly curious architecture is s12z, which has 32-bit long
long, and thus no way to represent 64-bit integers in C-like
languages.
Co-Authored-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ifc0ccd33e7fd3c7585112ff6bebe7d266136768b
I broke the gdbserver build on x86-64 Windows a little while back.
Previously, I could not build this configuration, but today I found
out that if I configure with:
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
using the Fedora 34 tools, it will in fact build. I'm not certain,
but maybe the gnulib update helped with this.
This patch fixes the build. I'm checking it in.
This patch makes use of the support for several stack pointers
introduced by the previous patch to switch between them as needed
during unwinding.
It introduces a new 'unwind-secure-frames' arm command to enable/disable
mode switching during unwinding. It is enabled by default.
It has been tested using an STM32L5 board (with cortex-m33) and the
sample applications shipped with the STM32Cube development
environment: GTZC_TZSC_MPCBB_TrustZone in
STM32CubeL5/Projects/NUCLEO-L552ZE-Q/Examples/GTZC.
The test consisted in setting breakpoints in various places and check
that the backtrace is correct: SecureFault_Callback (Non-secure mode),
__gnu_cmse_nonsecure_call (before and after the vpush instruction),
SecureFault_Handler (Secure mode).
This implies that we tested only some parts of this patch (only MSP*
were used), but remaining parts seem reasonable.
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
Armv8-M architecture with Security extension features four stack pointers
to handle Secure and Non-secure modes.
This patch adds support to switch between them as needed during
unwinding, and replaces all updates of cache->prev_sp with calls to
arm_cache_set_prev_sp.
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
This patch is a preparation for the rest of the series and adds two
arm_cache_init helper functions. It updates every place that updates
cache->saved_regs to call the helper instead.
Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
This patch removes the hardcoded access to PSP in
arm_m_exception_cache() and relies on the definition with the XML
descriptions.
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
While working on adding support for Non-secure/Secure modes unwinding,
I noticed that the prologue analysis lacked support for vpush, which
is used for instance in the CMSE stub routine.
This patch updates thumb_analyze_prologue accordingly, adding support
for vpush of D-registers.
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
Tom and Simon feedback that there is a test failing in this commit:
commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6
Date: Sun Apr 17 15:09:46 2022 +0800
gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)
Then, I reproduced the same fail with Ubuntu 20.04 as Simon said, and I
fixed the nit in this patch. The root of the problem is not correctly
matching the presentation of internal breakpoints.
In addition, as Pedro pointed out, the original testcase is not portable
in some methods, so this patch fixes this issue and some other
improvements.
Tested on x86_64 ubuntu 20.04.4 and openSUSE Tumbleweed(VERSION_ID="20220425").
Revert commit 65daf5bed6 testsuite changes in ld-plugin/. -z isn't
supported for non-ELF targets, and isn't needed since we now prune the
exec stack warning (commit 333cd559ba).
PR 29072
I learned about with_cwd today. I spotted a few spots that could use
it, to make the code more robust.
Change-Id: Ia23664cb827f25e79d31948e0c006a8dc61c33e1
This patch adds PowerPC specific tests to verify recording of various
instructions. The first test case checks the ISA 2.06 lxvd2x instruction.
The second test case tests several of the ISA 3.01 instructions. Specifically,
it checks the word and prefixed instructions and some of the Matrix
Multiply Assist (MMA) instructions.
The patch has been run on both Power 10 and Power 9 to verify the ISA
2.06 test case runs on both platforms without errors. The ISA 3.1 test
runs without errors on Power 10 and is skipped as expected on Power 9.
This patch adds support for the PowerPC ISA 3.1 instructions to the PowerPC
gdb instruction recording routines. Case statement entries are added to a
number of the existing routines for recording the 32-bit word instructions.
A few new functions were added to handle the new word instructions. The 64-bit
prefix instructions are all handled by a set of new routines. The function
ppc_process_prefix_instruction() is the primary function to handle the
prefixed instructions. It calls additional functions to handle specific
sets of prefixed instructions. These new functions are:
ppc_process_record_prefix_vsx_d_form(),
ppc_process_record_prefix_store_vsx_ds_form(),
ppc_process_record_prefix_op34(),
ppc_process_record_prefix_op33(),
ppc_process_record_prefix_op32(),
ppc_process_record_prefix_store(),
ppc_process_record_prefix_op59_XX3(),
ppc_process_record_prefix_op42().
Internally at AdaCore, we noticed that the new Windows thread name
code could fail. First, it might return a zero-length string, but in
gdb conventions it should return nullptr instead. Second, an encoding
failure could wind up showing replacement characters to the user; this
is confusing and not useful; it's better to recognize such errors and
simply discard the name. This patch makes both of these changes.
I noticed that these files failed to format with Black, because they use
print without parenthesis (which isn't Python 3 compatible).
I don't know if these files are still relevant, but the change is
trivial, so here it is.
Change-Id: I116445c2b463486016f824d32effffc915b60766
The format for printing the floating point values was changed by commit:
commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e
Author: Tom Tromey <tromey@adacore.com>
Date: Thu Feb 17 13:43:59 2022 -0700
Change how "print/x" displays floating-point value
Currently, "print/x" will display a floating-point value by first
casting it to an integer type. This yields weird results like:
(gdb) print/x 1.5
$1 = 0x1
...
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16242
The above change results in 417 regression test failures since the expected
Power vector register output no longer match.
This patch updates the expected Altivec floating point register prints to
the hexadecimal format for both big endian and little endian systems. The
patch also fixes a formatting isue with the decimal_vector expected value
assign statements.
The expected VSX vector_register1, vector_register1_vr, vector_register2,
vector_register2_vr variables are updated to include the new float128 entry.
Additionally, the comment in the vsx expect file about the initialization
of the vs registers is updated.
The patch has been tested on Power 10, Power 8 LE and Power 8 BE.
This fixes build breakage using clang with libc++ on FreeBSD where
std::array<> is not yet declared when used by the path_join variadic
function template.
