This was missed when support for the insns was added. Just like for
DATA16, in
rex64 neg (%rax)
rex64 neg (%r16)
rex64 {nf} neg (%rax)
it is not logical why the last one shouldn't be permitted. Bypassing
that check requires other adjustments, though, to actually properly
consume (and then squash) the prefix.
Enable full 32-bit and 64-bit multiplication macro verification, by
splitting the 'mul' test into two parts respectively, and run them
across all the compatible architectures.
The multiplication macros expand differently based on the ISA chosen, so
run the 'mul' macro test across compatible architectures, adopting the
'mul-ilocks' test orphaned by commit 23fce1e311 ("MIPS16 intermix test
failure"), <https://sourceware.org/ml/binutils/2009-01/msg00335.html>,
and providing coverage for the expansion variants.
Only run from MIPS III up for now and remove the ISA override from the
source, so that the 64-bit instructions are covered for individual
64-bit architectures.
Enable full 32-bit and 64-bit division macro verification, by splitting
the 'div' test into two parts respectively, and run them across all the
compatible architectures.
The division macros expand differently depending on the ISA selected, so
run the 'div' macro test across compatible architectures, adopting the
'div-ilocks' test orphaned by commit 23fce1e311 ("MIPS16 intermix test
failure"), <https://sourceware.org/ml/binutils/2009-01/msg00335.html>,
and providing coverage for the expansion variants.
Only run from MIPS III up for now and remove the ISA override from the
source, so that the 64-bit instructions are covered for individual
64-bit architectures.
We have an ISA check for the '--trap' command-line option that reports
its incompatibility with the MIPS I architecture. It doesn't prevent
trap instructions from being enabled though, so when attempt is made to
emit one in an expansion of one of the division or multiplication macros
an assertion failure triggers:
.../gas/testsuite/gas/mips/brtr-opt.s: Assembler messages:
.../gas/testsuite/gas/mips/brtr-opt.s:3: Error: trap exception not supported at ISA 1
.../gas/testsuite/gas/mips/brtr-opt.s:9: Warning: divide by zero
.../gas/testsuite/gas/mips/brtr-opt.s:9: Internal error in macro_build at .../gas/config/tc-mips.c:9064.
Please report this bug.
The same assertion failure triggers without an earlier error message
when the initial ISA is compatible with the '--trap', however at the
time an attempt is made to emit a trap instruction from a division or
multiplication macro the ISA has been changed by a '.set' pseudo-op to
an incompatible one.
With the way the situations are mishandled it seems unlikely that anyone
relies on the current semantics and a sane approach is to decide on the
fly according to the currently selected ISA as to whether to emit trap
or breakpoint instructions in the case where '--trap' has been used.
Change our code to do so then and clarify that in the manual, which is
not explicit about how '--trap' is handled with a changing ISA. Mention
the change in NEWS too since it's a applies to a user option.
Add a fully interlocked MIPS IV CPU so that we can have coverage for
MIPS IV instruction sequences with and without instruction separation
required for a HI/LO data anti-dependency.
Similar to the x86_64 testcases, some .s files contain the corresponding
CFI directives. This helps in validating the synthesized CFI by running
those tests with and without the --scfi=experimental command line
option.
GAS issues some diagnostics, enabled by default, with
--scfi=experimental. The diagnostics have been added with an intent to
help user correct inadvertent errors in their hand-written asm. An
error is issued when GAS finds that input asm is not amenable to
accurate CFI synthesis. The existing scfi-diag-*.s tests in the
gas/testsuite/gas/scfi/x86_64 directory test some SCFI diagnostics
already:
- (#1) "Warning: SCFI: Asymetrical register restore"
- (#2) "Error: SCFI: usage of REG_FP as scratch not supported"
- (#3) "Error: SCFI: unsupported stack manipulation pattern"
- (#4) "Error: untraceable control flow for func 'XXX'"
In the newly added aarch64 testsuite, further tests for additional
diagnostics have been added:
- scfi-diag-1.s in this patch highlights an aarch64-specific diagnostic:
(#5) "Warning: SCFI: ignored probable save/restore op with reg offset"
Additionally, some testcases are added to showcase the (currently)
unsupported patterns, e.g., scfi-unsupported-1.s
mov x16, 4384
sub sp, sp, x16
gas/testsuite/:
* gas/scfi/README: Update comment to include aarch64.
* gas/scfi/aarch64/scfi-aarch64.exp: New file.
* gas/scfi/aarch64/ginsn-arith-1.l: New test.
* gas/scfi/aarch64/ginsn-arith-1.s: New test.
* gas/scfi/aarch64/ginsn-cofi-1.l: New test.
* gas/scfi/aarch64/ginsn-cofi-1.s: New test.
* gas/scfi/aarch64/ginsn-ldst-1.l: New test.
* gas/scfi/aarch64/ginsn-ldst-1.s: New test.
* gas/scfi/aarch64/scfi-callee-saved-fp-1.d: New test.
* gas/scfi/aarch64/scfi-callee-saved-fp-1.l: New test.
* gas/scfi/aarch64/scfi-callee-saved-fp-1.s: New test.
* gas/scfi/aarch64/scfi-callee-saved-fp-2.d: New test.
* gas/scfi/aarch64/scfi-callee-saved-fp-2.l: New test.
* gas/scfi/aarch64/scfi-callee-saved-fp-2.s: New test.
* gas/scfi/aarch64/scfi-cb-1.d: New test.
* gas/scfi/aarch64/scfi-cb-1.l: New test.
* gas/scfi/aarch64/scfi-cb-1.s: New test.
* gas/scfi/aarch64/scfi-cfg-1.d: New test.
* gas/scfi/aarch64/scfi-cfg-1.l: New test.
* gas/scfi/aarch64/scfi-cfg-1.s: New test.
* gas/scfi/aarch64/scfi-cfg-2.d: New test.
* gas/scfi/aarch64/scfi-cfg-2.l: New test.
* gas/scfi/aarch64/scfi-cfg-2.s: New test.
* gas/scfi/aarch64/scfi-cfg-3.d: New test.
* gas/scfi/aarch64/scfi-cfg-3.l: New test.
* gas/scfi/aarch64/scfi-cfg-3.s: New test.
* gas/scfi/aarch64/scfi-cfg-4.l: New test.
* gas/scfi/aarch64/scfi-cfg-4.s: New test.
* gas/scfi/aarch64/scfi-cond-br-1.d: New test.
* gas/scfi/aarch64/scfi-cond-br-1.l: New test.
* gas/scfi/aarch64/scfi-cond-br-1.s: New test.
* gas/scfi/aarch64/scfi-diag-1.l: New test.
* gas/scfi/aarch64/scfi-diag-1.s: New test.
* gas/scfi/aarch64/scfi-diag-2.l: New test.
* gas/scfi/aarch64/scfi-diag-2.s: New test.
* gas/scfi/aarch64/scfi-diag-3.l: New test.
* gas/scfi/aarch64/scfi-diag-3.s: New test.
* gas/scfi/aarch64/scfi-ldrp-1.d: New test.
* gas/scfi/aarch64/scfi-ldrp-1.l: New test.
* gas/scfi/aarch64/scfi-ldrp-1.s: New test.
* gas/scfi/aarch64/scfi-ldrp-2.d: New test.
* gas/scfi/aarch64/scfi-ldrp-2.l: New test.
* gas/scfi/aarch64/scfi-ldrp-2.s: New test.
* gas/scfi/aarch64/scfi-ldstnap-1.d: New test.
* gas/scfi/aarch64/scfi-ldstnap-1.l: New test.
* gas/scfi/aarch64/scfi-ldstnap-1.s: New test.
* gas/scfi/aarch64/scfi-strp-1.d: New test.
* gas/scfi/aarch64/scfi-strp-1.l: New test.
* gas/scfi/aarch64/scfi-strp-1.s: New test.
* gas/scfi/aarch64/scfi-strp-2.d: New test.
* gas/scfi/aarch64/scfi-strp-2.l: New test.
* gas/scfi/aarch64/scfi-strp-2.s: New test.
* gas/scfi/aarch64/scfi-unsupported-1.l: New test.
* gas/scfi/aarch64/scfi-unsupported-1.s: New test.
* gas/scfi/aarch64/scfi-unsupported-2.l: New test.
* gas/scfi/aarch64/scfi-unsupported-2.s: New test.
For synthesizing CFI (SCFI) for hand-written asm, the SCFI machinery in
GAS works on the generic GAS insns (ginsns). This patch adds support in
the aarch64 backend to create ginsns for a subset of the supported
machine instructions. The subset includes the minimal necessary
instructions to ensure SCFI correctness:
- Any potential register saves and unsaves. Hence, process instructions
belonging to a variety of iclasses involving str, ldr, stp, ldp.
- Any change of flow instructions. This includes all conditional and
unconditional branches, call (bl, blr, etc.) and return.
- Most importantly, any instruction that could affect the two registers
of interest: REG_SP, REG_FP. This set includes all pre-indexed and
post-indexed memory operations, with writeback, on the stack. This
set must also include other instructions (e.g., arithmetic insns)
where the destination register is one of the afore-mentioned registers.
With respect to callee-saved registers in Aarch64, FP/Advanced SIMD
registers D8-D15 are included along with the relevant GPRs. Calculating
offsets for loads and stores especially for Q registers needs special
attention here.
As an example,
str q8, [sp, #16]
On big-endian:
STR Qn stores as a 128-bit integer (MSB first), hence, should record
D8 as being saved at sp+24 rather than sp+16.
On little-endian:
should record D8 as being saved at sp+16
D8-D15 are the low 64 bits of Q8-Q15, and of Z8-Z15 if SVE is used;
hence, they remain "interesting" for SCFI purposes in such cases. A CFI
save slot always represents the low 64 bits, regardless of whether a
save occurs on D, Q or Z registers. Currently, the ginsn creation
machinery can handle D and Q registers on little-endian and big-endian.
Apart from creating ginsn, another key responsibility of the backend is
to make sure there are safeguards in place to detect and alert if an
instruction of interest may have been skipped. This is done via
aarch64_ginsn_unhandled () (similar to the x86 backend). This function
, hence, is also intended to alert when future ISA changes may otherwise
render SCFI results incorrect, because of missing ginsns for the newly
added machine instructions.
At this time, becuase of the complexities wrt endianness in handling Z
register usage, skip sve_misc opclass altogether for now. The SCFI
machinery will error out (using the aarch64_ginsn_unhandled () code
path) though if Z register usage affects correctness.
The current SCFI machinery does not currently synthesize the
PAC-related, aarch64-specific CFI directives: .cfi_b_key_frame. The
support for this is planned for near future.
SCFI is enabled for ELF targets only.
gas/
* config/tc-aarch64-ginsn.c: New file.
* config/tc-aarch64.c (md_assemble): Include tc-aarch64-ginsn.c
file. Invoke aarch64_ginsn_new.
* config/tc-aarch64.h (TARGET_USE_GINSN): Define for SCFI
enablement.
(TARGET_USE_SCFI): Likewise.
(SCFI_MAX_REG_ID): New definition.
(REG_FP): Likewise.
(REG_LR): Likewise.
(REG_SP): Likewise.
(SCFI_INIT_CFA_OFFSET): Likewise.
(SCFI_CALLEE_SAVED_REG_P): Likewise.
(aarch64_scfi_callee_saved_p): New declaration.
Enforce some checks on the newly added subclass flags:
- If a subclass is set of one insn of an iclass, every insn of that
iclass must have non-zero subclass field.
- For all other iclasses, the subclass bits are zero for all insns.
include/
* opcode/aarch64.h (enum aarch64_insn_class): Identify the
maximum iclass enum value.
opcodes/
* aarch64-gen.c (iclass_has_subclasses_p): New array of bool.
(read_table): Enforce checks on subclass flags.
For detecting irg, add a subclass to identify it in the set of
instructions of iclass dp_2src.
opcodes/
* aarch64-tbl.h: Add subclass flag F_DP_TAG_ONLY for irg insn.
Use the two new subclass flags: F_BRANCH_CALL, F_BRANCH_RET, to indicate
call to and return from subroutine respectively.
opcodes/
* aarch64-tbl.h: Use the new F_BRANCH_* flags.
Use the three new subclass flags: F_ARITH_ADD, F_ARITH_SUB,
F_ARITH_MOV, to indicate add, sub and mov ops respectively.
These flags for subclasses will later be used for SCFI purposes to
create appropriate ginsns. At this time, only those iclasses relevant
to SCFI have the new subclass flags specified.
For addg and subg insns, F_SUBCLASS_OTHER is more suitable because these
operations do more than just simple add or sub.
opcodes/
* aarch64-tbl.h: Use the new F_ARITH_* flags.
The existing iclass information tells us the general shape and purpose
of the instructions. In some cases, however, we need to further disect
the iclass on the basis of other finer-grain information. E.g., for the
purpose of SCFI, we need to know whether a given insn with iclass
of ldst_* is a load or a store.
At the moment, specify subclasses for only those iclasses relevant to
SCFI: ldst_imm9, ldst_pos, ldstpair_indexed, ldstpair_off and
ldstnapair_offs.
Some insns are best tagged with F_SUBCLASS_OTHER rather than F_LDST_LOAD
or F_LDST_STORE:
- stg* ops (as they store tag only),
- prfm,
- ldpsw, ldrsw (32-bit loads with signed extended value. Not useful
for restore operations in context of SCFI.)
- Use F_SUBCLASS_OTHER for all QL_LDST_R8 and QL_LDST_R16 operands.
Also use F_SUBLASS_OTHER for strb/ldrb, strh/ldrh opcodes.
These are not full loads and stores and cannot be allowed for
register save / restore for the purpose of SCFI.
opcodes/
* aarch64-tbl.h: Use the new F_LDST_* flags.
The existing iclass information tells us the general shape and purpose
of the instructions. In some cases, however, we need to further disect
the iclass on the basis of other finer-grain information. E.g., for the
purpose of SCFI, we need to know whether a given insn with iclass of
ldst_* is a load or a store. Similarly, whether a particular arithmetic
insn is an add or sub or mov, etc.
This patch defines new flags to demarcate the insns. Also provide an
access function for subclass lookup.
Later, we will enforce (in aarch64-gen.c) that if an iclass has at least
one instruction with a non-zero subclass, all instructions of the iclass
must have a non-zero subclass information. If none of the defined
subclasses are applicable (or not required for SCFI purposes),
F_SUBCLASS_OTHER can be used for such instructions.
include/
* opcode/aarch64.h (F_SUBCLASS): New flag.
(F_SUBCLASS_OTHER): Likewise.
(F_LDST_LOAD): Likewise.
(F_LDST_STORE): Likewise.
(F_ARITH_ADD): Likewise.
(F_ARITH_SUB): Likewise.
(F_ARITH_MOV): Likewise.
(F_BRANCH_CALL): Likewise.
(F_BRANCH_RET): Likewise.
(F_DP_TAG_ONLY): Likewise.
(aarch64_opcode_subclass_p): New definition.
When the SCFI machinery detects that a register has been restored from
stack, it makes some state changes in the SCFI state object.
Prior to the patch, scfi_state_restore_reg () was setting a value of
(reg, CFI_IN_REG) for (base, state) respectively. This was causing
issues in the cmp_scfi_state () function:
- The default state of all (callee-saved) regs at the beginning of
function is set to (0, CFI_UNDEFINED).
- If a register is saved and restored on some control path, the state
of reg is (reg, CFI_IN_REG) on that path.
- On another control path where the register was perhaps not
used (or saved/restored on stack) remains (0, CFI_UNDEFINED).
- The two states should be treated equal, however, at the point in
program after the register has been restored.
Fix this by resetting the state to (0, CFI_UNDEFINED) in
scfi_state_restore_reg ().
A testcase (scfi-cfg-4.s) for this is added in a subsequent commit.
gas/
* scfi.c (scfi_state_restore_reg): Reset to 0, CFI_UNDEFINED
for base, state.
- help message: add a comma between the short and long option
- as doc:
- brief summary of how to invoke gas: separate [-w] [-x] on a new line as those
two options have nothing to do with the warning options.
- reordering of the warning options to have the same order as the listing.
- no-warn option description: change an "and" to a "or", as it is either the short
or long option to use, but not both at the same time.
- remove trailing whitespaces.
Within the debug-file-directory GDB looks for the existence of a
.build-id directory.
Within the .build-id directory GDB looks for files with the form:
.build-id/ff/4b4142d62b399499844924d53e33d4028380db.debug
which contain the debug information for the objfile with the build-id
ff4b4142d62b399499844924d53e33d4028380db.
There appear to be two strategies for populating the .build-id
directory. Ubuntu takes the approach of placing the actual debug
information in this directory, so
4b4142d62b399499844924d53e33d4028380db.debug is an actual file
containing the debug information.
Fedora, RHEL, and SUSE take a slightly different approach, placing the
debug information elsewhere, and then creating symlinks in the
.build-id directory back to the original debug information file. The
actual debug information is arranged in a mirror of the filesystem
within the debug directory, as an example, if the debug-file-directory
is /usr/lib/debug, then the debug information for /bin/foo can be
found in /usr/lib/debug/bin/foo.debug.
Where this gets interesting is that in some cases a package will
install a single binary with multiple names, in this case a single
binary will be install with either hard-links, or symlinks providing
the alternative names.
The debug information for these multiple binaries will then be placed
into the /usr/lib/debug/ tree, and again, links are created so a
single file can provide debug information for each of the names that
binary presents as. An example file system might look like this (the
[link] could be symlinks, but are more likely hard-links):
/bin/
foo
bar -> foo [ HARD LINK ]
baz -> foo [ HARD LINK ]
/usr/
lib/
debug/
bin/
foo.debug
bar.debug -> foo.debug [ HARD LINK ]
baz.debug -> foo.debug [ HARD LINK ]
In the .build-id tree though we have a problem. Do we have a single
entry that links to one of the .debug files? This would work; a user
debugging any of the binaries will find the debug information based on
the build-id, and will get the correct information, after all the
.debug files are identical (same file linked together). But there is
one problem with this approach.
Sometimes, for *reasons* it's possible that one or more the linked
binaries might get removed, along with its associated debug
information. I'm honestly not 100% certain under what circumstances
this can happen, but what I observe is that sometime a single name for
a binary, and its corresponding .debug entry, can be missing. If this
happens to be the entry that the .build-id link is pointing at, then
we have a problem. The user can no longer find the debug information
based on the .build-id link.
The solution that Fedora, RHEL, & SUSE have adopted is to add multiple
entries in the .build-id tree, with each entry pointing to a different
name within the debug/ tree, a sequence number is added to the
build-id to distinguish the multiple entries. Thus, we might end up
with a layout like this:
/bin/
foo
bar -> foo [ HARD LINK ]
baz -> foo [ HARD LINK ]
/usr/
lib/
debug/
bin/
foo.debug
bar.debug -> foo.debug [ HARD LINK ]
baz.debug -> foo.debug [ HARD LINK ]
.build-id/
a3/
4b4142d62b399499844924d53e33d4028380db.debug -> ../../debug/bin/foo.debug [ SYMLINK ]
4b4142d62b399499844924d53e33d4028380db.1.debug -> ../../debug/bin/bar.debug [ SYMLINK ]
4b4142d62b399499844924d53e33d4028380db.2.debug -> ../../debug/bin/baz.debug [ SYMLINK ]
With current master GDB, debug information will only ever be looked up
via the 4b4142d62b399499844924d53e33d4028380db.debug link. But if
'foo' and its corresponding 'foo.debug' are ever removed, then master
GDB will fail to find the debug information.
Ubuntu seems to have a much better approach for debug information
handling; they place the debug information directly into the .build-id
tree, so there only ever needs to be a single entry for any one
build-id. I wonder if/how they handle the case where multiple names
might share a single .debug file, if one of those names is then
uninstalled, how do they know the .debug file should be retained or
not ... but I assume that problem either doesn't exist or has been
solved.
Anyway, for a while Fedora has carried a patch that handles the
build-id sequence number logic. What's presented here is inspired by
the Fedora patch, but has some changes to fix some issues.
I'm aware that this is a patch that applies to only some (probably a
minority) of distros. However, the logic is contained to only a
single function in build-id.c, and isn't too complex, so I'm hoping
that there wont be too many objections.
For distros that don't have build-id sequence numbers there should be
no impact. The sequence number approach still leaves the first file
without a sequence number, and this is the first file that GDB (after
this patch) checks for. The new logic only kicks in if the
non-sequence numbered first file exists, but is a symlink to a non
existent file; in this case GDB checks for the sequence numbered files
instead.
Tests are included.
There is a small fix needed for gdb.base/sysroot-debug-lookup.exp,
after this commit GDB now treats a target: sysroot where the target
file system is local to GDB the same as if the sysroot had no target:
prefix. The consequence of this is that GDB now resolves a symlink
back to the real filename in the sysroot-debug-lookup.exp test where
it didn't previously. As this behaviour is inline with the case where
there is no target: prefix I think this is fine.
After the previous two commits, this commit adds support for the
vFile::stat packet to gdbserver. This is pretty similar to the
handling for vFile::fstat, but instead calls 'lstat'.
There's still no users of target_fileio_stat in GDB, that will come in
a later commit.
This commit adds the GDB side of target_ops::fileio_stat. There's an
implementation for inf_child_target, which just calls 'lstat', and
there's an implementation for remote_target, which sends a new
vFile:stat packet.
The new packet is documented.
There's still no users of target_fileio_stat as I have not yet added
support for vFile::stat to gdbserver. If these packets are currently
sent to gdbserver then they will be reported as not supported and the
ENOSYS error code will be returned.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
In a later commit I want target_fileio_stat, that is a call that
operates on a filename rather than an open file descriptor as
target_fileio_fstat does.
This commit adds the initial framework for target_fileio_stat, I've
added the top level target function and the virtual target_ops methods
in the target_ops base class.
At this point no actual targets override target_ops::fileio_stat, so
any attempts to call this function will return ENOSYS error code.
When running test-case gdb.arch/arm-pseudo-unwind.exp with target board
unix/mthumb, we run into:
...
(gdb) continue^M
Continuing.^M
^M
Program received signal SIGILL, Illegal instruction.^M
0x00400f38 in ?? ()^M
(gdb) FAIL: $exp: continue to breakpoint: continue to callee
...
The test-case attempts to force arm-pseudo-unwind.c to be compiled in arm mode
using additional_flags=-marm, but that's overridden by using target board
unix/mthumb.
This causes function main to be in thumb mode, and consequently function
caller (which is called from main) is is executed as if it's in thumb mode,
while it's actually in arm mode.
Fix this by adding an intermediate function caller_trampoline in
arm-pseudo-unwind.c, and hardcoding it to arm mode using
__attribute__((target("arm"))).
Likewise for test-case gdb.arch/arm-pseudo-unwind-legacy.exp.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
C++ 11 has a built-in attribute for this, no need to use a compat macro.
Change-Id: I90e4220d26e8f3949d91761f8a13cd9c37da3875
Reviewed-by: Lancelot Six <lancelot.six@amd.com>
I noticed a lot of escaping in test-case gdb.base/complex-parts.exp.
Make the test-case more readable by using:
- string_to_regexp, and
- {} instead of "".
Tested on x86_64-linux and aarch64-linux.
Make the current program space reference bubble up one level.
Change-Id: Iee8b11c853c76e539c991c4785737c69e6a1925c
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space reference bubble up one level.
Change-Id: I81e45e89e0cfd87c308f801d49ae811a941348b7
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space reference bubble up one level.
Change-Id: Ifc9b8186abaefb10caf99f79ae09e526fa65c882
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space bubble up one level.
Change-Id: Ic3ad0869ca1afe41854f605a6f7eb092fca29ff8
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space reference bubble up one level.
Change-Id: I9b33c9e0d22c171eb1bb59ce480621b02c7b7bf7
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space reference bubble up one level.
Change-Id: I6ba6dc4a2cb188720cbb61b84ab5c954aac105c6
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space reference bubble up one level.
Change-Id: I19c4fc2ca955f9c828ef426a077b43983865697b
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Change return types to bool, and make a few stylistic adjustments.
Change-Id: I784c3c33af0394a77c25064b06eb3e128e69222f
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space reference bubble up one level.
Change-Id: I692554474d17e4f4708fd8ad662bf6c0bb964726
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Use `this` instead of `current_program_space`. Presumably, the method
wants to check the solibs of "this" program space, not the current
global program space (although they are likely always the same at the
moment).
Change-Id: Iaf0534f36bfd47c04c53ed0657da332bdb8fb906
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space reference bubble up one level. Pass
`current_program_space` everywhere, except in some cases where we can
get the pspace another way, and it's relatively obvious that it's the
same as the current program space.
Change-Id: Id86b79f1e44f92a398f49d137d57457174dfa96d
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
The `no_shared_libraries` function is currently used to implement the
`nosharedlibrary` command, but it also used internally by other
functions. This does not make a very good internal API.
Add the `no_shared_libraries_command` function to implement the CLI
command. Remove the unused parameters from `no_shared_libraries`.
Remove the `from_tty` parameter of `target_pre_inferior`, since it's now
unused.
Change-Id: I4fcba5ee1e0f7d250aab1a7b62b9ea16265fe962
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Make the current program space reference bubble up one level.
Change-Id: I08cfa77a0351c9602131ed2a294eabb1f1f59a6e
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
