Before this change individual sections would not be padded or aligned if
there was no C64 code or if there were no capability GOT relocations in
the binary. This meant that if we had a data-only PURECAP shared
library with a CAPINIT relocation in it pointing at something, then the
section that relocation pointed into would not be padded accordingly.
This patch changes this so that we look for sections which may need
individual padding if we see the PURECAP elf header flag, and if there
is a `srelcaps` section (i.e. the RELATIVE capability relocations).
We keep the behaviour that we do not adjust the size of sections unless
there is a static relocation pointing at a zero-sized symbol at that
section. That is, we do not make any adjustment to try and handle
section padding in the case where other binaries would dynamically link
against such symbols. We do this since the "symbol pointing to section
start implies spanning entire section" decision is a hack to enable some
linker script uses, and we don't want to extend it without a known
motivating example.
Finally, this patch ignores padding PCC bounds on PURECAP binaries if
there is no C64 code in this binary, but ensures that the PCC bounds are
made precise even if there are no static relocations in the file.
We could still get the current PCC and offset it using `adr` if there
are no static relocations, but without there being any C64 code there
will be no PCC to bound and hence we don't need the bounds on a
hypothetical PCC to be precise.
Always ensure that the PCC bounds are precise for Morello
The mechanism by which we were ensuring the PCC bounds were made precise
for Morello happened to only work if there were some sections which
needed to be made precisely representable for Morello individually.
This was because we included the PCC bounds calculation in the `queue`
iteration that only iterated over adjustments to individual sections.
Here we move the PCC bounds calculation to after the `queue` iteration
so that we always perform this operation.
We suspect the original implementation was chosen to ensure that padding
was added in sequential section ordering. This ordering seems to have
been in order to ensure that padding at one position would not adjust
sections that had already been adjusted (because padding one section
changes the location of the sections after it).
We have already found in previous patches that this approach was not
sufficient to ensure an adjustment being permanent. The alignment
change to the first section that the PCC should span can change the
location of all sections after it, or the linker can simply have extra
space before .text that it removes on a call to layout_sections_again.
In the patches to fix those problems, we have adjusted the code here to
represent the padding in a way that stays stable across changes. That
has meant that the iteration in VMA order is no longer necessary, and
that means that our movement of the PCC bounds calculation to outside of
the `queue` iteration loop can be performed.
One interesting part of this adjustment is that given a set of sections,
the length of memory that they span can change if the first sections
alignment is adjusted.
For example, if we have the below:
sectionA VMA 0xf size 0x1 alignment 0x1
sectionB VMA 0x10 size 0x10 alignment 0x10
Then aligning sectionA to 0x10 gives the below:
sectionA VMA 0x10 size 0x1 alignment 0x10
sectionB VMA 0x20 size 0x10 alignment 0x10
The total range of the first case is [0xf -> 0x20] for a size of 0x11
and of the second case it is [0x10 -> 0x30] for a size of 0x20.
This means that we should handle the alignment adjustment for the PCC
bounds first, and must handle it in a loop to ensure that we handle the
case that this change in length requires an extra alignment.
Only then do we know the size that we want to add into the last section
in the range so that the entire bounds are correct.
Before this patch we would only change the alignment of a section if it
did not have a start and end address that was aligned properly.
This meant that there was nothing stopping the alignment of this section
degrading in the future. On first glance this looks like it would not
be a problem since this function only adjusts sections in order of
increasing VMA (hence it would seem that the alignment of the current
section can not be reduced).
However, in some cases layout_sections_again can be seen to reduce the
alignment of sections if there was some initial space before the .text
section that it shrinks for some reason. This led to a degredation of
the alignment of all sections after that point (until another highly
aligned section).
The testcase added for this change (in the final "testsuite" commit of
this patch series) is a good example of this, on first entry to the
elfNN_c64_resize_sections function .text happened to have a start
address of 0xb0 (which meant that .data.rel.ro was also aligned to such
a boundary and the function did not believe there was a need to align
.data.rel.ro to a 16 byte boundary). However after the first call to
layout_sections_again this changed to 0x78, reducing the alignment of
.data.rel.ro in the process.
Add padding with an expression rather than a hard-address
When adding padding to ensure section bounds do not overlap we were
implementing the padding using `lang_add_newdot`. This interacts with
what is essentially an in-memory linker script that the linker will
use at the very end to emit its sections according to those rules that
have been built up.
`lang_add_newdot` is essentially the same as defining the position to be
the given address in a linker script. This means that all sections
after this point in the linker script will be at an address starting
from this known address.
I.e. the method by which we add padding is essentially changing the
description of how we will lay a binary out from:
<sections before the padded one>
<section to be padded>
<sections after the padded one>
to the description:
<sections before the padded one>
<section to be padded>
<current position must be 0x[number calculated now]>
<sections after the padded one>
This works fine in most cases. The address we calculate is a known-good
value and sections after this "point" are moved to after the known-good
value.
However, the fact that we choose a specific value when we call
`c64_pad_section` means that adjusting sections which occur *before* the
current point will not change anything that occurs after it.
I.e. a description of
<sections before the padded one>
<section to be padded>
<current position must be 0x[number calculated now]>
<sections after the padded one>
being changed to a description of
<sections before section X>
<New padding>
<sections before padded one>
<section to be padded>
<current position must be 0x[number calculated now]>
<sections after the padded one>
leaves the `<sections after the padded one>` with the same address.
This can lead to the padded section and the section after it
overlapping.
This rarely happens, because our padding always happens after a section
and we iterate over sections in memory order. However, when we align
the very start of the PCC range in order to produce precise bounds
across this range that can change the start position of the first
section that should be spanned by the PCC range.
Since it can change the start position we can hit the problem described
above. This happens when attempting to build glibc. It causes an error
message like the one below.
section .got LMA [000000000053c0c0,000000000053cfff] overlaps section .data.rel.ro LMA [0000000000525fe0,000000000053d08f]
This patch solves this problem by adding an entry into this in-memory
linker script that describes padding without specifying a given address.
I.e. the outline of the script we produce becomes
<sections before the padded one>
<section to be padded>
<current position goes from P to P+0x[padding calculated now]>
<sections after the padded one>
This is safe w.r.t. adjustments occuring before the padding we have
inserted, and it avoids the warning we noticed when trying to build
glibc.
We also fix up some other bugs in this area around double-padding
sections.
First, the calculation of the padding required was based on the
output section VMA and size. The calculation was done by taking the
current start and end VMA then finding the resulting start and end VMA
that we want using c64_valid_cap_range. Then we calculated the padding
we wanted by finding the difference between the current and requested
end VMA's. This ignored the fact that the output section was also
getting aligned, which would change the start VMA -- hence the resulting
end VMA would not end up where we wanted.
Here we do the calculation of how much padding to add based on the size
we want rather than based on the ending VMA we want.
Second, the reported size of the output section was not changing after
adding our padding. This meant that the second time around this loop
(if for example a relocation into a given section was used in more than
one place and hence this section was enqueued twice) we would again find
that the section size was not padded and try again. We fix this by
introducing the padding statement to the output section statement
children rather than to the main statement list. This means that the
padding will be accounted for in the output section size and hence the
loop will avoid padding this section again.
Just to note: LLD does not report the sizes of sections including their
padding. This is so that programs which read binary information (such
as readelf and objdump) do not need to read the padded zeros in the
file. We choose to include this padding in the section size information
on the premise that it is usually quite small and that the output from
these programs is then more readable. The bug that we fixed by
including this padding in the size of the output section could be fixed
in another way.
Before this they would span sections which are SEC_CODE or some specific
known sections like the GOT and PLT.
This is not enough, since the compiler can want to access .rodata via
relative offsets to PCC. Hence we need to include READONLY sections.
Similarly, we want to include .data.rel.ro sections in the PCC bounds so
that they can be accessed via PCC -- this allows the capability
indirection table to be accessed.
We have not been noticing this until now because the default linker
script happens to order sections such that the PCC being required to
span .got and .text happens to end up including these problematic
sections.
RELRO sections are a bit interesting since the fact they are RELRO is
not recorded anywhere on the section itself. Rather it is stored in the
fact that the section is covered by the RELRO segment.
This means that we need to check if the sections VMA is within the
relevant range rather than just look at the section. This turns out to
be pretty easy since we have a structure containing the RELRO range,
however we do need to ensure that we don't mix up the uses of the
section VMA and the RELRO start and end around calls of
layout_sections_again since this call can change both.
Return the alignment required from c64_valid_cap_range
We were specifying section alignment requirements based on the alignment
that the section base happened to have. This sometimes resulted in very
strange alignment requests that were much greater than actually
required.
That is not usually a problem, but it does give unnecessary padding upon
re-adjustments due to changing the PCC bounds after individual sections
have been padded.
This patch adds an interface such that we return the alignment actually
required for exact capability bounds from c64_valid_cap_range. We then
use that alignment as our alignment requirement on the sections which
have a section-sized symbol associated with them.
Provide default permissions if section has no permission flags
The permissions that a capability to an object should end up with is
based on the section it should point into. With symbols that point into
SHN_ABS sections we have nothing to base the permissions on (since these
sections don't have associated permission flags).
For the moment we are making a default of choosing Read-Write
permissions and warning the user about it. The permissions match what
Morello LLD currently does (from observation).
When Morello linkers use the symbol type to determine whether a
capability should have executable permissions or not, this should end up
being able to handle all uses (since STT_FUNC would get RX perms while
everything else gets RW perms).
In the only case we know of in the GNU team the symbol ends up with
zero-size anyway, so the choice of Read-Write doesn't seem too lax.
(Having zero-size is fine for the use-case we know of in glibc, since
that use case simply checks if the address of the symbol is non-zero.
Hence we have no need as yet to dereference the symbol).
The use case we know about are the `_nl_current_<LANG>_used` symbols
defined with `_NL_CURRENT_DEFINE` in the locale/lc-<lang>.c files in
statically linked glibc. If any case that requires non-zero size or
different permissions becomes important then something more will be
required across the toolchain.
This commit is partly changing two existing (believed buggy) behaviours
in elfNN_aarch64_merge_private_bfd_data and partly accounting for a
capability-specific requirement.
The existing behaviours in elfNN_aarch64_merge_private_bfd_data were:
1) It returned `TRUE` by default. This effectively ignored the ELF
flags on the binaries, despite there being code looking at them.
2) We do not mark the output BFD as initialised until we see flags with
non-default architecture and flags. This can't tell the difference
between linking default objects to non-default objects if the default
objects are given first on the command line.
The capability-specific requirement is:
- This function originally returned early if the object file getting
merged into the existing output object file is not dynamic and has no
code sections. The code reasoned that differing ELF flags did not
matter in this case since there was no code that would be expecting
it.
For capabilities the binary compatibility is still important.
Data sections now contain capabilities as pointers, got sections now
have a different got element size.
Hence we avoid this short-circuit if any of the flags we're checking
are the CHERI_PURECAP flag.
The reasoning behind only warning for symbols which have a size which
cannot be precisely bounded is that there is nothing *requiring* precise
bounds, GCC knowingly avoids changing the size of some symbols for
precise bounds (TLS and symbols with user-specified alignment and
user-specified section), and LLD only warns on imprecise bounds rather
than erroring.
N.b. the reasoning for GCC avoiding padding in these cases is explained
in the commit message of b302420cb55 in the GCC branch
vendors/ARM/heads/morello.
All in all it's not something that we want in our toolchain as a
requirement, and it's not something that other toolchains have as a
requirement, so there doesn't seem to be much of a reason to include it.
In order to make this warning a little nicer for anyone reading it, we
add the name of the symbol to the warning. Update the testsuite to
account for this.
1) The linker was storing permission flags in the bottom byte and the
size in the top 56 bits. Newlib was looking for the permission flags
in the top byte and the length in the bottom 56 bits of a uint64_t
stored as bytes 8:16 of the fragment.
N.b. The ABI requires a given storage order between the size and
permission flags (as opposed to requiring a given uint64_t value be
stored in the relevant position). This means that our current
implementation would not work for a hypothetical big-endian Morello.
2) The linker prioritised SEC_READONLY flags over SEC_CODE ones on the
section, this meant that function symbols into the .text section
(which has both flags on it) would be given read-only permissions
rather than executable permissions.
This patch also must update all tests to account for this change.
Alex Coplan [Thu, 3 Feb 2022 08:59:49 +0000 (08:59 +0000)]
ld: Adjust bounds, base, and size for various symbols
This patch has two main goals:
- Relax an existing diagnostic to permit the linker to accept
capability relocations against symbols without size information.
- Adjust the capability base and bounds for symbols which point into
sections which may be accessed via the PCC.
The Morello ABI accesses global data using ADR and ADRP, and has no
special indirection to jump to other functions. Given this, the PCC
must maintain its bounds and base so that during execution loading
global data and jumping to other functions can be done without worrying
about the current PCC permissions and bounds.
To implement this, all capabilities that could be loaded into the PCC
(via BLR or similar) must have a bounds and base according to the PCC.
This must span all global data and text sections (i.e. .got, .text,
.got.plt and the like).
There is already code finding the range that the PCC should span, this
patch records the information in a variable that we can query later.
There are two places where we create a relocation requesting a
capability to be initialised at runtime. When handling relocations
which request a capability from the GOT, and when handling a CAPINIT
relocation. This patch adjusts both.
We can't tell from inspection which symbols would be loaded into the
PCC, but we know that those symbols must point into a section which is
executable. For now, we do this operation for all symbols which point
into an executable section.
Most RELATIVE relocations don't use the addend. Rather the VA and size
we want are put in the relative fragment and the addend is zero.
This is because the *base* of the capability usually matches the VA we
want that capability initialised to.
In these possibly-code symbols we want the base of the capability bounds
to be the base of the PCC, and the VA to be something very different.
Hence we make use of the addend in the RELA relocations to encode this
offset.
Note on implementation:
c64_fixup_frag takes the base and size of a capability we want to
request from the runtime and checks that these are exactly representable
in a capability. This patch changes many of the capabilities we request
from the runtime to have the same bounds (those of the PCC). We leave
the check to look at the bounds requested by the symbol rather than to
check the PCC bounds multiple times. That means that if a symbol that
points into an executable section has incorrect bounds then this will
trigger a linker error even though it will cause no security problem
when this executes. This is a trade-off between getting extra checks
that the compiler is handling object bounds sizes and erroring on
non-problematic code.
We have a compatibility hack that if a symbol is defined in the linker
script to be directly after a given section but is *named* something
like __.*_start or __start_.* then we treat it as if it is defined at
the very start of the next section. The new behaviour introduced in
this patch needs to take account of the above compatibility hack.
This patch also updates the testsuite according to these changes.
In some places the original test no longer checks what it wanted, since
the base of all symbols pointing into executable sections are now the
same. There we add extra symbols and things to check so we ensure that
this behaviour of PCC bounds is seen and that the original behaviour is
still seen on non-executable sections.
This commit also includes a few tidy-ups:
We adjust the base and limit that are checked in c64_fixup_frag.
Originally this would calculate the base as value + addend. As
discussed above the way we treat capabilities in Morello is such that
the value determines the base and the addend determines the initial
value pointing from that base. Hence the check that these capabilities
had correct bounds was not correct.
We add an extra assertion in final_link_relocate for robustness
purposes. There is an existing bug in the assembler where GOT
relocations against local symbols can be turned into relocations against
the relevant section symbol plus an addend. This is problematic for
multiple reasons, one being that the linker implementation does not have
any way to associate different GOT entries with the same symbol but
multiple offsets. In fact the linker ignores any offset. Here we
simply add an assertion that this never happens. It turns a silent
pre-existing error into a noisy one.
2022-02-03 Alex Coplan <alex.coplan@arm.com>
Matthew Malcomson <matthew.malcomson@arm.com>
bfd/ChangeLog:
* elfnn-aarch64.c (pcc_low): New.
(pcc_high): New.
(elfNN_c64_resize_sections): Update new global variables
pcc_{low,high} instead of local variables to track PCC span.
(enum c64_section_perm_type): New.
(c64_symbol_section_adjustment): New.
(c64_fixup_frag): Rework to calculate size appropriately for
symbols that need adjustment.
(c64_symbol_adjust): New. Use it ...
(elfNN_aarch64_final_link_relocate): ... here.
ld/ChangeLog:
* testsuite/ld-aarch64/aarch64-elf.exp: Add new tests.
* testsuite/ld-aarch64/emit-relocs-morello-6.d: New test.
* testsuite/ld-aarch64/emit-relocs-morello-6.s: Assembly.
* testsuite/ld-aarch64/emit-relocs-morello-6b.d: New test.
* testsuite/ld-aarch64/emit-relocs-morello-7.d: New test.
* testsuite/ld-aarch64/emit-relocs-morello-7.ld: Linker script thereof.
* testsuite/ld-aarch64/emit-relocs-morello-7.s: Assembly.
* testsuite/ld-aarch64/morello-capinit.d: New test.
* testsuite/ld-aarch64/morello-capinit.ld: Linker script.
* testsuite/ld-aarch64/morello-capinit.s: Assembly.
* testsuite/ld-aarch64/morello-sizeless-global-syms.d: New test.
* testsuite/ld-aarch64/morello-sizeless-global-syms.s: Assembly.
* testsuite/ld-aarch64/morello-sizeless-got-syms.d: New test.
* testsuite/ld-aarch64/morello-sizeless-got-syms.s: Assembly.
* testsuite/ld-aarch64/morello-sizeless-local-syms.d: New test.
* testsuite/ld-aarch64/morello-sizeless-local-syms.s: Assembly.
Co-authored-by: Matthew Malcomson <matthew.malcomson@arm.com>
Trying to link code against newlib with the current BFD Morello linker
we get quite a lot of cases of the error below.
"relocation truncated to fit: R_MORELLO_LD128_GOT_LO12_NC against symbol
`<whatever>' defined in .text.<whatever> section in <filename>"
This happens because the relocation gets transformed into a relocation
pointing into the GOT in elfNN_aarch64_final_link_relocate, but the
h->target_internal flag that indicates whether this is a C64 function
symbol or not is then added to the *end* value rather than the value
that is stored in the GOT.
This then correctly falls foul of a check in _bfd_aarch64_elf_put_addend
that ensures the value we get from this relocation is 8-byte aligned
since it must be pointing to the start of a valid entry in the GOT.
Here we ensure that this LSB is set on the value newly added into the
GOT rather than on the offset pointing into the GOT. This both means
that loading function symbols from the GOT will have the LSB correctly
set (hence we stay in C64 mode when branching to this function as we
should) and it means that the error about a misaligned GOT address is
fixed.
In this patch we also ensure that we add a dynamic relocation to
initialise the correct GOT entry when we are resolving a MORELLO
relocation that requires an entry in the GOT.
This was already handled in the case of a global symbol, but had not
been handled in the case of a local symbol. This is why we set
`relative_reloc` to TRUE in if resolving a MORELLO GOT relocation
against a static executable.
In writing the testcase for this patch we found an existing bug to do
with static relocations of this kind (of this kind meaning that are
handled in this case statement). The assembler often chooses to create
the relocation against the section symbol rather than the original
symbol, and make up for that by giving the relocation an addend. The
linker does not have any mechanism to create "symbol plus addend"
entries in the GOT -- it indexes into the GOT based on the symbol only.
Hence all relocations which are a section symbol plus addend end up
pointing at one value in the GOT just containing the value of the
symbol.
We do not fix this existing bug, but just note it given that this is in the
same area.
The name has been changed in LLVM, so we adjust it in binutils to match.
We also move where these symbols are created. Previously they were
created in elfNN_aarch64_always_size_sections, but we move this to
elfNN_aarch64_size_dynamic_sections.
We do the moving since these symbols are supposed to span all dynamic
capability relocations stored in the .rela.dyn section for static
executables. In the case of a static binary we place relocations for
the GOT into this section as well as internal relocations.
These relocations for the GOT are handled in
elfNN_aarch64_size_dynamic_sections, which is called *after*
elfNN_aarch64_always_size_sections. The size of this section is only
fully known after those GOT relocations are managed, so the position
these symbols should be placed in is only known at that point. Hence we
only initialise the __rela_dyn* symbols at that point.
2021-10-06 Matthew Malcomson <matthew.malcomson@arm.com>
ChangeLog:
* bfd/elfnn-aarch64.c (elfNN_aarch64_always_size_sections): Move
initialisation of __rela_dyn* symbols ...
(elfNN_aarch64_size_dynamic_sections): ... to here.
* ld/testsuite/ld-aarch64/aarch64-elf.exp: Run new tests.
* ld/testsuite/ld-aarch64/emit-morello-reloc-markers-1.d: New test.
* ld/testsuite/ld-aarch64/emit-morello-reloc-markers-1.s: New test.
* ld/testsuite/ld-aarch64/emit-morello-reloc-markers-2.d: New test.
* ld/testsuite/ld-aarch64/emit-morello-reloc-markers-2.s: New test.
* ld/testsuite/ld-aarch64/emit-morello-reloc-markers-3.d: New test.
* ld/testsuite/ld-aarch64/emit-morello-reloc-markers-3.s: New test.
Alex Coplan [Mon, 17 Jan 2022 16:52:07 +0000 (16:52 +0000)]
ld: Ignore TLS relocs against weak undef symbols
The behaviour of weak undef thread-local variables is not well defined.
TLS relocations against weak undef symbols are not handled properly by
the linker, and in some cases cause the linker to crash (notably when
linking glibc for purecap Morello). This patch simply ignores these and
emits a warning to that effect. This is a compromise to enable progress
for Morello.
bfd/ChangeLog:
2022-01-17 Alex Coplan <alex.coplan@arm.com>
* elfnn-aarch64.c (elfNN_aarch64_relocate_section): Skip over TLS
relocations against weak undef symbols.
(elfNN_aarch64_check_relocs): Likewise, but also warn.
ld/ChangeLog:
2022-01-17 Alex Coplan <alex.coplan@arm.com>
* testsuite/ld-aarch64/aarch64-elf.exp: Add morello-weak-tls test.
* testsuite/ld-aarch64/morello-weak-tls.d: New test.
* testsuite/ld-aarch64/morello-weak-tls.s: New test.
* testsuite/ld-aarch64/weak-tls.d: Update test wrt new behaviour.
Luis Machado [Thu, 30 Dec 2021 14:10:07 +0000 (11:10 -0300)]
Simplify tag management in value structs
Instead of actively setting the tagged field of struct value *, initialize
the tagged field right when allocating a new value. This simplifies the
management of this field.
Luis Machado [Thu, 30 Dec 2021 13:45:11 +0000 (10:45 -0300)]
Preserve tag when passing pointers/capabilities as parameters
Fix a bug where Morello GDB wasn't setting the capability tag when calling a
function by hand, and said function received a pointer/capability as
parameter.
This was observed when attempting to call strlen by hand and passing the
argv[] entries.
Luis Machado [Wed, 29 Dec 2021 11:20:53 +0000 (08:20 -0300)]
Support assignment of capabilities to C registers
Enable assignment of capabilities to C registers while preserving
the capability tag. This enables operations like the following:
set $c0=$c1
set $c0=p, where "p" is a capability (pointer) in AARCH64-CAP
Due to the X/C register overlap, we also force a re-read of register
data after every register write. So any 'G' packets are immediately
followed by a 'g' packet.
Luis Machado [Fri, 24 Dec 2021 14:37:52 +0000 (11:37 -0300)]
Improve error messages for capability reads/writes to memory
Improve the messages a little so the errors are more clear. One case in
particular is when we attempt to write a tagged capability to a shared
mapping area that doesn't support tags.
GDB and GDBserver share the same error messages now.
Improve error message when setting capability registers fails. Mention
the name of the set (capability) explicitly so it is clear what register
set we are talking about.
Luis Machado [Wed, 1 Dec 2021 11:23:24 +0000 (08:23 -0300)]
Adjust PCC bounds when calling a function by hand in AAPCS64-CAP
For dynamically-linked binaries using the AAPCS64-CAP ABI, the PCC bounds for
distinct DSO's can be different, and that needs to be taken into account.
Since there isn't a good interface for GDB to fetch the precise bounds (the
.plt.got could be used for this, but doesn't contain data for symbols not
being used by the program), we use maximum bounds and the existing PCC
permissions.
This allows GDB to call functions by hand in AAPCS64-CAP mode.
Also, revert a previous change to do partial writes (lower 64 bits) of the
PCC, as this isn't needed anymore.
For each register of the C set, users can reference the pseudo registers by
adding a 'p' prefix. For example, the pseudo register of c0 and pcc are pc0
and ppcc.
Users can set the entire 129 bits of the capability this way, if the
cheri.ptrace_forge_cap flag is enabled.
Luis Machado [Wed, 15 Dec 2021 13:24:35 +0000 (10:24 -0300)]
Workaround GDBserver register cache management
Given X and C registers have an overlap, if we write to an X register, we need
to fetch the C registers again so we get updated values (side effects). The
same happens when we attempt to write to the lower half of C registers, we need
to fetch the X registers again so we get updated values.
This patch forces the register cache to get updated values after a register
store request.
Luis Machado [Mon, 29 Nov 2021 12:19:39 +0000 (09:19 -0300)]
Handle C regset write warnings better in GDBServer
GDBServer handles register reads/writes a bit differently compared to GDB.
Since C register writes are only allowed with cheri.ptrace_forge_cap=1,
GDBServer will keep issuing warnings if such setting is 0.
This patch improves it by issuing a single more helpful warning to the
user. If cheri.ptrace_forge_cap is flipped, the warning will be issued
again appropriately to remind the user about it.
Luis Machado [Mon, 29 Nov 2021 10:28:28 +0000 (07:28 -0300)]
Handle bitfield instructions in the prologue
Morello GCC seems to generate bitfield instructions in the prologue, which
throws Morello GDB's prologue analyzis off. Handle such instructions so we
can properly skip past the prologue.
Luis Machado [Fri, 26 Nov 2021 14:31:18 +0000 (11:31 -0300)]
New --enable-threading configure option to control use of threads in GDB/GDBserver
Add the --enable-threading configure option so multithreading can be disabled
at configure time. This is useful for statically-linked builds of
GDB/GDBserver, since the thread library doesn't play well with that setup.
If you try to run a statically-linked GDB built with threading, it will crash
when setting up the number of worker threads.
This new option is also convenient when debugging GDB in a system with lots of
threads, where the thread discovery code in GDB will emit too many messages,
like so:
Alex Coplan [Thu, 11 Nov 2021 16:57:22 +0000 (16:57 +0000)]
aarch64: Fix scbnds validation
Prior to this patch, we were failing to validate scbnds instructions
properly in multiple ways. The code in tc-aarch64.c:parse_operands
failed to check if the expression parsing code actually returned a
constant (O_constant) immediate. For sufficiently large immediates this
would result in O_big instead and this was not handled.
Moreover, the code to coerce the immediate form into the immediate +
shift form of the instruction was buggy in multiple ways: using the
wrong mask to check if the lower bits were set and checking the wrong
variable.
Finally, the code in operand_general_constraint_met_p was only checking
if the immediate is in range for the shifted case: it should be checking
this in both cases.
As well as fixing these issues, this patch improves the error messages
in a couple of cases and adds tests for various valid and invalid cases.
gas/ChangeLog:
2021-11-11 Alex Coplan <alex.coplan@arm.com>
* config/tc-aarch64.c (parse_shift): Improve error message for
O_big expressions.
(parse_operands): In AARCH64_OPND_A64C_IMM6_EXT case, handle
parse_shifter_operand_imm returning non-O_constant
expressions; fix logic for coercion to the shifted form.
* testsuite/gas/aarch64/scbnds-immed.d: New test.
* testsuite/gas/aarch64/scbnds-immed.s: Assembly thereof.
* testsuite/gas/aarch64/scbnds-invalid.d: New test.
* testsuite/gas/aarch64/scbnds-invalid.l: Error output thereof.
* testsuite/gas/aarch64/scbnds-invalid.s: Assembly thereof.
opcodes/ChangeLog:
2021-11-11 Alex Coplan <alex.coplan@arm.com>
* aarch64-opc.c (operand_general_constraint_met_p): Always check
if the immediate is in range for AARCH64_OPND_A64C_IMM6_EXT.
Alex Coplan [Fri, 24 Sep 2021 12:56:59 +0000 (13:56 +0100)]
aarch64: Mark purecap object files with EF_AARCH64_CHERI_PURECAP
This simple patch sets the ELF header flag EF_AARCH64_CHERI_PURECAP for
purecap Morello object files, as documented in aaelf64-morello:
https://github.com/ARM-software/abi-aa/blob/main/aaelf64-morello/aaelf64-morello.rst
gas/ChangeLog:
2021-09-24 Alex Coplan <alex.coplan@arm.com>
* config/tc-aarch64.c (md_begin): Set the ELF header flag
EF_AARCH64_CHERI_PURECAP if we have the C64 extension.
Alex Coplan [Fri, 24 Sep 2021 10:50:40 +0000 (11:50 +0100)]
morello: Fix encoding of ldtr/sttr
This patch fixes the encoding of the immediate in the A64C ldtr/sttr
instructions. Prior to this patch, GAS would accept immediates for these
instructions that were not multiples of 16, and would not scale the
immediate by 16.
gas/ChangeLog:
2021-09-24 Alex Coplan <alex.coplan@arm.com>
* testsuite/gas/aarch64/morello_ldst-c64.d: Update following
test + encoding change.
* testsuite/gas/aarch64/morello_ldst-invalid.d: New test.
* testsuite/gas/aarch64/morello_ldst-invalid.l: New test.
* testsuite/gas/aarch64/morello_ldst-invalid.s: New test.
* testsuite/gas/aarch64/morello_ldst.d: Update following
test + encoding change.
* testsuite/gas/aarch64/morello_ldst.s: Update to use valid
immediates for ldtr/sttr instructions.
opcodes/ChangeLog:
2021-09-24 Alex Coplan <alex.coplan@arm.com>
* aarch64-tbl.h (aarch64_opcode_table): Update A64C_INSNs
ldtr/sttr to take A64C_ADDR_SIMM9 instead of ADDR_SIMM9
operands.
This function had a buggy implementation of rounding a value up to a
given power of 2. Aligning to a multiple of 16 would align to a
multiple of 32 and so on.
This was observable when linking object files that had very large
objects in them. The compiler would ensure that these objects are large
enough that they are exactly representable, but the linker would
complain that they are not because the linker asserted extra alignment
than the compiler.
Here we fix the bug, add a few testcases, and adjust an existing
testcase in the area.
Alex Coplan [Fri, 10 Sep 2021 17:10:48 +0000 (18:10 +0100)]
aarch64: Correct feature bits for Morello
As it stands, the architecture feature bits for Morello include FP16FML
(i.e. ARMv8.2-FHM) but not FP16: this is an invalid combination.
Looking at the Morello Arm ARM [1], it seems that Morello wants the
feature FP16 (ARMv8.2-FP16) but not FP16FML.
Luis Machado [Fri, 20 Aug 2021 11:19:04 +0000 (08:19 -0300)]
Support linkmap offsets for the AAPCS64-CAP ABI
With the AAPCS64-CAP ABI, any pointers in data structures become capabilities.
Capabilities for Morello are 128-bit in size, so the offsets of individual
fields within the structure might change.
One such structure that needs to be adjusted is the linkmap. The linkmap is
used by GDB to list shared libraries that get loaded/unloaded.
This patch enables AAPCS64-CAP linkmap offsets for both GDB and GDBserver,
allowing GDB/GDBserver to list the shared libraries correctly.
After d30dd5c GAS now accounts for the LSB getting set on STT_FUNC by
maintaining the value of the relevant functions to include that LSB.
Previously GAS attempted to account for the LSB only when outputting the
file (i.e. in the obj_adjust_symtab hook and when a relocation is
getting made for the relevant symbol).
The obj_adjust_symtab hook is still needed, since this is about adding a
flag to an elf_sym rather than adjusting the value of the symbol.
We changed from this so that expressions given by the user would
naturally account for the LSB set on C64 STT_FUNC symbols. This means
that we no longer need to adjust local pc-relative relocations in
`parse_operands` since the relative relocation will naturally include
whether the LSB is set on the relevant symbol.
Here we remove the previous code to do this adjustment. With both
methods of accounting we ended up adding 2 to the relocation rather than
just setting the LSB.
Note that the combination of this change and d30dd5c has meant that a
`AARCH64_ADR_PREL_LO21` relocation to a locally defined function now points
directly to that function rather than to that function plus 1.
These relocations are left in the object file when the locally defined
function is declared global. This matches the behaviour of LLVM.
gas: Remove requirement of getting a target symbol
Before this change we had a check that any capinit directive had a plain
symbol (possibly plus an addend) as an argument.
Unfortunately, the check itself is actually that GAS can identify that
the expression we have is in that category *before* applying all
adjustments after alignment etc. Internally this not only required that
the expression was of a simple enough form, but also that if we had an
expression of the form `f+((.Ltmp+1)-f)` (which is a form that compilers
use for label addresses) this required that the `f` and `.Ltmp` labels
were in the same `frag`.
In order to be in the same `frag` there could be no alignment between
them, whether from alignment directives between the two labels, or
because we had a data directive in between them and the assembler
ensured we were aligned when re-entering code state.
This artificial requirement triggered an assembler error when running
the GCC testsuite, hence we have removed it. This matches LLVM
behaviour. More obvious errors like subtracting symbols from different
sections are still caught in the general expression handling code.
gas: Allow MORELLO branch relocations to addresses with LSB set
Now that we internally handle a set LSB as part of a C64 STT_FUNC value
throughout the assembler rather than as something that is just
introduced by the linker, relocations to code labels now may or may not
include that LSB.
GAS checks that the target of an AARCH64 BRANCH19, TSTBR14, CALL26, or
JUMP26 relocation is aligned, since all uses should point to an
instruction and all instructions should be aligned.
Now that we are including the LSB in the value of STT_FUNC C64 symbols,
the relevant MORELLO_* relocations do not also satisfy this alignment
behaviour. When these relocations target a location generated from an
STT_FUNC C64 symbol, their value includes that LSB.
This behaviour is not relevant to the user since these relocations lose
the bottom 2 bits of the value they target. It does however match the
specification of the relocations in the ABI document, which includes the
`C` bit.
This fix avoids requiring that this LSB is unset when in `md_apply_fix`.
For extra robustness we also assert that when setting this LSB on the
symbol in the first place it was not set to begin with.
A downside is that if the LSB is set on non-function symbols the user
will not be warned about that. Any method to handle that would always
need to determine which expressions should include this LSB and which
shouldn't, which would be difficult to make perfect. On top of that,
the relevant code would either have to duplicate the code in
`fixup_segment` that resolves an expression into a single value, or
record another bit in the `TC_FIX_TYPE` structure just for this warning.
This seems like more complexity than the extra warning is worth.
We add two tests since `objdump` shows the resulting disassembly but
`readelf` shows the LSB getting set on the relevant functions.
This is just to help anyone trying to build Morello binutils with a very
old system compiler.
At the time we branched, binutils wanted to be able to be build using C89.
These changes are what is needed to compile using the `-ansi` flag (i.e.
using that C89 flag).
gas: aarch64: Accept `purecap` and `hybrid` ABI parameters
When GCC is given an ABI parameter with `-mabi=<whatever>` it passes
that argument down to GAS. GAS does not need to know the Morello ABI
that is being used, since all decisions are based on the processor state
(whether +c64 is enabled or not).
GAS doesn't currently accept `purecap` or `hybrid` as arguments to the
`-mabi` option. Even though it does not need this information, I think
it should accept the arguments. This would mean GCC does not need
implement special handling to avoid passing the `-mabi` argument to GAS
in these specific cases.
gas/ChangeLog:
2021-07-30 Matthew Malcomson <matthew.malcomson@arm.com>
gas: aarch64: Require 16 bytes for Morello capinit relocation
The `capinit` directive does not allocate space for the relevant
relocation, rather it creates a CAPINIT relocation on the 16 bytes
immediately following it.
Our implementation works by ensuring we can grow the existing `frag` (an
internal structure that describes known contiguous bytes) by 8 bytes
and then recording that we have an 8 byte sized CAPINIT relocation.
It should be 16 bytes, since the relocation is on a 16 byte quantity.
One symptom this problem can cause is where the section that a given
CAPINIT relocation is recorded may not have enough space for the entire
capability the CAPINIT relocation requests.
The testcase we add demonstrated this problem before the current change.
Now it errors out. Unfortunately the error is an internal one with a
error message that references internal data structures, but I believe
that is better than creating a faulty binary without complaint.
This directive is the equivalent of the capinit directive except that it
allocates space as well as creating a CAPINIT relocation.
It is useful to be added to binutils since LLVM intend to transition
away from using capinit to chericap and this helps enable that
transition.
Here we just emit the required number of zeros into the output file with
md_number_to_chars. Since we don't have to worry about endianness for a
big zero this is not complicated.
gas: aarch64: Fixing expression calculation using C64 symbols
Expressions involving function symbols should take into account the fact
that the LSB of C64 functions is set (while the LSB of labels is not
set).
The main motivating example of this is `capinit` expressions of the form
f+((.Ltmp0+1)-f)
where `f` is a function and `.Ltmp0` is a label.
These should result in a CAPINIT relocation of the form
`f + <constant multiple of 4>` since the `+1` on the `.Ltmp0` should
cancel out the LSB that is set on `f`.
This is slightly different to the handling of a set LSB for THUMB
functions, since in THUMB the LSB is not kept when computing relations.
For THUMB expressions using the function are emitted as relocations to
let the linker apply the adjustment.
To implement this, we have two options (we choose the second):
- Handle the LSB in the target hook `md_optimize_expr` (similar to how
the arm backend handles expressions involving THUMB functions).
- Set the LSB on the value assigned to the symbol in `tc_frob_label`.
The approach using the `md_optimize_expr` hook would involve adding one
to the expression that describes an operand, when that operand is a
C64 function symbol with no addend. Then returning `FALSE` from that
hook in order to let the generic code handle the expression from then
on.
We would only want to do this when there is no addend to avoid applying
this adjustment multiple times in an expression (e.g. when a
subexpression reduces to a function symbol plus addend).
This adjustment would also want to avoid doing this to any expression
that would end up as a relocation involving that function symbol, since
then the artificial adjustment would be propagated to the relocation
(resulting in an expression like `f - 63` where the addend has been
adjusted to account for the LSB in `f`, but the linker will account for
the LSB in `f` itself).
Such avoidance is simple enough for expressions like `O_add` since we
can always avoid them, but it is more awkward to tell for `O_subtract`
expressions where some expressions can be reduced to a constant while
others will end up as a relocation.
Another difficulty with this approach is that the value of an expression
can be different depending on the relative location of the `type`
directive to the expression in the assembly source. If the directive is
before an expression then the expression will account for the LSB but if
the directive is after the expression it will not.
While behaviour depending on the location of the `type` directive is a
tricky problem and has problems in the Morello LLVM compiler as well,
these behaviours do not match the behaviour of Morello LLVM.
The second approach is to adjust a symbols value in `tc_frob_label` if
it is a C64 function. This will automatically mean that all symbol
expressions use this LSB correctly.
This approach does still have difficulties with relative locations of
the `type` directive, but here the behaviour matches Morello LLVM. The
important factor in this case is whether the `type` directive is before
or after the function symbols label. If the function label is before
the `type` directive then *all* expressions using the function label
will not account for the LSB, otherwise all expressions will utilise it.
There are two known differences with the Morello LLVM behaviour when
taking this approach.
The first is around calculating an expression of the form `operand - f`.
If `operand` is known, then both GAS and LLVM will account for the LSB
of `f`, but if `operand` is not known at the time this expression is
found then GAS will account for the LSB in the final relocation put into
the binary while Morello LLVM will not. This is a Morello LLVM bug.
The second is that Morello LLVM does not allow expressions of the form
`f > altlabel` while GAS does. In this case we have chosen to account
for the LSB, so that even if `f` and `altlabel` are defined in the same
place, if `f` is a C64 function symbol and `altlabel` is not then `f >
altlabel` will evaluate to true.
We're choosing the bfd_reloc_code_real_type value to set on
inst.reloc.type. Hence we should use the bfd_reloc_code_real_type type
for our temporaries.
This was not failing since the temporaries could hold the relevant
types, but was causing warnings that broke the build if running with
-Werror. I saw the warning on gcc version 10 and 11, I did not see the
warning on gcc version 7.5.
Testsuite as a cross-build for aarch64-none-elf and aarch64-linux native
shows no change.
---
2021-07-20 Matthew Malcomson <matthew.malcomson@arm.com>
gas/ChangeLog:
* config/tc-aarch64.h (parse_operands): Use correct enum type for
temporaries.
Alex Coplan [Tue, 13 Jul 2021 16:20:22 +0000 (17:20 +0100)]
gas: Fix uninitialized c64 member of aarch64_fix struct
The c64 flag in the aarch64_fix struct was missing an initialization.
This was causing Morello relocations to be spuriously inserted, even
when not targeting C64.
This patch fixes the issue by initializing the flag to false.
Luis Machado [Tue, 22 Jun 2021 18:25:32 +0000 (15:25 -0300)]
Fix ABI check
Morello GDB used to rely on the presence of the __cap_relocs section to
identify a ELF file that followed the pure-cap ABI. This isn't reliable
anymore.
Instead, we check two types of information. One of them is the e_flags, which
contains a bit identifying the pure-cap ABI. The second one is the LSB of the
e_entry, which is set for a pure-cap ABI ELF.
gdb/ChangeLog:
2021-06-24 Luis Machado <luis.machado@arm.com>
* aarch64-tdep.c: Include elf/aarch64.h.
(aarch64_bfd_has_capabilities): Make more robust.
(aarch64_gdbarch_init): Set have_capability if we have a pure-cap
ABI marker.
include/ChangeLog:
2021-06-24 Luis Machado <luis.machado@arm.com>
* elf/aarch64.h (EF_AARCH64_CHERI_PURECAP): New constant.
Luis Machado [Mon, 14 Jun 2021 17:32:26 +0000 (14:32 -0300)]
Make capability maintenance command available to cross GDB
The capability maintenance commands were originally only available to
native Morello GDB builds. Make those commands available to cross Morello
GDB builds as well, since they are useful.
Luis Machado [Mon, 14 Jun 2021 17:19:35 +0000 (14:19 -0300)]
Print additional information on capability store errors
Augment the warnings about not being able to write to capability registers
or write capabilities to memory. Show the command that needs to be entered
in the shell to enable this particular mode.
There is a speed limitation while saving capability tags. That's because GDB
only has access to one capability per-ptrace call. In the future there may be
a ptrace request to read capability tags in bulk, which will make things much
faster.
Tested by writing a gcore-based core file and reading it back, and also
exercised by reading a kernel-generated core file.
bfd/ChangeLog:
2021-05-24 Luis Machado <luis.machado@arm.com>
* elf-bfd.h (elfcore_write_aarch_morello): New prototype.
* elf.c (elfcore_grok_aarch_morello): New function.
(elfcore_grok_note): Handle NT_ARM_MORELLO.
(elfcore_write_aarch_morello): New function.
(elfcore_write_register_note): Handle reg-aarch-morello.
(elfcore_make_memtag_note_section): New function.
(elfcore_grok_note): Handle NT_MEMTAG note types.
Luis Machado [Tue, 4 May 2021 15:45:36 +0000 (12:45 -0300)]
Refactor parsing of /proc/<pid>/smaps
The Linux kernel exposes the information about MTE-protected pages via the
proc filesystem, more specifically through the smaps file.
What we're looking for is a mapping with the 'mt' flag, which tells us that
mapping was created with a PROT_MTE flag and, thus, is capable of using memory
tagging.
We already parse that file for other purposes (core file
generation/filtering), so this patch refactors the code to make the parsing
of the smaps file reusable for memory tagging.
The function linux_address_in_memtag_page uses the refactored code to allow
querying for memory tag support in a particular address, and it gets used in the
next patch.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-tdep.c (struct smaps_vmflags) <memory_tagging>: New flag
bit.
(struct smaps_data): New struct.
(decode_vmflags): Handle the 'mt' flag.
(parse_smaps_data): New function, refactored from
linux_find_memory_regions_full.
(linux_address_in_memtag_page): New function.
(linux_find_memory_regions_full): Refactor into parse_smaps_data.
* linux-tdep.h (linux_address_in_memtag_page): New prototype.
Luis Machado [Fri, 26 Feb 2021 16:34:12 +0000 (13:34 -0300)]
Support for passing/returning parameters
This patch implements passing/returning of parameters for Morello. It is
implemented based on the Morello AAPCS64 document and supports both the hybrid
AAPCS64 and Pure-Cap AAPCS64-CAP ABI's.
gdb/ChangeLog
2021-02-26 Luis Machado <luis.machado@arm.com>
* aarch64-tdep.c (struct stack_item_t) <arg_value): New field.
(set_register_tag, pass_in_c, pass_in_c_or_stack,
pass_in_c_x_or_stack, type_fields_overlap_capabilities,
convert_pointer_to_capability,
morello_write_memory_with_capabilities,
morello_push_dummy_call, morello_extract_return_value,
morello_return_in_memory, morello_store_return_value,
morello_return_value): New functions.
(pass_in_x, pass_in_v, pass_on_stack, pass_in_x_or_stack,
pass_in_v_vfp_candidate): Update.
(aarch64_return_value): New argument value.
(aarch64_gdbarch_init): Conditionally set both gdbarch_push_dummy_call
and gdbarch_return_value.
* arch/aarch64.h (MORELLO_MEMORY_TAG_GRANULE_SIZE): New constant.
* dwarf2/read.c (handle_struct_member_die): Record whether the
composite type contains capabilities.
* gdbarch.sh (return_value): New argument value.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbtypes.c (recursive_dump_type): Dump extra information.
(append_composite_type_field_raw): Set whether the composite type
constains capabilities.
* gdbtypes.h (struct main_type) <m_flag_contains_capability>: New field.
<contains_capability>: New member function.
<set_contains_capability>: New member function.
Luis Machado [Tue, 12 Jan 2021 18:53:00 +0000 (15:53 -0300)]
Enable capability writes to memory
Enable writing/forging capabilities to memory via the PTRACE_POKECAP ptrace
request. This patch enables both GDB and gdbserver for Morello.
For remote writes, we use the qXfer:capa:write packet.
gdb/ChangeLog:
2021-03-17 Luis Machado <luis.machado@arm.com>
* aarch64-linux-nat.c (aarch64_linux_nat_target)
<write_capability>: New member function override.
(aarch64_linux_nat_target::write_capability): New member
function.
(maint_print_cap_from_addr_cmd): Adjust printing format.
(maint_set_capability_in_memory_cmd): New maintenance function.
(add_show_debug_regs_command): Register new maintenance command.
* nat/aarch64-cap-linux.c (aarch64_linux_write_capability): New
function.
* nat/aarch64-cap-linux.h (aarch64_linux_write_capability): New
prototype.
* remote.c (remote_target)
<write_capability>: New member function override.
Adjust enum documentation for PACKET_qXfer_capability.
(remote_target::write_capability): New member function.
(_initialize_remote): Adjust documentation for
PACKET_qXfer_capability.
* target-debug.h
(target_debug_print_gdb_array_view_const_gdb_byte): New macro.
* target-delegates.c: Regenerate.
* target.c (target_write_capability): New function.
* target.h (struct target_ops) <write_capability>: New virtual member
function.
(target_write_capability): New prototype.
Luis Machado [Tue, 9 Mar 2021 17:56:15 +0000 (14:56 -0300)]
Fix disassembly of C64 instructions in GDB
Disassembling of C64 instructions in GDB does not work correctly. It needs
to pass the proper information to opcodes.
This patch accomplishes that.
gdb/ChangeLog:
2021-03-17 Luis Machado <luis.machado@arm.com>
* aarch64-tdep.c (aarch64_find_mapping_symbol, aarch64_pc_is_c64): New
functions.
(aarch64_gdb_print_insn): Pass map type to disassembler.
include/ChangeLog:
2021-03-17 Luis Machado <luis.machado@arm.com>
* opcode/aarch64.h (enum map_type): Moved from opcodes/aarch64-dis.c.
Renamed fields.
(struct aarch64_private_data): New struct.
opcodes/ChangeLog:
2021-03-17 Luis Machado <luis.machado@arm.com>
* aarch64-dis.c (enum map_type): Moved to include/opcode/aarch64.h.
(MAYBE_C64): Adjust.
(get_sym_code_type): Adjust.
(print_insn_aarch64): Use private data when available.
Luis Machado [Mon, 11 Jan 2021 17:18:36 +0000 (14:18 -0300)]
Enable Morello register set writes
Make the Morello register set writable, so GDB can write to the C registers
and forge capabilities.
To enable write access to the registers, the cheri.ptrace_forge_cap sysctl
option must be toggled.
gdb/ChangeLog:
2021-01-15 Luis Machado <luis.machado@arm.com>
* aarch64-linux-nat.c (store_cregs_to_thread): Implement.
(aarch64_linux_nat_target::store_registers): Don't fetch the C
registers before writing to them.
Fetch GPR's after modifying the C registers.
* aarch64-tdep.c (aarch64_cannot_store_register): Remove C registers
write restriction.
* regcache.c (regcache_write_pc): Handle partial writes to PCC.
gdbserver/ChangeLog:
2021-01-15 Luis Machado <luis.machado@arm.com>
* linux-aarch64-low.cc (aarch64_fill_cregset): New function.
(aarch64_regsets, aarch64_sve_regsets): Add C registers fill hook.
Luis Machado [Mon, 21 Dec 2020 14:44:23 +0000 (11:44 -0300)]
Read capability tags from memory
This patch enables capability reads from memory, including the tag bit.
It enables both native GDB and gdbserver to do so.
gdb/ChangeLog:
2021-01-15 Luis Machado <luis.machado@arm.com>
* aarch64-linux-nat.c (aarch64_linux_nat_target)
<read_capability>: New function override.
(aarch64_linux_nat_target::read_capability): New function.
(maint_print_cap_from_addr_cmd): New function.
(add_show_debug_regs_command): Register new maintenance command.
* aarch64-linux-tdep.c: Include target.h.
(aarch64_linux_get_cap_tag_from_address): New function.
(aarch64_linux_init_abi): Register hook for
gdbarch_get_cap_tag_from_address
* arch-utils.c (default_get_cap_tag_from_address): New function.
* arch-utils.h (default_get_cap_tag_from_address): New prototype.
* configure.nat: Add nat/aarch64-cap-linux.o to the list of object
files for AArch64-Linux.
* gdbarch.c: Regenerate.
* gdbarch.h: Regenerate.
* gdbarch.sh (get_cap_tag_from_address): New gdbarch hook.
* nat/aarch64-cap-linux.c: New file.
* nat/aarch64-cap-linux.h (aarch64_linux_read_capability): New
prototype.
* remote.c (remote_target) <read_capability>: New function override.
(PACKET_qXfer_capability): New enum.
(remote_target::xfer_partial): Handle TARGET_OBJECT_CAPABILITY.
(remote_target::read_capability): New member function.
(_initialize_remote): Add new packet configuration.
* target-delegates.c: Regenerate.
* target.c (target_read_capability): New function.
* target.h (target_object) <TARGET_OBJECT_CAPABILITY>: New enum field.
(struct target_ops) <read_capability>: New virtual member function.
(target_read_capability): New prototype.
* valprint.c (generic_value_print_capability): Handle tags from
capabilities stored in memory.
* value.c (value_fetch_lazy_memory): Fetch tag if reading a capability.
gdbserver/ChangeLog
2021-01-15 Luis Machado <luis.machado@arm.com>
* configure.srv: Add nat/aarch64-cap-linux.o to the list of object
files for AArch64-Linux
* linux-aarch64-low.cc (aarch64_target) <supports_qxfer_capability>
<qxfer_capability>: New member function overrides.
(aarch64_target::supports_qxfer_capability): New function.
(aarch64_target::qxfer_capability): New function.
* server.cc (handle_qxfer_capability): New function.
(qxfer_packets): Add "capa" packet.
* target.cc (process_stratum_target::supports_qxfer_capability)
(process_stratum_target::qxfer_capability): New functions.
* target.h (process_stratum_target) <supports_qxfer_capability>
<qxfer_capability>: New virtual member functions.
Luis Machado [Fri, 18 Dec 2020 16:33:36 +0000 (13:33 -0300)]
Add switch to control compact/verbose printing of capabilities
Add a new option set/show "print compact-capabilities" that default to "on".
This makes GDB default to printing capabilities in compact format, the CHERI
format.
gdb/ChangeLog:
2020-12-30 Luis Machado <luis.machado@arm.com>
* valprint.c (user_print_options): Initialize compact_capabilities.
(show_print_compact_capabilities): New function.
(generic_value_print_capability): Use compact_capabilities option.
(value_print_option_defs): New compact_capabilities option.
* valprint.h (value_print_options) <compact_capabilities>: New member
variable.
Luis Machado [Tue, 15 Dec 2020 18:41:29 +0000 (15:41 -0300)]
CHERI-style compact printing format
This patch adds CHERI-style compact printing format to GDB and uses it
by default.
The format is described here: https://github.com/CTSRD-CHERI/cheri-c-programming/wiki/Displaying-Capabilities
gdbsupport/ChangeLog:
2020-12-16 Luis Machado <luis.machado@arm.com>
* capability.cc (cap_short_perms_strings): Remove.
(capability::is_null_derived): New member function.
(capability::to_str): Document and handle new CHERY-style printing
format.
* capability.h (cap_constants): Document the CAP_SEAL_TYPE_*
constants.
(struct capability) <is_null_derived>: New member function prototype.
Luis Machado [Thu, 5 Nov 2020 16:10:08 +0000 (13:10 -0300)]
Print shorter version of decoded capabilities
In order to produce output that is not so verbose, we print the short version
of the decoded capabilities instead.
gdb/ChangeLog:
2020-11-11 Luis Machado <luis.machado@arm.com>
* valprint.c (generic_value_print_capability): Use compact form.
gdbsupport/ChangeLog:
2020-11-11 Luis Machado <luis.machado@arm.com>
* capability.cc (cap_short_perms_strings): New static global.
(capability::to_str): New argument COMPACT. Print contents based
on the new argument.
(capability::print): Update calls.
* capability.h (capability::to_str): Update prototype and
documentation.
Luis Machado [Wed, 4 Nov 2020 19:13:05 +0000 (16:13 -0300)]
Support casting capabilities/capability pointers to other types
When casting capabilities and capability pointers to other types, we truncate
the value to the appropriate size, given some capabilities are greater than
8 bytes in size.
gdb/ChangeLog:
2020-11-11 Luis Machado <luis.machado@arm.com>
* valops.c (value_cast): Handle casting from capabilities and
capability pointers.
Luis Machado [Wed, 28 Oct 2020 18:56:36 +0000 (15:56 -0300)]
Invert CSP/PCC and simplify access to C register numbers
This change makes the code more straightforward, since we can expect the order
of the X registers to match that of the C registers. That way we don't have to
deal with ordering issues.
It also simplifies the access to the dynamic C register numbers through the
gdbarch tdep data structure.
gdb/ChangeLog:
2020-11-11 Luis Machado <luis.machado@arm.com>
* aarch64-linux-nat.c (fetch_cregs_from_thread): Invert pcc/csp
order.
* aarch64-linux-tdep.c (aarch64_linux_sigframe_init): Likewise.
* aarch64-tdep.c (aarch64_c_register_names): Likewise.
(aarch64_analyze_prologue): Remove code to handle csp/pcc ordering
issues.
(aarch64_prologue_prev_register): Use new tdep fields.
(aarch64_dwarf2_prev_register): Use new tdep fields and handle lr/clr.
(aarch64_dwarf2_frame_init_reg): Use new tdep fields.
(aarch64_gdbarch_init): Initialize the new tdep fields.
* aarch64-tdep.h (gdbarch_tdep) <cap_reg_clr, cap_reg_csp>
<cap_reg_pcc, cap_reg_rcsp>: New fields
* features/aarch64-capability.c: Regenerate.
* features/aarch64-capability.xml: Invert pcc/csp.
Luis Machado [Mon, 19 Oct 2020 21:46:49 +0000 (18:46 -0300)]
[Morello] Add preliminary core file register set support
Add the register set that is going to be used to read core file data.
gdb/ChangeLog:
2020-10-20 Luis Machado <luis.machado@arm.com>
* aarch64-linux-tdep.c (aarch64_linux_cregmap)
(aarch64_linux_cregset): New structs.
(aarch64_linux_iterate_over_regset_sections): Check for capability
registers.
(aarch64_linux_init_abi): Initialize C register set numbers.
Luis Machado [Mon, 19 Oct 2020 20:32:52 +0000 (17:32 -0300)]
[Morello] Fixup manual unwinding without DWARF
Given the use of C registers implies we now have to store 16 bytes worth of
data instead of 8 bytes, we need to adjust the code that handles tracking
register motion and register saving to the stack.
FIXME-Morello: This patch requires changes to opcodes/aarch64-tbl.h so the
a64c instructions carry the proper iclass and opcode information.
Right now, some of the a64c instructions don't carry enough information for
the prologue analyzer to distinguish/group them.
This patch also adds more debugging output.
gdb/ChangeLog:
2020-10-20 Luis Machado <luis.machado@arm.com>
* aarch64-tdep.c (aarch64_analyze_prologue): Handle C registers and
a64c instructions.
(aarch64_scan_prologue): Add debugging output.
* prologue-value.c (pv_area::find_reg): Don't match the register size
exactly, but check if the area size is at least the size of a register.
Luis Machado [Fri, 9 Oct 2020 16:50:17 +0000 (13:50 -0300)]
[Morello] Unwinding: Restore CLR and PCC properly
This patch teaches GDB how to handle restoring CLR and PCC values properly.
gdb/ChangeLog:
2020-10-20 Luis Machado <luis.machado@arm.com>
* aarch64-tdep.c (aarch64_prologue_prev_register): Use LR or CLR
depending on the request.
(aarch64_dwarf_reg_to_regnum): Redirect CLR to LR temporarily.
* aarch64-tdep.h (AARCH64_DWARF_CLR): New constant.
Luis Machado [Wed, 9 Sep 2020 16:09:47 +0000 (13:09 -0300)]
[Morello] Enable DWARF unwinding with C registers
Adjust unwinding functions to cope with the presence of C registers.
gdb/ChangeLog:
2020-10-20 Luis Machado <luis.machado@arm.com>
* aarch64-tdep.c (aarch64_prologue_prev_register): Handle the PCC and
CSP registers. Remove the LSB.
(aarch64_dwarf2_prev_register): Handle CSP, PCC and remove the LSB
from CLR.
(aarch64_dwarf2_frame_init_reg): Handle PCC and CSP.
(aarch64_dwarf_reg_to_regnum): Handle C registers.
Luis Machado [Thu, 1 Oct 2020 18:59:23 +0000 (15:59 -0300)]
[Morello] Record mapping symbols and mark C64 function symbols as special
This patch teaches GDB about AArch64 mapping symbols and special minimal
symbols.
FIXME-Morello: This is currently not actively used, but will be used to detect
capability mode functions later.
gdb/ChangeLog:
2020-10-20 Luis Machado <luis.machado@arm.com>
* aarch64-tdep.c: Include elf-bfd.h.
(MSYMBOL_SET_SPECIAL, MSYMBOL_IS_SPECIAL): New constants.
(aarch64_mapping_symbol): New struct.
(aarch64_mapping_symbol_vec): New typedef.
(aarch64_per_bfd): New struct.
(aarch64_bfd_data_key): New static global.
(aarch64_elf_make_msymbol_special, +aarch64_record_special_symbol): New
function.
(aarch64_gdbarch_init): Register hooks.
Luis Machado [Mon, 28 Sep 2020 19:32:03 +0000 (16:32 -0300)]
[Morello] Disable displaced stepping for Morello
Morello can't support displaced stepping at the moment given it has no API
to write capabilities, which is needed when GDB needs to adjust the X and C
registers during a displaced stepping operation.
gdb/ChangeLog:
2020-10-20 Luis Machado <luis.machado@arm.com>
* aarch64-linux-tdep.c (aarch64_linux_init_abi): Only set displaced
stepping hooks for non-Morello targets.
Luis Machado [Thu, 24 Sep 2020 18:09:24 +0000 (15:09 -0300)]
[Morello] Add support for Morello sigreturn/sigcontext frame
This patch teaches GDB how to interpret the Morello sigcontext
structure in a sigreturn frame and allows GDB to read back the
correct values of the registers.
gdb/ChangeLog:
2020-10-20 Luis Machado <luis.machado@arm.com>
* aarch64-linux-tdep.c: Include arch/aarch64-insn.h.
(AARCH64_MORELLO_MAGIC, AARCH64_MORELLO_SIGCONTEXT_SIZE)
(AARCH64_MORELLO_SIGCONTEXT_C0_OFFSET): New constants.
(aarch64_linux_sigframe_init): Update to handle Morello
sigreturn/sigcontext frames.
projects / thirdparty / binutils-gdb.git / log
