2004-02-01 22:35:24 +00:00
|
|
|
/* Auxiliary vector support for GDB, the GNU debugger.
|
|
|
|
|
2023-01-01 16:49:04 +04:00
|
|
|
Copyright (C) 2004-2023 Free Software Foundation, Inc.
|
2004-02-01 22:35:24 +00:00
|
|
|
|
|
|
|
This file is part of GDB.
|
|
|
|
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
2007-08-23 18:08:50 +00:00
|
|
|
the Free Software Foundation; either version 3 of the License, or
|
2004-02-01 22:35:24 +00:00
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
2007-08-23 18:08:50 +00:00
|
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
2004-02-01 22:35:24 +00:00
|
|
|
|
|
|
|
#include "defs.h"
|
2019-04-06 13:38:10 -06:00
|
|
|
#include "target.h"
|
2019-04-02 20:04:24 -06:00
|
|
|
#include "gdbtypes.h"
|
2019-04-06 13:38:10 -06:00
|
|
|
#include "command.h"
|
2019-04-02 20:04:24 -06:00
|
|
|
#include "inferior.h"
|
|
|
|
#include "valprint.h"
|
2019-04-06 13:38:10 -06:00
|
|
|
#include "gdbcore.h"
|
|
|
|
#include "observable.h"
|
Rename common to gdbsupport
This is the next patch in the ongoing series to move gdbsever to the
top level.
This patch just renames the "common" directory. The idea is to do
this move in two parts: first rename the directory (this patch), then
move the directory to the top. This approach makes the patches a bit
more tractable.
I chose the name "gdbsupport" for the directory. However, as this
patch was largely written by sed, we could pick a new name without too
much difficulty.
Tested by the buildbot.
gdb/ChangeLog
2019-07-09 Tom Tromey <tom@tromey.com>
* contrib/ari/gdb_ari.sh: Change common to gdbsupport.
* configure: Rebuild.
* configure.ac: Change common to gdbsupport.
* gdbsupport: Rename from common.
* acinclude.m4: Change common to gdbsupport.
* Makefile.in (CONFIG_SRC_SUBDIR, COMMON_SFILES)
(HFILES_NO_SRCDIR, stamp-version, ALLDEPFILES): Change common to
gdbsupport.
* aarch64-tdep.c, ada-lang.c, ada-lang.h, agent.c, alloc.c,
amd64-darwin-tdep.c, amd64-dicos-tdep.c, amd64-fbsd-nat.c,
amd64-fbsd-tdep.c, amd64-linux-nat.c, amd64-linux-tdep.c,
amd64-nbsd-tdep.c, amd64-obsd-tdep.c, amd64-sol2-tdep.c,
amd64-tdep.c, amd64-windows-tdep.c, arch-utils.c,
arch/aarch64-insn.c, arch/aarch64.c, arch/aarch64.h, arch/amd64.c,
arch/amd64.h, arch/arm-get-next-pcs.c, arch/arm-linux.c,
arch/arm.c, arch/i386.c, arch/i386.h, arch/ppc-linux-common.c,
arch/riscv.c, arch/riscv.h, arch/tic6x.c, arm-tdep.c, auto-load.c,
auxv.c, ax-gdb.c, ax-general.c, ax.h, breakpoint.c, breakpoint.h,
btrace.c, btrace.h, build-id.c, build-id.h, c-lang.h, charset.c,
charset.h, cli/cli-cmds.c, cli/cli-cmds.h, cli/cli-decode.c,
cli/cli-dump.c, cli/cli-option.h, cli/cli-script.c,
coff-pe-read.c, command.h, compile/compile-c-support.c,
compile/compile-c.h, compile/compile-cplus-symbols.c,
compile/compile-cplus-types.c, compile/compile-cplus.h,
compile/compile-loc2c.c, compile/compile.c, completer.c,
completer.h, contrib/ari/gdb_ari.sh, corefile.c, corelow.c,
cp-support.c, cp-support.h, cp-valprint.c, csky-tdep.c, ctf.c,
darwin-nat.c, debug.c, defs.h, disasm-selftests.c, disasm.c,
disasm.h, dtrace-probe.c, dwarf-index-cache.c,
dwarf-index-cache.h, dwarf-index-write.c, dwarf2-frame.c,
dwarf2expr.c, dwarf2loc.c, dwarf2read.c, event-loop.c,
event-top.c, exceptions.c, exec.c, extension.h, fbsd-nat.c,
features/aarch64-core.c, features/aarch64-fpu.c,
features/aarch64-pauth.c, features/aarch64-sve.c,
features/i386/32bit-avx.c, features/i386/32bit-avx512.c,
features/i386/32bit-core.c, features/i386/32bit-linux.c,
features/i386/32bit-mpx.c, features/i386/32bit-pkeys.c,
features/i386/32bit-segments.c, features/i386/32bit-sse.c,
features/i386/64bit-avx.c, features/i386/64bit-avx512.c,
features/i386/64bit-core.c, features/i386/64bit-linux.c,
features/i386/64bit-mpx.c, features/i386/64bit-pkeys.c,
features/i386/64bit-segments.c, features/i386/64bit-sse.c,
features/i386/x32-core.c, features/riscv/32bit-cpu.c,
features/riscv/32bit-csr.c, features/riscv/32bit-fpu.c,
features/riscv/64bit-cpu.c, features/riscv/64bit-csr.c,
features/riscv/64bit-fpu.c, features/tic6x-c6xp.c,
features/tic6x-core.c, features/tic6x-gp.c, filename-seen-cache.h,
findcmd.c, findvar.c, fork-child.c, gcore.c, gdb_bfd.c, gdb_bfd.h,
gdb_proc_service.h, gdb_regex.c, gdb_select.h, gdb_usleep.c,
gdbarch-selftests.c, gdbthread.h, gdbtypes.h, gnu-nat.c,
go32-nat.c, guile/guile.c, guile/scm-ports.c,
guile/scm-safe-call.c, guile/scm-type.c, i386-fbsd-nat.c,
i386-fbsd-tdep.c, i386-go32-tdep.c, i386-linux-nat.c,
i386-linux-tdep.c, i386-tdep.c, i387-tdep.c,
ia64-libunwind-tdep.c, ia64-linux-nat.c, inf-child.c,
inf-ptrace.c, infcall.c, infcall.h, infcmd.c, inferior-iter.h,
inferior.c, inferior.h, inflow.c, inflow.h, infrun.c, infrun.h,
inline-frame.c, language.h, linespec.c, linux-fork.c, linux-nat.c,
linux-tdep.c, linux-thread-db.c, location.c, machoread.c,
macrotab.h, main.c, maint.c, maint.h, memattr.c, memrange.h,
mi/mi-cmd-break.h, mi/mi-cmd-env.c, mi/mi-cmd-stack.c,
mi/mi-cmd-var.c, mi/mi-interp.c, mi/mi-main.c, mi/mi-parse.h,
minsyms.c, mips-linux-tdep.c, namespace.h,
nat/aarch64-linux-hw-point.c, nat/aarch64-linux-hw-point.h,
nat/aarch64-linux.c, nat/aarch64-sve-linux-ptrace.c,
nat/amd64-linux-siginfo.c, nat/fork-inferior.c,
nat/linux-btrace.c, nat/linux-btrace.h, nat/linux-namespaces.c,
nat/linux-nat.h, nat/linux-osdata.c, nat/linux-personality.c,
nat/linux-procfs.c, nat/linux-ptrace.c, nat/linux-ptrace.h,
nat/linux-waitpid.c, nat/mips-linux-watch.c,
nat/mips-linux-watch.h, nat/ppc-linux.c, nat/x86-dregs.c,
nat/x86-dregs.h, nat/x86-linux-dregs.c, nat/x86-linux.c,
nto-procfs.c, nto-tdep.c, objfile-flags.h, objfiles.c, objfiles.h,
obsd-nat.c, observable.h, osdata.c, p-valprint.c, parse.c,
parser-defs.h, ppc-linux-nat.c, printcmd.c, probe.c, proc-api.c,
procfs.c, producer.c, progspace.h, psymtab.h,
python/py-framefilter.c, python/py-inferior.c, python/py-ref.h,
python/py-type.c, python/python.c, record-btrace.c, record-full.c,
record.c, record.h, regcache-dump.c, regcache.c, regcache.h,
remote-fileio.c, remote-fileio.h, remote-sim.c, remote.c,
riscv-tdep.c, rs6000-aix-tdep.c, rust-exp.y, s12z-tdep.c,
selftest-arch.c, ser-base.c, ser-event.c, ser-pipe.c, ser-tcp.c,
ser-unix.c, skip.c, solib-aix.c, solib-target.c, solib.c,
source-cache.c, source.c, source.h, sparc-nat.c, spu-linux-nat.c,
stack.c, stap-probe.c, symfile-add-flags.h, symfile.c, symfile.h,
symtab.c, symtab.h, target-descriptions.c, target-descriptions.h,
target-memory.c, target.c, target.h, target/waitstatus.c,
target/waitstatus.h, thread-iter.h, thread.c, tilegx-tdep.c,
top.c, top.h, tracefile-tfile.c, tracefile.c, tracepoint.c,
tracepoint.h, tui/tui-io.c, ui-file.c, ui-out.h,
unittests/array-view-selftests.c,
unittests/child-path-selftests.c, unittests/cli-utils-selftests.c,
unittests/common-utils-selftests.c,
unittests/copy_bitwise-selftests.c, unittests/environ-selftests.c,
unittests/format_pieces-selftests.c,
unittests/function-view-selftests.c,
unittests/lookup_name_info-selftests.c,
unittests/memory-map-selftests.c, unittests/memrange-selftests.c,
unittests/mkdir-recursive-selftests.c,
unittests/observable-selftests.c,
unittests/offset-type-selftests.c, unittests/optional-selftests.c,
unittests/parse-connection-spec-selftests.c,
unittests/ptid-selftests.c, unittests/rsp-low-selftests.c,
unittests/scoped_fd-selftests.c,
unittests/scoped_mmap-selftests.c,
unittests/scoped_restore-selftests.c,
unittests/string_view-selftests.c, unittests/style-selftests.c,
unittests/tracepoint-selftests.c, unittests/unpack-selftests.c,
unittests/utils-selftests.c, unittests/xml-utils-selftests.c,
utils.c, utils.h, valarith.c, valops.c, valprint.c, value.c,
value.h, varobj.c, varobj.h, windows-nat.c, x86-linux-nat.c,
xml-support.c, xml-support.h, xml-tdesc.h, xstormy16-tdep.c,
xtensa-linux-nat.c, dwarf2read.h: Change common to gdbsupport.
gdb/gdbserver/ChangeLog
2019-07-09 Tom Tromey <tom@tromey.com>
* configure: Rebuild.
* configure.ac: Change common to gdbsupport.
* acinclude.m4: Change common to gdbsupport.
* Makefile.in (SFILES, OBS, GDBREPLAY_OBS, IPA_OBJS)
(version-generated.c, gdbsupport/%-ipa.o, gdbsupport/%.o): Change
common to gdbsupport.
* ax.c, event-loop.c, fork-child.c, gdb_proc_service.h,
gdbreplay.c, gdbthread.h, hostio-errno.c, hostio.c, i387-fp.c,
inferiors.c, inferiors.h, linux-aarch64-tdesc-selftest.c,
linux-amd64-ipa.c, linux-i386-ipa.c, linux-low.c,
linux-tic6x-low.c, linux-x86-low.c, linux-x86-tdesc-selftest.c,
linux-x86-tdesc.c, lynx-i386-low.c, lynx-low.c, mem-break.h,
nto-x86-low.c, regcache.c, regcache.h, remote-utils.c, server.c,
server.h, spu-low.c, symbol.c, target.h, tdesc.c, tdesc.h,
thread-db.c, tracepoint.c, win32-i386-low.c, win32-low.c: Change
common to gdbsupport.
2019-05-05 20:29:24 -06:00
|
|
|
#include "gdbsupport/filestuff.h"
|
2019-04-06 13:38:10 -06:00
|
|
|
#include "objfiles.h"
|
|
|
|
|
|
|
|
#include "auxv.h"
|
|
|
|
#include "elf/common.h"
|
|
|
|
|
|
|
|
#include <unistd.h>
|
|
|
|
#include <fcntl.h>
|
2004-02-01 22:35:24 +00:00
|
|
|
|
|
|
|
|
2014-01-30 08:23:14 +08:00
|
|
|
/* Implement the to_xfer_partial target_ops method. This function
|
|
|
|
handles access via /proc/PID/auxv, which is a common method for
|
|
|
|
native targets. */
|
2004-02-01 22:35:24 +00:00
|
|
|
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
static enum target_xfer_status
|
2010-01-14 21:15:00 +00:00
|
|
|
procfs_xfer_auxv (gdb_byte *readbuf,
|
2005-05-23 18:20:03 +00:00
|
|
|
const gdb_byte *writebuf,
|
2004-02-01 22:35:24 +00:00
|
|
|
ULONGEST offset,
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
ULONGEST len,
|
|
|
|
ULONGEST *xfered_len)
|
2004-02-01 22:35:24 +00:00
|
|
|
{
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
ssize_t l;
|
2004-02-01 22:35:24 +00:00
|
|
|
|
2018-08-07 17:43:08 -04:00
|
|
|
std::string pathname = string_printf ("/proc/%d/auxv", inferior_ptid.pid ());
|
2021-07-22 11:56:33 -04:00
|
|
|
scoped_fd fd
|
|
|
|
= gdb_open_cloexec (pathname, writebuf != NULL ? O_WRONLY : O_RDONLY, 0);
|
|
|
|
if (fd.get () < 0)
|
2014-01-27 17:32:33 +08:00
|
|
|
return TARGET_XFER_E_IO;
|
2004-02-01 22:35:24 +00:00
|
|
|
|
|
|
|
if (offset != (ULONGEST) 0
|
2021-07-22 11:56:33 -04:00
|
|
|
&& lseek (fd.get (), (off_t) offset, SEEK_SET) != (off_t) offset)
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
l = -1;
|
2004-02-01 22:35:24 +00:00
|
|
|
else if (readbuf != NULL)
|
2021-07-22 11:56:33 -04:00
|
|
|
l = read (fd.get (), readbuf, (size_t) len);
|
2004-02-01 22:35:24 +00:00
|
|
|
else
|
2021-07-22 11:56:33 -04:00
|
|
|
l = write (fd.get (), writebuf, (size_t) len);
|
2004-02-01 22:35:24 +00:00
|
|
|
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
if (l < 0)
|
|
|
|
return TARGET_XFER_E_IO;
|
|
|
|
else if (l == 0)
|
|
|
|
return TARGET_XFER_EOF;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
*xfered_len = (ULONGEST) l;
|
|
|
|
return TARGET_XFER_OK;
|
|
|
|
}
|
2004-02-01 22:35:24 +00:00
|
|
|
}
|
|
|
|
|
2010-01-14 21:15:00 +00:00
|
|
|
/* This function handles access via ld.so's symbol `_dl_auxv'. */
|
|
|
|
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
static enum target_xfer_status
|
2010-01-14 21:15:00 +00:00
|
|
|
ld_so_xfer_auxv (gdb_byte *readbuf,
|
|
|
|
const gdb_byte *writebuf,
|
|
|
|
ULONGEST offset,
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
ULONGEST len, ULONGEST *xfered_len)
|
2010-01-14 21:15:00 +00:00
|
|
|
{
|
use bound_minsym as result for lookup_minimal_symbol et al
This patch changes a few minimal symbol lookup functions to return a
bound_minimal_symbol rather than a pointer to the minsym. This change
helps prepare gdb for computing a minimal symbol's address at the
point of use.
Note that this changes even those functions that ostensibly search a
single objfile. That was necessary because, in fact, those functions
can search an objfile and its separate debug objfiles; and it is
important for the caller to know in which objfile the minimal symbol
was actually found.
The bulk of this patch is mechanical.
2014-02-26 Tom Tromey <tromey@redhat.com>
* ada-lang.c (ada_update_initial_language): Update.
(ada_main_name, ada_has_this_exception_support): Update.
* ada-tasks.c (ada_tasks_inferior_data_sniffer): Update.
* aix-thread.c (pdc_symbol_addrs, pd_enable): Update.
* arm-tdep.c (arm_skip_stub): Update.
* auxv.c (ld_so_xfer_auxv): Update.
* avr-tdep.c (avr_scan_prologue): Update.
* ax-gdb.c (gen_var_ref): Update.
* breakpoint.c (struct breakpoint_objfile_data)
<overlay_msym, longjmp_msym, terminate_msym, exception_msym>: Change
type to bound_minimal_symbol.
(create_overlay_event_breakpoint)
(create_longjmp_master_breakpoint)
(create_std_terminate_master_breakpoint)
(create_exception_master_breakpoint): Update.
* bsd-uthread.c (bsd_uthread_lookup_address): Update.
* c-exp.y (classify_name): Update.
* coffread.c (coff_symfile_read): Update.
* common/agent.c (agent_look_up_symbols): Update.
* d-lang.c (d_main_name): Update.
* dbxread.c (find_stab_function_addr, end_psymtab): Update.
* dec-thread.c (enable_dec_thread): Update.
* dwarf2loc.c (call_site_to_target_addr): Update.
* elfread.c (elf_gnu_ifunc_resolve_by_got): Update.
* eval.c (evaluate_subexp_standard): Update.
* findvar.c (struct minsym_lookup_data) <result>: Change type
to bound_minimal_symbol.
<objfile>: Remove.
(minsym_lookup_iterator_cb, default_read_var_value): Update.
* frame.c (inside_main_func): Update.
* frv-tdep.c (frv_frame_this_id): Update.
* gcore.c (call_target_sbrk): Update.
* glibc-tdep.c (glibc_skip_solib_resolver): Update.
* gnu-v3-abi.c (gnuv3_get_typeid, gnuv3_skip_trampoline):
Update.
* go-lang.c (go_main_name): Update.
* hppa-hpux-tdep.c (hppa_hpux_skip_trampoline_code)
(hppa_hpux_find_import_stub_for_addr): Update.
* hppa-tdep.c (hppa_extract_17, hppa_lookup_stub_minimal_symbol):
Update. Change return type.
* hppa-tdep.h (hppa_lookup_stub_minimal_symbol): Change return
type.
* jit.c (jit_breakpoint_re_set_internal): Update.
* linux-fork.c (inferior_call_waitpid, checkpoint_command):
Update.
* linux-nat.c (get_signo): Update.
* linux-thread-db.c (inferior_has_bug): Update
* m32c-tdep.c (m32c_return_value)
(m32c_m16c_address_to_pointer): Update.
* m32r-tdep.c (m32r_frame_this_id): Update.
* m68hc11-tdep.c (m68hc11_get_register_info): Update.
* machoread.c (macho_resolve_oso_sym_with_minsym): Update.
* minsyms.c (lookup_minimal_symbol_internal): Rename to
lookup_minimal_symbol. Change return type.
(lookup_minimal_symbol): Remove.
(lookup_bound_minimal_symbol): Update.
(lookup_minimal_symbol_text): Change return type.
(lookup_minimal_symbol_solib_trampoline): Change return type.
* minsyms.h (lookup_minimal_symbol, lookup_minimal_symbol_text)
(lookup_minimal_symbol_solib_trampoline): Change return type.
* mips-linux-tdep.c (mips_linux_skip_resolver): Update.
* objc-lang.c (lookup_objc_class, lookup_child_selector)
(value_nsstring, find_imps): Update.
* obsd-tdep.c (obsd_skip_solib_resolver): Update.
* p-lang.c (pascal_main_name): Update.
* ppc-linux-tdep.c (ppc_linux_spe_context_lookup): Update.
* ppc-sysv-tdep.c (convert_code_addr_to_desc_addr): Update.
* proc-service.c (ps_pglobal_lookup): Update.
* ravenscar-thread.c (get_running_thread_msymbol): Change
return type.
(has_ravenscar_runtime, get_running_thread_id): Update.
* remote.c (remote_check_symbols): Update.
* sol-thread.c (ps_pglobal_lookup): Update.
* sol2-tdep.c (sol2_skip_solib_resolver): Update.
* solib-dsbt.c (lm_base): Update.
* solib-frv.c (lm_base, frv_relocate_section_addresses):
Update.
* solib-irix.c (locate_base): Update.
* solib-som.c (som_solib_create_inferior_hook)
(som_solib_desire_dynamic_linker_symbols, link_map_start):
Update.
* solib-spu.c (spu_enable_break): Update.
* solib-svr4.c (elf_locate_base, enable_break): Update.
* spu-tdep.c (spu_get_overlay_table, spu_catch_start)
(flush_ea_cache): Update.
* stabsread.c (define_symbol): Update.
* symfile.c (simple_read_overlay_table): Update.
* symtab.c (find_pc_sect_line): Update.
* tracepoint.c (scope_info): Update.
* tui-disasm.c (tui_get_begin_asm_address): Update.
* value.c (value_static_field): Update.
2013-10-14 19:53:29 -06:00
|
|
|
struct bound_minimal_symbol msym;
|
2010-01-14 21:15:00 +00:00
|
|
|
CORE_ADDR data_address, pointer_address;
|
2023-09-29 14:24:38 -04:00
|
|
|
gdbarch *arch = current_inferior ()->arch ();
|
|
|
|
type *ptr_type = builtin_type (arch)->builtin_data_ptr;
|
2022-09-21 11:05:21 -04:00
|
|
|
size_t ptr_size = ptr_type->length ();
|
2010-01-14 21:15:00 +00:00
|
|
|
size_t auxv_pair_size = 2 * ptr_size;
|
2015-09-25 14:08:06 -04:00
|
|
|
gdb_byte *ptr_buf = (gdb_byte *) alloca (ptr_size);
|
2010-01-14 21:15:00 +00:00
|
|
|
LONGEST retval;
|
|
|
|
size_t block;
|
|
|
|
|
|
|
|
msym = lookup_minimal_symbol ("_dl_auxv", NULL, NULL);
|
use bound_minsym as result for lookup_minimal_symbol et al
This patch changes a few minimal symbol lookup functions to return a
bound_minimal_symbol rather than a pointer to the minsym. This change
helps prepare gdb for computing a minimal symbol's address at the
point of use.
Note that this changes even those functions that ostensibly search a
single objfile. That was necessary because, in fact, those functions
can search an objfile and its separate debug objfiles; and it is
important for the caller to know in which objfile the minimal symbol
was actually found.
The bulk of this patch is mechanical.
2014-02-26 Tom Tromey <tromey@redhat.com>
* ada-lang.c (ada_update_initial_language): Update.
(ada_main_name, ada_has_this_exception_support): Update.
* ada-tasks.c (ada_tasks_inferior_data_sniffer): Update.
* aix-thread.c (pdc_symbol_addrs, pd_enable): Update.
* arm-tdep.c (arm_skip_stub): Update.
* auxv.c (ld_so_xfer_auxv): Update.
* avr-tdep.c (avr_scan_prologue): Update.
* ax-gdb.c (gen_var_ref): Update.
* breakpoint.c (struct breakpoint_objfile_data)
<overlay_msym, longjmp_msym, terminate_msym, exception_msym>: Change
type to bound_minimal_symbol.
(create_overlay_event_breakpoint)
(create_longjmp_master_breakpoint)
(create_std_terminate_master_breakpoint)
(create_exception_master_breakpoint): Update.
* bsd-uthread.c (bsd_uthread_lookup_address): Update.
* c-exp.y (classify_name): Update.
* coffread.c (coff_symfile_read): Update.
* common/agent.c (agent_look_up_symbols): Update.
* d-lang.c (d_main_name): Update.
* dbxread.c (find_stab_function_addr, end_psymtab): Update.
* dec-thread.c (enable_dec_thread): Update.
* dwarf2loc.c (call_site_to_target_addr): Update.
* elfread.c (elf_gnu_ifunc_resolve_by_got): Update.
* eval.c (evaluate_subexp_standard): Update.
* findvar.c (struct minsym_lookup_data) <result>: Change type
to bound_minimal_symbol.
<objfile>: Remove.
(minsym_lookup_iterator_cb, default_read_var_value): Update.
* frame.c (inside_main_func): Update.
* frv-tdep.c (frv_frame_this_id): Update.
* gcore.c (call_target_sbrk): Update.
* glibc-tdep.c (glibc_skip_solib_resolver): Update.
* gnu-v3-abi.c (gnuv3_get_typeid, gnuv3_skip_trampoline):
Update.
* go-lang.c (go_main_name): Update.
* hppa-hpux-tdep.c (hppa_hpux_skip_trampoline_code)
(hppa_hpux_find_import_stub_for_addr): Update.
* hppa-tdep.c (hppa_extract_17, hppa_lookup_stub_minimal_symbol):
Update. Change return type.
* hppa-tdep.h (hppa_lookup_stub_minimal_symbol): Change return
type.
* jit.c (jit_breakpoint_re_set_internal): Update.
* linux-fork.c (inferior_call_waitpid, checkpoint_command):
Update.
* linux-nat.c (get_signo): Update.
* linux-thread-db.c (inferior_has_bug): Update
* m32c-tdep.c (m32c_return_value)
(m32c_m16c_address_to_pointer): Update.
* m32r-tdep.c (m32r_frame_this_id): Update.
* m68hc11-tdep.c (m68hc11_get_register_info): Update.
* machoread.c (macho_resolve_oso_sym_with_minsym): Update.
* minsyms.c (lookup_minimal_symbol_internal): Rename to
lookup_minimal_symbol. Change return type.
(lookup_minimal_symbol): Remove.
(lookup_bound_minimal_symbol): Update.
(lookup_minimal_symbol_text): Change return type.
(lookup_minimal_symbol_solib_trampoline): Change return type.
* minsyms.h (lookup_minimal_symbol, lookup_minimal_symbol_text)
(lookup_minimal_symbol_solib_trampoline): Change return type.
* mips-linux-tdep.c (mips_linux_skip_resolver): Update.
* objc-lang.c (lookup_objc_class, lookup_child_selector)
(value_nsstring, find_imps): Update.
* obsd-tdep.c (obsd_skip_solib_resolver): Update.
* p-lang.c (pascal_main_name): Update.
* ppc-linux-tdep.c (ppc_linux_spe_context_lookup): Update.
* ppc-sysv-tdep.c (convert_code_addr_to_desc_addr): Update.
* proc-service.c (ps_pglobal_lookup): Update.
* ravenscar-thread.c (get_running_thread_msymbol): Change
return type.
(has_ravenscar_runtime, get_running_thread_id): Update.
* remote.c (remote_check_symbols): Update.
* sol-thread.c (ps_pglobal_lookup): Update.
* sol2-tdep.c (sol2_skip_solib_resolver): Update.
* solib-dsbt.c (lm_base): Update.
* solib-frv.c (lm_base, frv_relocate_section_addresses):
Update.
* solib-irix.c (locate_base): Update.
* solib-som.c (som_solib_create_inferior_hook)
(som_solib_desire_dynamic_linker_symbols, link_map_start):
Update.
* solib-spu.c (spu_enable_break): Update.
* solib-svr4.c (elf_locate_base, enable_break): Update.
* spu-tdep.c (spu_get_overlay_table, spu_catch_start)
(flush_ea_cache): Update.
* stabsread.c (define_symbol): Update.
* symfile.c (simple_read_overlay_table): Update.
* symtab.c (find_pc_sect_line): Update.
* tracepoint.c (scope_info): Update.
* tui-disasm.c (tui_get_begin_asm_address): Update.
* value.c (value_static_field): Update.
2013-10-14 19:53:29 -06:00
|
|
|
if (msym.minsym == NULL)
|
2014-01-27 17:32:33 +08:00
|
|
|
return TARGET_XFER_E_IO;
|
2010-01-14 21:15:00 +00:00
|
|
|
|
2022-01-28 10:41:49 -05:00
|
|
|
if (msym.minsym->size () != ptr_size)
|
2014-01-27 17:32:33 +08:00
|
|
|
return TARGET_XFER_E_IO;
|
2010-01-14 21:15:00 +00:00
|
|
|
|
2010-12-31 19:16:37 +00:00
|
|
|
/* POINTER_ADDRESS is a location where the `_dl_auxv' variable
|
|
|
|
resides. DATA_ADDRESS is the inferior value present in
|
|
|
|
`_dl_auxv', therefore the real inferior AUXV address. */
|
2010-01-14 21:15:00 +00:00
|
|
|
|
2022-01-28 08:09:50 -05:00
|
|
|
pointer_address = msym.value_address ();
|
2010-01-14 21:15:00 +00:00
|
|
|
|
2010-07-05 17:58:56 +00:00
|
|
|
/* The location of the _dl_auxv symbol may no longer be correct if
|
2010-12-31 19:16:37 +00:00
|
|
|
ld.so runs at a different address than the one present in the
|
|
|
|
file. This is very common case - for unprelinked ld.so or with a
|
|
|
|
PIE executable. PIE executable forces random address even for
|
|
|
|
libraries already being prelinked to some address. PIE
|
|
|
|
executables themselves are never prelinked even on prelinked
|
|
|
|
systems. Prelinking of a PIE executable would block their
|
|
|
|
purpose of randomizing load of everything including the
|
|
|
|
executable.
|
|
|
|
|
|
|
|
If the memory read fails, return -1 to fallback on another
|
|
|
|
mechanism for retrieving the AUXV.
|
|
|
|
|
|
|
|
In most cases of a PIE running under valgrind there is no way to
|
|
|
|
find out the base addresses of any of ld.so, executable or AUXV
|
|
|
|
as everything is randomized and /proc information is not relevant
|
|
|
|
for the virtual executable running under valgrind. We think that
|
|
|
|
we might need a valgrind extension to make it work. This is PR
|
|
|
|
11440. */
|
2010-07-05 17:58:56 +00:00
|
|
|
|
|
|
|
if (target_read_memory (pointer_address, ptr_buf, ptr_size) != 0)
|
2014-01-27 17:32:33 +08:00
|
|
|
return TARGET_XFER_E_IO;
|
2010-07-05 17:58:56 +00:00
|
|
|
|
|
|
|
data_address = extract_typed_address (ptr_buf, ptr_type);
|
2010-01-14 21:15:00 +00:00
|
|
|
|
2010-12-31 19:16:37 +00:00
|
|
|
/* Possibly still not initialized such as during an inferior
|
|
|
|
startup. */
|
2010-01-14 21:15:00 +00:00
|
|
|
if (data_address == 0)
|
2014-01-27 17:32:33 +08:00
|
|
|
return TARGET_XFER_E_IO;
|
2010-01-14 21:15:00 +00:00
|
|
|
|
|
|
|
data_address += offset;
|
|
|
|
|
|
|
|
if (writebuf != NULL)
|
|
|
|
{
|
|
|
|
if (target_write_memory (data_address, writebuf, len) == 0)
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
{
|
|
|
|
*xfered_len = (ULONGEST) len;
|
|
|
|
return TARGET_XFER_OK;
|
|
|
|
}
|
2010-01-14 21:15:00 +00:00
|
|
|
else
|
2014-01-27 17:32:33 +08:00
|
|
|
return TARGET_XFER_E_IO;
|
2010-01-14 21:15:00 +00:00
|
|
|
}
|
|
|
|
|
2010-12-31 19:16:37 +00:00
|
|
|
/* Stop if trying to read past the existing AUXV block. The final
|
|
|
|
AT_NULL was already returned before. */
|
2010-01-14 21:15:00 +00:00
|
|
|
|
|
|
|
if (offset >= auxv_pair_size)
|
|
|
|
{
|
|
|
|
if (target_read_memory (data_address - auxv_pair_size, ptr_buf,
|
|
|
|
ptr_size) != 0)
|
2014-01-27 17:32:33 +08:00
|
|
|
return TARGET_XFER_E_IO;
|
2010-01-14 21:15:00 +00:00
|
|
|
|
|
|
|
if (extract_typed_address (ptr_buf, ptr_type) == AT_NULL)
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
return TARGET_XFER_EOF;
|
2010-01-14 21:15:00 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
retval = 0;
|
|
|
|
block = 0x400;
|
|
|
|
gdb_assert (block % auxv_pair_size == 0);
|
|
|
|
|
|
|
|
while (len > 0)
|
|
|
|
{
|
|
|
|
if (block > len)
|
|
|
|
block = len;
|
|
|
|
|
2010-12-31 19:16:37 +00:00
|
|
|
/* Reading sizes smaller than AUXV_PAIR_SIZE is not supported.
|
|
|
|
Tails unaligned to AUXV_PAIR_SIZE will not be read during a
|
|
|
|
call (they should be completed during next read with
|
|
|
|
new/extended buffer). */
|
2010-01-14 21:15:00 +00:00
|
|
|
|
|
|
|
block &= -auxv_pair_size;
|
|
|
|
if (block == 0)
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
break;
|
2010-01-14 21:15:00 +00:00
|
|
|
|
|
|
|
if (target_read_memory (data_address, readbuf, block) != 0)
|
|
|
|
{
|
|
|
|
if (block <= auxv_pair_size)
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
break;
|
2010-01-14 21:15:00 +00:00
|
|
|
|
|
|
|
block = auxv_pair_size;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
data_address += block;
|
|
|
|
len -= block;
|
|
|
|
|
2010-12-31 19:16:37 +00:00
|
|
|
/* Check terminal AT_NULL. This function is being called
|
gdb, gdbserver, gdbsupport: fix leading space vs tabs issues
Many spots incorrectly use only spaces for indentation (for example,
there are a lot of spots in ada-lang.c). I've always found it awkward
when I needed to edit one of these spots: do I keep the original wrong
indentation, or do I fix it? What if the lines around it are also
wrong, do I fix them too? I probably don't want to fix them in the same
patch, to avoid adding noise to my patch.
So I propose to fix as much as possible once and for all (hopefully).
One typical counter argument for this is that it makes code archeology
more difficult, because git-blame will show this commit as the last
change for these lines. My counter counter argument is: when
git-blaming, you often need to do "blame the file at the parent commit"
anyway, to go past some other refactor that touched the line you are
interested in, but is not the change you are looking for. So you
already need a somewhat efficient way to do this.
Using some interactive tool, rather than plain git-blame, makes this
trivial. For example, I use "tig blame <file>", where going back past
the commit that changed the currently selected line is one keystroke.
It looks like Magit in Emacs does it too (though I've never used it).
Web viewers of Github and Gitlab do it too. My point is that it won't
really make archeology more difficult.
The other typical counter argument is that it will cause conflicts with
existing patches. That's true... but it's a one time cost, and those
are not conflicts that are difficult to resolve. I have also tried "git
rebase --ignore-whitespace", it seems to work well. Although that will
re-introduce the faulty indentation, so one needs to take care of fixing
the indentation in the patch after that (which is easy).
gdb/ChangeLog:
* aarch64-linux-tdep.c: Fix indentation.
* aarch64-ravenscar-thread.c: Fix indentation.
* aarch64-tdep.c: Fix indentation.
* aarch64-tdep.h: Fix indentation.
* ada-lang.c: Fix indentation.
* ada-lang.h: Fix indentation.
* ada-tasks.c: Fix indentation.
* ada-typeprint.c: Fix indentation.
* ada-valprint.c: Fix indentation.
* ada-varobj.c: Fix indentation.
* addrmap.c: Fix indentation.
* addrmap.h: Fix indentation.
* agent.c: Fix indentation.
* aix-thread.c: Fix indentation.
* alpha-bsd-nat.c: Fix indentation.
* alpha-linux-tdep.c: Fix indentation.
* alpha-mdebug-tdep.c: Fix indentation.
* alpha-nbsd-tdep.c: Fix indentation.
* alpha-obsd-tdep.c: Fix indentation.
* alpha-tdep.c: Fix indentation.
* amd64-bsd-nat.c: Fix indentation.
* amd64-darwin-tdep.c: Fix indentation.
* amd64-linux-nat.c: Fix indentation.
* amd64-linux-tdep.c: Fix indentation.
* amd64-nat.c: Fix indentation.
* amd64-obsd-tdep.c: Fix indentation.
* amd64-tdep.c: Fix indentation.
* amd64-windows-tdep.c: Fix indentation.
* annotate.c: Fix indentation.
* arc-tdep.c: Fix indentation.
* arch-utils.c: Fix indentation.
* arch/arm-get-next-pcs.c: Fix indentation.
* arch/arm.c: Fix indentation.
* arm-linux-nat.c: Fix indentation.
* arm-linux-tdep.c: Fix indentation.
* arm-nbsd-tdep.c: Fix indentation.
* arm-pikeos-tdep.c: Fix indentation.
* arm-tdep.c: Fix indentation.
* arm-tdep.h: Fix indentation.
* arm-wince-tdep.c: Fix indentation.
* auto-load.c: Fix indentation.
* auxv.c: Fix indentation.
* avr-tdep.c: Fix indentation.
* ax-gdb.c: Fix indentation.
* ax-general.c: Fix indentation.
* bfin-linux-tdep.c: Fix indentation.
* block.c: Fix indentation.
* block.h: Fix indentation.
* blockframe.c: Fix indentation.
* bpf-tdep.c: Fix indentation.
* break-catch-sig.c: Fix indentation.
* break-catch-syscall.c: Fix indentation.
* break-catch-throw.c: Fix indentation.
* breakpoint.c: Fix indentation.
* breakpoint.h: Fix indentation.
* bsd-uthread.c: Fix indentation.
* btrace.c: Fix indentation.
* build-id.c: Fix indentation.
* buildsym-legacy.h: Fix indentation.
* buildsym.c: Fix indentation.
* c-typeprint.c: Fix indentation.
* c-valprint.c: Fix indentation.
* c-varobj.c: Fix indentation.
* charset.c: Fix indentation.
* cli/cli-cmds.c: Fix indentation.
* cli/cli-decode.c: Fix indentation.
* cli/cli-decode.h: Fix indentation.
* cli/cli-script.c: Fix indentation.
* cli/cli-setshow.c: Fix indentation.
* coff-pe-read.c: Fix indentation.
* coffread.c: Fix indentation.
* compile/compile-cplus-types.c: Fix indentation.
* compile/compile-object-load.c: Fix indentation.
* compile/compile-object-run.c: Fix indentation.
* completer.c: Fix indentation.
* corefile.c: Fix indentation.
* corelow.c: Fix indentation.
* cp-abi.h: Fix indentation.
* cp-namespace.c: Fix indentation.
* cp-support.c: Fix indentation.
* cp-valprint.c: Fix indentation.
* cris-linux-tdep.c: Fix indentation.
* cris-tdep.c: Fix indentation.
* darwin-nat-info.c: Fix indentation.
* darwin-nat.c: Fix indentation.
* darwin-nat.h: Fix indentation.
* dbxread.c: Fix indentation.
* dcache.c: Fix indentation.
* disasm.c: Fix indentation.
* dtrace-probe.c: Fix indentation.
* dwarf2/abbrev.c: Fix indentation.
* dwarf2/attribute.c: Fix indentation.
* dwarf2/expr.c: Fix indentation.
* dwarf2/frame.c: Fix indentation.
* dwarf2/index-cache.c: Fix indentation.
* dwarf2/index-write.c: Fix indentation.
* dwarf2/line-header.c: Fix indentation.
* dwarf2/loc.c: Fix indentation.
* dwarf2/macro.c: Fix indentation.
* dwarf2/read.c: Fix indentation.
* dwarf2/read.h: Fix indentation.
* elfread.c: Fix indentation.
* eval.c: Fix indentation.
* event-top.c: Fix indentation.
* exec.c: Fix indentation.
* exec.h: Fix indentation.
* expprint.c: Fix indentation.
* f-lang.c: Fix indentation.
* f-typeprint.c: Fix indentation.
* f-valprint.c: Fix indentation.
* fbsd-nat.c: Fix indentation.
* fbsd-tdep.c: Fix indentation.
* findvar.c: Fix indentation.
* fork-child.c: Fix indentation.
* frame-unwind.c: Fix indentation.
* frame-unwind.h: Fix indentation.
* frame.c: Fix indentation.
* frv-linux-tdep.c: Fix indentation.
* frv-tdep.c: Fix indentation.
* frv-tdep.h: Fix indentation.
* ft32-tdep.c: Fix indentation.
* gcore.c: Fix indentation.
* gdb_bfd.c: Fix indentation.
* gdbarch.sh: Fix indentation.
* gdbarch.c: Re-generate
* gdbarch.h: Re-generate.
* gdbcore.h: Fix indentation.
* gdbthread.h: Fix indentation.
* gdbtypes.c: Fix indentation.
* gdbtypes.h: Fix indentation.
* glibc-tdep.c: Fix indentation.
* gnu-nat.c: Fix indentation.
* gnu-nat.h: Fix indentation.
* gnu-v2-abi.c: Fix indentation.
* gnu-v3-abi.c: Fix indentation.
* go32-nat.c: Fix indentation.
* guile/guile-internal.h: Fix indentation.
* guile/scm-cmd.c: Fix indentation.
* guile/scm-frame.c: Fix indentation.
* guile/scm-iterator.c: Fix indentation.
* guile/scm-math.c: Fix indentation.
* guile/scm-ports.c: Fix indentation.
* guile/scm-pretty-print.c: Fix indentation.
* guile/scm-value.c: Fix indentation.
* h8300-tdep.c: Fix indentation.
* hppa-linux-nat.c: Fix indentation.
* hppa-linux-tdep.c: Fix indentation.
* hppa-nbsd-nat.c: Fix indentation.
* hppa-nbsd-tdep.c: Fix indentation.
* hppa-obsd-nat.c: Fix indentation.
* hppa-tdep.c: Fix indentation.
* hppa-tdep.h: Fix indentation.
* i386-bsd-nat.c: Fix indentation.
* i386-darwin-nat.c: Fix indentation.
* i386-darwin-tdep.c: Fix indentation.
* i386-dicos-tdep.c: Fix indentation.
* i386-gnu-nat.c: Fix indentation.
* i386-linux-nat.c: Fix indentation.
* i386-linux-tdep.c: Fix indentation.
* i386-nto-tdep.c: Fix indentation.
* i386-obsd-tdep.c: Fix indentation.
* i386-sol2-nat.c: Fix indentation.
* i386-tdep.c: Fix indentation.
* i386-tdep.h: Fix indentation.
* i386-windows-tdep.c: Fix indentation.
* i387-tdep.c: Fix indentation.
* i387-tdep.h: Fix indentation.
* ia64-libunwind-tdep.c: Fix indentation.
* ia64-libunwind-tdep.h: Fix indentation.
* ia64-linux-nat.c: Fix indentation.
* ia64-linux-tdep.c: Fix indentation.
* ia64-tdep.c: Fix indentation.
* ia64-tdep.h: Fix indentation.
* ia64-vms-tdep.c: Fix indentation.
* infcall.c: Fix indentation.
* infcmd.c: Fix indentation.
* inferior.c: Fix indentation.
* infrun.c: Fix indentation.
* iq2000-tdep.c: Fix indentation.
* language.c: Fix indentation.
* linespec.c: Fix indentation.
* linux-fork.c: Fix indentation.
* linux-nat.c: Fix indentation.
* linux-tdep.c: Fix indentation.
* linux-thread-db.c: Fix indentation.
* lm32-tdep.c: Fix indentation.
* m2-lang.c: Fix indentation.
* m2-typeprint.c: Fix indentation.
* m2-valprint.c: Fix indentation.
* m32c-tdep.c: Fix indentation.
* m32r-linux-tdep.c: Fix indentation.
* m32r-tdep.c: Fix indentation.
* m68hc11-tdep.c: Fix indentation.
* m68k-bsd-nat.c: Fix indentation.
* m68k-linux-nat.c: Fix indentation.
* m68k-linux-tdep.c: Fix indentation.
* m68k-tdep.c: Fix indentation.
* machoread.c: Fix indentation.
* macrocmd.c: Fix indentation.
* macroexp.c: Fix indentation.
* macroscope.c: Fix indentation.
* macrotab.c: Fix indentation.
* macrotab.h: Fix indentation.
* main.c: Fix indentation.
* mdebugread.c: Fix indentation.
* mep-tdep.c: Fix indentation.
* mi/mi-cmd-catch.c: Fix indentation.
* mi/mi-cmd-disas.c: Fix indentation.
* mi/mi-cmd-env.c: Fix indentation.
* mi/mi-cmd-stack.c: Fix indentation.
* mi/mi-cmd-var.c: Fix indentation.
* mi/mi-cmds.c: Fix indentation.
* mi/mi-main.c: Fix indentation.
* mi/mi-parse.c: Fix indentation.
* microblaze-tdep.c: Fix indentation.
* minidebug.c: Fix indentation.
* minsyms.c: Fix indentation.
* mips-linux-nat.c: Fix indentation.
* mips-linux-tdep.c: Fix indentation.
* mips-nbsd-tdep.c: Fix indentation.
* mips-tdep.c: Fix indentation.
* mn10300-linux-tdep.c: Fix indentation.
* mn10300-tdep.c: Fix indentation.
* moxie-tdep.c: Fix indentation.
* msp430-tdep.c: Fix indentation.
* namespace.h: Fix indentation.
* nat/fork-inferior.c: Fix indentation.
* nat/gdb_ptrace.h: Fix indentation.
* nat/linux-namespaces.c: Fix indentation.
* nat/linux-osdata.c: Fix indentation.
* nat/netbsd-nat.c: Fix indentation.
* nat/x86-dregs.c: Fix indentation.
* nbsd-nat.c: Fix indentation.
* nbsd-tdep.c: Fix indentation.
* nios2-linux-tdep.c: Fix indentation.
* nios2-tdep.c: Fix indentation.
* nto-procfs.c: Fix indentation.
* nto-tdep.c: Fix indentation.
* objfiles.c: Fix indentation.
* objfiles.h: Fix indentation.
* opencl-lang.c: Fix indentation.
* or1k-tdep.c: Fix indentation.
* osabi.c: Fix indentation.
* osabi.h: Fix indentation.
* osdata.c: Fix indentation.
* p-lang.c: Fix indentation.
* p-typeprint.c: Fix indentation.
* p-valprint.c: Fix indentation.
* parse.c: Fix indentation.
* ppc-linux-nat.c: Fix indentation.
* ppc-linux-tdep.c: Fix indentation.
* ppc-nbsd-nat.c: Fix indentation.
* ppc-nbsd-tdep.c: Fix indentation.
* ppc-obsd-nat.c: Fix indentation.
* ppc-ravenscar-thread.c: Fix indentation.
* ppc-sysv-tdep.c: Fix indentation.
* ppc64-tdep.c: Fix indentation.
* printcmd.c: Fix indentation.
* proc-api.c: Fix indentation.
* producer.c: Fix indentation.
* producer.h: Fix indentation.
* prologue-value.c: Fix indentation.
* prologue-value.h: Fix indentation.
* psymtab.c: Fix indentation.
* python/py-arch.c: Fix indentation.
* python/py-bpevent.c: Fix indentation.
* python/py-event.c: Fix indentation.
* python/py-event.h: Fix indentation.
* python/py-finishbreakpoint.c: Fix indentation.
* python/py-frame.c: Fix indentation.
* python/py-framefilter.c: Fix indentation.
* python/py-inferior.c: Fix indentation.
* python/py-infthread.c: Fix indentation.
* python/py-objfile.c: Fix indentation.
* python/py-prettyprint.c: Fix indentation.
* python/py-registers.c: Fix indentation.
* python/py-signalevent.c: Fix indentation.
* python/py-stopevent.c: Fix indentation.
* python/py-stopevent.h: Fix indentation.
* python/py-threadevent.c: Fix indentation.
* python/py-tui.c: Fix indentation.
* python/py-unwind.c: Fix indentation.
* python/py-value.c: Fix indentation.
* python/py-xmethods.c: Fix indentation.
* python/python-internal.h: Fix indentation.
* python/python.c: Fix indentation.
* ravenscar-thread.c: Fix indentation.
* record-btrace.c: Fix indentation.
* record-full.c: Fix indentation.
* record.c: Fix indentation.
* reggroups.c: Fix indentation.
* regset.h: Fix indentation.
* remote-fileio.c: Fix indentation.
* remote.c: Fix indentation.
* reverse.c: Fix indentation.
* riscv-linux-tdep.c: Fix indentation.
* riscv-ravenscar-thread.c: Fix indentation.
* riscv-tdep.c: Fix indentation.
* rl78-tdep.c: Fix indentation.
* rs6000-aix-tdep.c: Fix indentation.
* rs6000-lynx178-tdep.c: Fix indentation.
* rs6000-nat.c: Fix indentation.
* rs6000-tdep.c: Fix indentation.
* rust-lang.c: Fix indentation.
* rx-tdep.c: Fix indentation.
* s12z-tdep.c: Fix indentation.
* s390-linux-tdep.c: Fix indentation.
* score-tdep.c: Fix indentation.
* ser-base.c: Fix indentation.
* ser-mingw.c: Fix indentation.
* ser-uds.c: Fix indentation.
* ser-unix.c: Fix indentation.
* serial.c: Fix indentation.
* sh-linux-tdep.c: Fix indentation.
* sh-nbsd-tdep.c: Fix indentation.
* sh-tdep.c: Fix indentation.
* skip.c: Fix indentation.
* sol-thread.c: Fix indentation.
* solib-aix.c: Fix indentation.
* solib-darwin.c: Fix indentation.
* solib-frv.c: Fix indentation.
* solib-svr4.c: Fix indentation.
* solib.c: Fix indentation.
* source.c: Fix indentation.
* sparc-linux-tdep.c: Fix indentation.
* sparc-nbsd-tdep.c: Fix indentation.
* sparc-obsd-tdep.c: Fix indentation.
* sparc-ravenscar-thread.c: Fix indentation.
* sparc-tdep.c: Fix indentation.
* sparc64-linux-tdep.c: Fix indentation.
* sparc64-nbsd-tdep.c: Fix indentation.
* sparc64-obsd-tdep.c: Fix indentation.
* sparc64-tdep.c: Fix indentation.
* stabsread.c: Fix indentation.
* stack.c: Fix indentation.
* stap-probe.c: Fix indentation.
* stubs/ia64vms-stub.c: Fix indentation.
* stubs/m32r-stub.c: Fix indentation.
* stubs/m68k-stub.c: Fix indentation.
* stubs/sh-stub.c: Fix indentation.
* stubs/sparc-stub.c: Fix indentation.
* symfile-mem.c: Fix indentation.
* symfile.c: Fix indentation.
* symfile.h: Fix indentation.
* symmisc.c: Fix indentation.
* symtab.c: Fix indentation.
* symtab.h: Fix indentation.
* target-float.c: Fix indentation.
* target.c: Fix indentation.
* target.h: Fix indentation.
* tic6x-tdep.c: Fix indentation.
* tilegx-linux-tdep.c: Fix indentation.
* tilegx-tdep.c: Fix indentation.
* top.c: Fix indentation.
* tracefile-tfile.c: Fix indentation.
* tracepoint.c: Fix indentation.
* tui/tui-disasm.c: Fix indentation.
* tui/tui-io.c: Fix indentation.
* tui/tui-regs.c: Fix indentation.
* tui/tui-stack.c: Fix indentation.
* tui/tui-win.c: Fix indentation.
* tui/tui-winsource.c: Fix indentation.
* tui/tui.c: Fix indentation.
* typeprint.c: Fix indentation.
* ui-out.h: Fix indentation.
* unittests/copy_bitwise-selftests.c: Fix indentation.
* unittests/memory-map-selftests.c: Fix indentation.
* utils.c: Fix indentation.
* v850-tdep.c: Fix indentation.
* valarith.c: Fix indentation.
* valops.c: Fix indentation.
* valprint.c: Fix indentation.
* valprint.h: Fix indentation.
* value.c: Fix indentation.
* value.h: Fix indentation.
* varobj.c: Fix indentation.
* vax-tdep.c: Fix indentation.
* windows-nat.c: Fix indentation.
* windows-tdep.c: Fix indentation.
* xcoffread.c: Fix indentation.
* xml-syscall.c: Fix indentation.
* xml-tdesc.c: Fix indentation.
* xstormy16-tdep.c: Fix indentation.
* xtensa-config.c: Fix indentation.
* xtensa-linux-nat.c: Fix indentation.
* xtensa-linux-tdep.c: Fix indentation.
* xtensa-tdep.c: Fix indentation.
gdbserver/ChangeLog:
* ax.cc: Fix indentation.
* dll.cc: Fix indentation.
* inferiors.h: Fix indentation.
* linux-low.cc: Fix indentation.
* linux-nios2-low.cc: Fix indentation.
* linux-ppc-ipa.cc: Fix indentation.
* linux-ppc-low.cc: Fix indentation.
* linux-x86-low.cc: Fix indentation.
* linux-xtensa-low.cc: Fix indentation.
* regcache.cc: Fix indentation.
* server.cc: Fix indentation.
* tracepoint.cc: Fix indentation.
gdbsupport/ChangeLog:
* common-exceptions.h: Fix indentation.
* event-loop.cc: Fix indentation.
* fileio.cc: Fix indentation.
* filestuff.cc: Fix indentation.
* gdb-dlfcn.cc: Fix indentation.
* gdb_string_view.h: Fix indentation.
* job-control.cc: Fix indentation.
* signals.cc: Fix indentation.
Change-Id: I4bad7ae6be0fbe14168b8ebafb98ffe14964a695
2020-11-02 10:26:14 -05:00
|
|
|
indefinitely being extended its READBUF until it returns EOF
|
|
|
|
(0). */
|
2010-01-14 21:15:00 +00:00
|
|
|
|
|
|
|
while (block >= auxv_pair_size)
|
|
|
|
{
|
|
|
|
retval += auxv_pair_size;
|
|
|
|
|
|
|
|
if (extract_typed_address (readbuf, ptr_type) == AT_NULL)
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
{
|
|
|
|
*xfered_len = (ULONGEST) retval;
|
|
|
|
return TARGET_XFER_OK;
|
|
|
|
}
|
2010-01-14 21:15:00 +00:00
|
|
|
|
|
|
|
readbuf += auxv_pair_size;
|
|
|
|
block -= auxv_pair_size;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
*xfered_len = (ULONGEST) retval;
|
|
|
|
return TARGET_XFER_OK;
|
2010-01-14 21:15:00 +00:00
|
|
|
}
|
|
|
|
|
2014-01-30 08:23:14 +08:00
|
|
|
/* Implement the to_xfer_partial target_ops method for
|
|
|
|
TARGET_OBJECT_AUXV. It handles access to AUXV. */
|
2010-01-14 21:15:00 +00:00
|
|
|
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
enum target_xfer_status
|
2010-01-14 21:15:00 +00:00
|
|
|
memory_xfer_auxv (struct target_ops *ops,
|
|
|
|
enum target_object object,
|
|
|
|
const char *annex,
|
|
|
|
gdb_byte *readbuf,
|
|
|
|
const gdb_byte *writebuf,
|
|
|
|
ULONGEST offset,
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
ULONGEST len, ULONGEST *xfered_len)
|
2010-01-14 21:15:00 +00:00
|
|
|
{
|
|
|
|
gdb_assert (object == TARGET_OBJECT_AUXV);
|
|
|
|
gdb_assert (readbuf || writebuf);
|
|
|
|
|
2010-12-31 19:16:37 +00:00
|
|
|
/* ld_so_xfer_auxv is the only function safe for virtual
|
|
|
|
executables being executed by valgrind's memcheck. Using
|
|
|
|
ld_so_xfer_auxv during inferior startup is problematic, because
|
|
|
|
ld.so symbol tables have not yet been relocated. So GDB uses
|
|
|
|
this function only when attaching to a process.
|
2010-07-05 18:00:40 +00:00
|
|
|
*/
|
2010-01-14 21:15:00 +00:00
|
|
|
|
2022-11-27 17:57:08 +01:00
|
|
|
if (current_inferior ()->attach_flag)
|
2010-01-14 21:15:00 +00:00
|
|
|
{
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
enum target_xfer_status ret;
|
2010-01-14 21:15:00 +00:00
|
|
|
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
ret = ld_so_xfer_auxv (readbuf, writebuf, offset, len, xfered_len);
|
|
|
|
if (ret != TARGET_XFER_E_IO)
|
|
|
|
return ret;
|
2010-01-14 21:15:00 +00:00
|
|
|
}
|
|
|
|
|
Return target_xfer_status in to_xfer_partial
This patch does the conversion of to_xfer_partial from
LONGEST (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len);
to
enum target_xfer_status (*to_xfer_partial) (struct target_ops *ops,
enum target_object object, const char *annex,
gdb_byte *readbuf, const gdb_byte *writebuf,
ULONGEST offset, ULONGEST len, ULONGEST *xfered_len);
It changes to_xfer_partial return the transfer status and the transfered
length by *XFERED_LEN. Generally, the return status has three stats,
- TARGET_XFER_OK,
- TARGET_XFER_EOF,
- TARGET_XFER_E_XXXX,
See the comments to them in 'enum target_xfer_status'. Note that
Pedro suggested not name TARGET_XFER_DONE, as it is confusing,
compared with "TARGET_XFER_OK". We finally name it TARGET_XFER_EOF.
With this change, GDB core can handle unavailable data in a convenient
way.
The rationale behind this change was mentioned here
https://sourceware.org/ml/gdb-patches/2013-10/msg00761.html
Consider an object/value like this:
0 100 150 200 512
DDDDDDDDDDDxxxxxxxxxDDDDDD...DDIIIIIIIIIIII..III
where D is valid data, and xxx is unavailable data, and I is beyond
the end of the object (Invalid). Currently, if we start the
xfer at 0, requesting, say 512 bytes, we'll first get back 100 bytes.
The xfer machinery then retries fetching [100,512), and gets back
TARGET_XFER_E_UNAVAILABLE. That's sufficient when you're either
interested in either having the whole of the 512 bytes available,
or erroring out. But, in this scenario, we're interested in
the data at [150,512). The problem is that the last
TARGET_XFER_E_UNAVAILABLE gives us no indication where to
start the read next. We'd need something like:
get me [0,512) >>>
<<< here's [0,100), *xfered_len is 100, returns TARGET_XFER_OK
get me [100,512) >>> (**1)
<<< [100,150) is unavailable, *xfered_len is 50, return TARGET_XFER_E_UNAVAILABLE.
get me [150,512) >>>
<<< here's [150,200), *xfered_len is 50, return TARGET_XFER_OK.
get me [200,512) >>>
<<< no more data, return TARGET_XFER_EOF.
This naturally implies pushing down the decision of whether
to return TARGET_XFER_E_UNAVAILABLE or something else
down to the target. (Which kinds of leads back to tfile
itself reading from RO memory from file (though we could
export a function in exec.c for that that tfile delegates to,
instead of re-adding the old code).
Beside this change, we also add a macro TARGET_XFER_STATUS_ERROR_P to
check whether a status is an error or not, to stop using "status < 0".
This patch also eliminates the comparison between status and 0.
No target implementations to to_xfer_partial adapts this new
interface. The interface still behaves as before.
gdb:
2014-02-11 Yao Qi <yao@codesourcery.com>
* target.h (enum target_xfer_error): Rename to ...
(enum target_xfer_status): ... it. New. All users updated.
(enum target_xfer_status) <TARGET_XFER_OK>, <TARGET_XFER_EOF>:
New.
(TARGET_XFER_STATUS_ERROR_P): New macro.
(target_xfer_error_to_string): Remove declaration.
(target_xfer_status_to_string): Declare.
(target_xfer_partial_ftype): Adjust it.
(struct target_ops) <to_xfer_partial>: Return
target_xfer_status. Add argument xfered_len. Update
comments.
* target.c (target_xfer_error_to_string): Rename to ...
(target_xfer_status_to_string): ... it. New. All callers
updated.
(target_read_live_memory): Likewise. Call target_xfer_partial
instead of target_read.
(memory_xfer_live_readonly_partial): Return
target_xfer_status. Add argument xfered_len.
(raw_memory_xfer_partial): Likewise.
(memory_xfer_partial_1): Likewise.
(memory_xfer_partial): Likewise.
(target_xfer_partial): Likewise. Check *XFERED_LEN is set
properly. Update debug message.
(default_xfer_partial, current_xfer_partial): Likewise.
(target_write_partial): Likewise.
(target_read_partial): Likewise. All callers updated.
(read_whatever_is_readable): Likewise.
(target_write_with_progress): Likewise.
(target_read_alloc_1): Likewise.
* aix-thread.c (aix_thread_xfer_partial): Likewise.
* auxv.c (procfs_xfer_auxv): Likewise.
(ld_so_xfer_auxv, memory_xfer_auxv): Likewise.
* bfd-target.c (target_bfd_xfer_partial): Likewise.
* bsd-kvm.c (bsd_kvm_xfer_partial): Likewise.
* bsd-uthread.c (bsd_uthread_xfer_partia): Likewise.
* corefile.c (read_memory): Adjust.
* corelow.c (core_xfer_partial): Likewise.
* ctf.c (ctf_xfer_partial): Likewise.
* darwin-nat.c (darwin_read_dyld_info): Likewise. All callers
updated.
(darwin_xfer_partial): Likewise.
* exec.c (section_table_xfer_memory_partial): Likewise. All
callers updated.
(exec_xfer_partial): Likewise.
* exec.h (section_table_xfer_memory_partial): Update
declaration.
* gnu-nat.c (gnu_xfer_memory): Likewise. Assert 'res' is not
negative.
(gnu_xfer_partial): Likewise.
* ia64-hpux-nat.c (ia64_hpux_xfer_memory_no_bs): Likewise.
(ia64_hpux_xfer_memory, ia64_hpux_xfer_uregs): Likewise.
(ia64_hpux_xfer_solib_got): Likewise.
* inf-ptrace.c (inf_ptrace_xfer_partial): Likewise. Change
type of 'partial_len' to ULONGEST.
* inf-ttrace.c (inf_ttrace_xfer_partial): Likewise.
* linux-nat.c (linux_xfer_siginfo ): Likewise.
(linux_nat_xfer_partial): Likewise.
(linux_proc_xfer_partial, linux_xfer_partial): Likewise.
(linux_proc_xfer_spu, linux_nat_xfer_osdata): Likewise.
* monitor.c (monitor_xfer_memory): Likewise.
(monitor_xfer_partial): Likewise.
* procfs.c (procfs_xfer_partial): Likewise.
* record-btrace.c (record_btrace_xfer_partial): Likewise.
* record-full.c (record_full_xfer_partial): Likewise.
(record_full_core_xfer_partial): Likewise.
* remote-sim.c (gdbsim_xfer_memory): Likewise.
(gdbsim_xfer_partial): Likewise.
* remote.c (remote_write_bytes_aux): Likewise. All callers
updated.
(remote_write_bytes, remote_read_bytes): Likewise. All
callers updated.
(remote_flash_erase): Likewise. All callers updated.
(remote_write_qxfer): Likewise. All callers updated.
(remote_read_qxfer): Likewise. All callers updated.
(remote_xfer_partial): Likewise.
* rs6000-nat.c (rs6000_xfer_partial): Likewise.
(rs6000_xfer_shared_libraries): Likewise.
* sol-thread.c (sol_thread_xfer_partial): Likewise.
(sol_thread_xfer_partial): Likewise.
* sparc-nat.c (sparc_xfer_wcookie): Likewise.
(sparc_xfer_partial): Likewise.
* spu-linux-nat.c (spu_proc_xfer_spu): Likewise. All callers
updated.
(spu_xfer_partial): Likewise.
* spu-multiarch.c (spu_xfer_partial): Likewise.
* tracepoint.c (tfile_xfer_partial): Likewise.
* windows-nat.c (windows_xfer_memory): Likewise.
(windows_xfer_shared_libraries): Likewise.
(windows_xfer_partial): Likewise.
* valprint.c: Replace 'target_xfer_error' with
'target_xfer_status' in comments.
2014-01-27 20:35:33 +08:00
|
|
|
return procfs_xfer_auxv (readbuf, writebuf, offset, len, xfered_len);
|
2010-01-14 21:15:00 +00:00
|
|
|
}
|
|
|
|
|
2020-04-08 04:01:10 +02:00
|
|
|
/* This function compared to other auxv_parse functions: it takes the size of
|
|
|
|
the auxv type field as a parameter. */
|
|
|
|
|
|
|
|
static int
|
2022-09-29 15:13:09 -04:00
|
|
|
generic_auxv_parse (struct gdbarch *gdbarch, const gdb_byte **readptr,
|
|
|
|
const gdb_byte *endptr, CORE_ADDR *typep, CORE_ADDR *valp,
|
2020-04-08 04:01:10 +02:00
|
|
|
int sizeof_auxv_type)
|
2004-02-01 22:35:24 +00:00
|
|
|
{
|
2020-04-08 04:01:10 +02:00
|
|
|
struct type *ptr_type = builtin_type (gdbarch)->builtin_data_ptr;
|
2022-09-21 11:05:21 -04:00
|
|
|
const int sizeof_auxv_val = ptr_type->length ();
|
2020-04-08 04:01:10 +02:00
|
|
|
enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
|
2022-09-29 15:13:09 -04:00
|
|
|
const gdb_byte *ptr = *readptr;
|
2004-02-01 22:35:24 +00:00
|
|
|
|
|
|
|
if (endptr == ptr)
|
|
|
|
return 0;
|
|
|
|
|
2020-04-08 04:01:10 +02:00
|
|
|
if (endptr - ptr < 2 * sizeof_auxv_val)
|
2004-02-01 22:35:24 +00:00
|
|
|
return -1;
|
|
|
|
|
2020-04-08 04:01:10 +02:00
|
|
|
*typep = extract_unsigned_integer (ptr, sizeof_auxv_type, byte_order);
|
|
|
|
/* Even if the auxv type takes less space than an auxv value, there is
|
|
|
|
padding after the type such that the value is aligned on a multiple of
|
|
|
|
its size (and this is why we advance by `sizeof_auxv_val` and not
|
|
|
|
`sizeof_auxv_type`). */
|
|
|
|
ptr += sizeof_auxv_val;
|
|
|
|
*valp = extract_unsigned_integer (ptr, sizeof_auxv_val, byte_order);
|
|
|
|
ptr += sizeof_auxv_val;
|
2004-02-01 22:35:24 +00:00
|
|
|
|
|
|
|
*readptr = ptr;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-04-08 04:01:10 +02:00
|
|
|
/* See auxv.h. */
|
|
|
|
|
|
|
|
int
|
2022-09-29 15:13:09 -04:00
|
|
|
default_auxv_parse (struct target_ops *ops, const gdb_byte **readptr,
|
|
|
|
const gdb_byte *endptr, CORE_ADDR *typep, CORE_ADDR *valp)
|
2020-04-08 04:01:10 +02:00
|
|
|
{
|
2023-09-29 14:24:38 -04:00
|
|
|
gdbarch *gdbarch = current_inferior ()->arch ();
|
2020-04-08 04:01:10 +02:00
|
|
|
struct type *ptr_type = builtin_type (gdbarch)->builtin_data_ptr;
|
2022-09-21 11:05:21 -04:00
|
|
|
const int sizeof_auxv_type = ptr_type->length ();
|
2020-04-08 04:01:10 +02:00
|
|
|
|
|
|
|
return generic_auxv_parse (gdbarch, readptr, endptr, typep, valp,
|
|
|
|
sizeof_auxv_type);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* See auxv.h. */
|
|
|
|
|
|
|
|
int
|
2022-09-29 15:13:09 -04:00
|
|
|
svr4_auxv_parse (struct gdbarch *gdbarch, const gdb_byte **readptr,
|
|
|
|
const gdb_byte *endptr, CORE_ADDR *typep, CORE_ADDR *valp)
|
2020-04-08 04:01:10 +02:00
|
|
|
{
|
|
|
|
struct type *int_type = builtin_type (gdbarch)->builtin_int;
|
2022-09-21 11:05:21 -04:00
|
|
|
const int sizeof_auxv_type = int_type->length ();
|
2020-04-08 04:01:10 +02:00
|
|
|
|
|
|
|
return generic_auxv_parse (gdbarch, readptr, endptr, typep, valp,
|
|
|
|
sizeof_auxv_type);
|
|
|
|
}
|
|
|
|
|
2008-05-04 09:28:27 +00:00
|
|
|
/* Read one auxv entry from *READPTR, not reading locations >= ENDPTR.
|
2022-09-29 16:08:24 -04:00
|
|
|
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
Use the auxv_parse method from GDBARCH, if defined, else use the auxv_parse
|
|
|
|
method of OPS.
|
2022-09-29 16:08:24 -04:00
|
|
|
|
2008-05-04 09:28:27 +00:00
|
|
|
Return 0 if *READPTR is already at the end of the buffer.
|
|
|
|
Return -1 if there is insufficient buffer for a whole entry.
|
|
|
|
Return 1 if an entry was read into *TYPEP and *VALP. */
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
|
2022-09-29 16:08:24 -04:00
|
|
|
static int
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
parse_auxv (target_ops *ops, gdbarch *gdbarch, const gdb_byte **readptr,
|
|
|
|
const gdb_byte *endptr, CORE_ADDR *typep, CORE_ADDR *valp)
|
2008-05-04 09:28:27 +00:00
|
|
|
{
|
2014-02-27 13:40:15 +01:00
|
|
|
if (gdbarch_auxv_parse_p (gdbarch))
|
|
|
|
return gdbarch_auxv_parse (gdbarch, readptr, endptr, typep, valp);
|
|
|
|
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
return ops->auxv_parse (readptr, endptr, typep, valp);
|
2008-05-04 09:28:27 +00:00
|
|
|
}
|
|
|
|
|
2011-11-15 13:17:05 +00:00
|
|
|
|
|
|
|
/* Auxiliary Vector information structure. This is used by GDB
|
|
|
|
for caching purposes for each inferior. This helps reduce the
|
|
|
|
overhead of transfering data from a remote target to the local host. */
|
|
|
|
struct auxv_info
|
|
|
|
{
|
2023-10-13 09:27:48 +00:00
|
|
|
std::optional<gdb::byte_vector> data;
|
2011-11-15 13:17:05 +00:00
|
|
|
};
|
|
|
|
|
2019-04-21 12:41:29 -06:00
|
|
|
/* Per-inferior data key for auxv. */
|
2020-10-18 11:38:10 -06:00
|
|
|
static const registry<inferior>::key<auxv_info> auxv_inferior_data;
|
2011-11-15 13:17:05 +00:00
|
|
|
|
|
|
|
/* Invalidate INF's auxv cache. */
|
|
|
|
|
|
|
|
static void
|
|
|
|
invalidate_auxv_cache_inf (struct inferior *inf)
|
|
|
|
{
|
2019-04-21 12:41:29 -06:00
|
|
|
auxv_inferior_data.clear (inf);
|
2011-11-15 13:17:05 +00:00
|
|
|
}
|
|
|
|
|
gdb: add all_objfiles_removed observer
The new_objfile observer is currently used to indicate both when a new
objfile is added to program space (when passed non-nullptr) and when all
objfiles of a program space were just removed (when passed nullptr).
I think this is confusing (and Andrew apparently thinks so too [1]).
Add a new "all_objfiles_removed" observer to remove the second role from
"new_objfile".
Some existing users of new_objfile do nothing if the passed objfile is
nullptr. For them, we can simply drop the nullptr check. For others,
add a new all_objfiles_removed callback, and refactor things a bit to
keep the existing behavior as much as possible.
Some callbacks relied on current_program_space, and following
the refactoring now use either objfile->pspace or the pspace passed to
all_objfiles_removed. I think this should be relatively safe, and in
general a step in the right direction.
On the notify side, I found only one call site to change from
new_objfile to all_objfiles_removed, in clear_symtab_users. It is not
entirely clear to me that this is entirely correct. clear_symtab_users
appears to be called in spots that don't remove all objfiles
(functions finish_new_objfile, remove_symbol_file_command, reread_symbols,
do_module_cleanups). But I think that this patch at least makes the
current code clearer.
[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/a0a031bce0527b1521788b5dad640e7883b3a252
Change-Id: Icb648f72862e056267f30f44dd439bd4ec766f13
Approved-By: Tom Tromey <tom@tromey.com>
2023-10-03 22:20:21 -04:00
|
|
|
/* Invalidate the auxv cache for all inferiors using PSPACE. */
|
2011-11-15 13:17:05 +00:00
|
|
|
|
|
|
|
static void
|
gdb: add all_objfiles_removed observer
The new_objfile observer is currently used to indicate both when a new
objfile is added to program space (when passed non-nullptr) and when all
objfiles of a program space were just removed (when passed nullptr).
I think this is confusing (and Andrew apparently thinks so too [1]).
Add a new "all_objfiles_removed" observer to remove the second role from
"new_objfile".
Some existing users of new_objfile do nothing if the passed objfile is
nullptr. For them, we can simply drop the nullptr check. For others,
add a new all_objfiles_removed callback, and refactor things a bit to
keep the existing behavior as much as possible.
Some callbacks relied on current_program_space, and following
the refactoring now use either objfile->pspace or the pspace passed to
all_objfiles_removed. I think this should be relatively safe, and in
general a step in the right direction.
On the notify side, I found only one call site to change from
new_objfile to all_objfiles_removed, in clear_symtab_users. It is not
entirely clear to me that this is entirely correct. clear_symtab_users
appears to be called in spots that don't remove all objfiles
(functions finish_new_objfile, remove_symbol_file_command, reread_symbols,
do_module_cleanups). But I think that this patch at least makes the
current code clearer.
[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/a0a031bce0527b1521788b5dad640e7883b3a252
Change-Id: Icb648f72862e056267f30f44dd439bd4ec766f13
Approved-By: Tom Tromey <tom@tromey.com>
2023-10-03 22:20:21 -04:00
|
|
|
auxv_all_objfiles_removed (program_space *pspace)
|
2011-11-15 13:17:05 +00:00
|
|
|
{
|
gdb: add all_objfiles_removed observer
The new_objfile observer is currently used to indicate both when a new
objfile is added to program space (when passed non-nullptr) and when all
objfiles of a program space were just removed (when passed nullptr).
I think this is confusing (and Andrew apparently thinks so too [1]).
Add a new "all_objfiles_removed" observer to remove the second role from
"new_objfile".
Some existing users of new_objfile do nothing if the passed objfile is
nullptr. For them, we can simply drop the nullptr check. For others,
add a new all_objfiles_removed callback, and refactor things a bit to
keep the existing behavior as much as possible.
Some callbacks relied on current_program_space, and following
the refactoring now use either objfile->pspace or the pspace passed to
all_objfiles_removed. I think this should be relatively safe, and in
general a step in the right direction.
On the notify side, I found only one call site to change from
new_objfile to all_objfiles_removed, in clear_symtab_users. It is not
entirely clear to me that this is entirely correct. clear_symtab_users
appears to be called in spots that don't remove all objfiles
(functions finish_new_objfile, remove_symbol_file_command, reread_symbols,
do_module_cleanups). But I think that this patch at least makes the
current code clearer.
[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/a0a031bce0527b1521788b5dad640e7883b3a252
Change-Id: Icb648f72862e056267f30f44dd439bd4ec766f13
Approved-By: Tom Tromey <tom@tromey.com>
2023-10-03 22:20:21 -04:00
|
|
|
for (inferior *inf : all_inferiors ())
|
|
|
|
if (inf->pspace == current_program_space)
|
|
|
|
invalidate_auxv_cache_inf (inf);
|
2011-11-15 13:17:05 +00:00
|
|
|
}
|
|
|
|
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
/* See auxv.h. */
|
2011-11-15 13:17:05 +00:00
|
|
|
|
2023-10-13 09:27:48 +00:00
|
|
|
const std::optional<gdb::byte_vector> &
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
target_read_auxv ()
|
2011-11-15 13:17:05 +00:00
|
|
|
{
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
inferior *inf = current_inferior ();
|
|
|
|
auxv_info *info = auxv_inferior_data.get (inf);
|
2011-11-15 13:17:05 +00:00
|
|
|
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
if (info == nullptr)
|
2011-11-15 13:17:05 +00:00
|
|
|
{
|
2019-04-21 12:41:29 -06:00
|
|
|
info = auxv_inferior_data.emplace (inf);
|
2022-10-11 20:53:39 -04:00
|
|
|
info->data = target_read_auxv_raw (inf->top_target ());
|
2011-11-15 13:17:05 +00:00
|
|
|
}
|
|
|
|
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
return info->data;
|
2011-11-15 13:17:05 +00:00
|
|
|
}
|
|
|
|
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
/* See auxv.h. */
|
|
|
|
|
2023-10-13 09:27:48 +00:00
|
|
|
std::optional<gdb::byte_vector>
|
2022-10-11 20:53:39 -04:00
|
|
|
target_read_auxv_raw (target_ops *ops)
|
2004-02-01 22:35:24 +00:00
|
|
|
{
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
return target_read_alloc (ops, TARGET_OBJECT_AUXV, NULL);
|
|
|
|
}
|
2011-11-15 13:17:05 +00:00
|
|
|
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
/* See auxv.h. */
|
2004-02-01 22:35:24 +00:00
|
|
|
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
int
|
|
|
|
target_auxv_search (const gdb::byte_vector &auxv, target_ops *ops,
|
|
|
|
gdbarch *gdbarch, CORE_ADDR match, CORE_ADDR *valp)
|
|
|
|
{
|
|
|
|
CORE_ADDR type, val;
|
|
|
|
const gdb_byte *data = auxv.data ();
|
2022-09-29 15:13:09 -04:00
|
|
|
const gdb_byte *ptr = data;
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
size_t len = auxv.size ();
|
2004-02-01 22:35:24 +00:00
|
|
|
|
|
|
|
while (1)
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
switch (parse_auxv (ops, gdbarch, &ptr, data + len, &type, &val))
|
2004-02-01 22:35:24 +00:00
|
|
|
{
|
|
|
|
case 1: /* Here's an entry, check it. */
|
|
|
|
if (type == match)
|
|
|
|
{
|
|
|
|
*valp = val;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
case 0: /* End of the vector. */
|
|
|
|
return 0;
|
|
|
|
default: /* Bogosity. */
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
/* See auxv.h. */
|
|
|
|
|
|
|
|
int
|
|
|
|
target_auxv_search (CORE_ADDR match, CORE_ADDR *valp)
|
|
|
|
{
|
2023-10-13 09:27:48 +00:00
|
|
|
const std::optional<gdb::byte_vector> &auxv = target_read_auxv ();
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
|
|
|
|
if (!auxv.has_value ())
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
return target_auxv_search (*auxv, current_inferior ()->top_target (),
|
2023-09-29 14:24:35 -04:00
|
|
|
current_inferior ()->arch (), match, valp);
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
}
|
2004-02-01 22:35:24 +00:00
|
|
|
|
2016-06-11 15:51:38 -07:00
|
|
|
/* Print the description of a single AUXV entry on the specified file. */
|
|
|
|
|
|
|
|
void
|
|
|
|
fprint_auxv_entry (struct ui_file *file, const char *name,
|
|
|
|
const char *description, enum auxv_format format,
|
|
|
|
CORE_ADDR type, CORE_ADDR val)
|
|
|
|
{
|
2023-09-29 14:24:38 -04:00
|
|
|
gdbarch *arch = current_inferior ()->arch ();
|
2022-01-02 11:46:15 -07:00
|
|
|
gdb_printf (file, ("%-4s %-20s %-30s "),
|
|
|
|
plongest (type), name, description);
|
2016-06-11 15:51:38 -07:00
|
|
|
switch (format)
|
|
|
|
{
|
|
|
|
case AUXV_FORMAT_DEC:
|
2022-01-02 11:46:15 -07:00
|
|
|
gdb_printf (file, ("%s\n"), plongest (val));
|
2016-06-11 15:51:38 -07:00
|
|
|
break;
|
|
|
|
case AUXV_FORMAT_HEX:
|
2023-09-29 14:24:38 -04:00
|
|
|
gdb_printf (file, ("%s\n"), paddress (arch, val));
|
2016-06-11 15:51:38 -07:00
|
|
|
break;
|
|
|
|
case AUXV_FORMAT_STR:
|
|
|
|
{
|
|
|
|
struct value_print_options opts;
|
|
|
|
|
|
|
|
get_user_print_options (&opts);
|
|
|
|
if (opts.addressprint)
|
2023-09-29 14:24:38 -04:00
|
|
|
gdb_printf (file, ("%s "), paddress (arch, val));
|
|
|
|
val_print_string (builtin_type (arch)->builtin_char,
|
2016-06-11 15:51:38 -07:00
|
|
|
NULL, val, -1, file, &opts);
|
2022-01-02 11:46:15 -07:00
|
|
|
gdb_printf (file, ("\n"));
|
2016-06-11 15:51:38 -07:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The default implementation of gdbarch_print_auxv_entry. */
|
|
|
|
|
|
|
|
void
|
|
|
|
default_print_auxv_entry (struct gdbarch *gdbarch, struct ui_file *file,
|
|
|
|
CORE_ADDR type, CORE_ADDR val)
|
|
|
|
{
|
|
|
|
const char *name = "???";
|
|
|
|
const char *description = "";
|
|
|
|
enum auxv_format format = AUXV_FORMAT_HEX;
|
|
|
|
|
|
|
|
switch (type)
|
|
|
|
{
|
|
|
|
#define TAG(tag, text, kind) \
|
|
|
|
case tag: name = #tag; description = text; format = kind; break
|
|
|
|
TAG (AT_NULL, _("End of vector"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_IGNORE, _("Entry should be ignored"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_EXECFD, _("File descriptor of program"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_PHDR, _("Program headers for program"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_PHENT, _("Size of program header entry"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_PHNUM, _("Number of program headers"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_PAGESZ, _("System page size"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_BASE, _("Base address of interpreter"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_FLAGS, _("Flags"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_ENTRY, _("Entry point of program"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_NOTELF, _("Program is not ELF"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_UID, _("Real user ID"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_EUID, _("Effective user ID"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_GID, _("Real group ID"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_EGID, _("Effective group ID"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_CLKTCK, _("Frequency of times()"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_PLATFORM, _("String identifying platform"), AUXV_FORMAT_STR);
|
|
|
|
TAG (AT_HWCAP, _("Machine-dependent CPU capability hints"),
|
|
|
|
AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_FPUCW, _("Used FPU control word"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_DCACHEBSIZE, _("Data cache block size"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_ICACHEBSIZE, _("Instruction cache block size"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_UCACHEBSIZE, _("Unified cache block size"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_IGNOREPPC, _("Entry should be ignored"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_BASE_PLATFORM, _("String identifying base platform"),
|
|
|
|
AUXV_FORMAT_STR);
|
|
|
|
TAG (AT_RANDOM, _("Address of 16 random bytes"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_HWCAP2, _("Extension of AT_HWCAP"), AUXV_FORMAT_HEX);
|
2023-06-22 01:03:04 +02:00
|
|
|
TAG (AT_RSEQ_FEATURE_SIZE, _("rseq supported feature size"),
|
|
|
|
AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_RSEQ_ALIGN, _("rseq allocation alignment"),
|
|
|
|
AUXV_FORMAT_DEC);
|
2016-06-11 15:51:38 -07:00
|
|
|
TAG (AT_EXECFN, _("File name of executable"), AUXV_FORMAT_STR);
|
|
|
|
TAG (AT_SECURE, _("Boolean, was exec setuid-like?"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_SYSINFO, _("Special system info/entry points"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_SYSINFO_EHDR, _("System-supplied DSO's ELF header"),
|
|
|
|
AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_L1I_CACHESHAPE, _("L1 Instruction cache information"),
|
|
|
|
AUXV_FORMAT_HEX);
|
2020-02-24 21:04:05 -03:00
|
|
|
TAG (AT_L1I_CACHESIZE, _("L1 Instruction cache size"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_L1I_CACHEGEOMETRY, _("L1 Instruction cache geometry"),
|
|
|
|
AUXV_FORMAT_HEX);
|
2016-06-11 15:51:38 -07:00
|
|
|
TAG (AT_L1D_CACHESHAPE, _("L1 Data cache information"), AUXV_FORMAT_HEX);
|
2020-02-24 21:04:05 -03:00
|
|
|
TAG (AT_L1D_CACHESIZE, _("L1 Data cache size"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_L1D_CACHEGEOMETRY, _("L1 Data cache geometry"),
|
|
|
|
AUXV_FORMAT_HEX);
|
2016-06-11 15:51:38 -07:00
|
|
|
TAG (AT_L2_CACHESHAPE, _("L2 cache information"), AUXV_FORMAT_HEX);
|
2020-02-24 21:04:05 -03:00
|
|
|
TAG (AT_L2_CACHESIZE, _("L2 cache size"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_L2_CACHEGEOMETRY, _("L2 cache geometry"), AUXV_FORMAT_HEX);
|
2016-06-11 15:51:38 -07:00
|
|
|
TAG (AT_L3_CACHESHAPE, _("L3 cache information"), AUXV_FORMAT_HEX);
|
2020-02-24 21:04:05 -03:00
|
|
|
TAG (AT_L3_CACHESIZE, _("L3 cache size"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_L3_CACHEGEOMETRY, _("L3 cache geometry"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_MINSIGSTKSZ, _("Minimum stack size for signal delivery"),
|
|
|
|
AUXV_FORMAT_HEX);
|
2016-06-11 15:51:38 -07:00
|
|
|
TAG (AT_SUN_UID, _("Effective user ID"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_SUN_RUID, _("Real user ID"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_SUN_GID, _("Effective group ID"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_SUN_RGID, _("Real group ID"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_SUN_LDELF, _("Dynamic linker's ELF header"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_SUN_LDSHDR, _("Dynamic linker's section headers"),
|
|
|
|
AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_SUN_LDNAME, _("String giving name of dynamic linker"),
|
|
|
|
AUXV_FORMAT_STR);
|
|
|
|
TAG (AT_SUN_LPAGESZ, _("Large pagesize"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_SUN_PLATFORM, _("Platform name string"), AUXV_FORMAT_STR);
|
Handle missing Solaris auxv entries
Currently, three tests FAIL on Solaris 11.4+ (amd64-pc-solaris2.11 and
sparcv9-sun-solaris2.11):
info auxv
[...]
2009 AT_SUN_HWCAP Machine-dependent CPU capability hints 0x3f5ff7
2023 ??? 0x0
0 AT_NULL End of vector 0x0
(gdb) WARNING: Unrecognized tag value: 2023 ??? 0x0
FAIL: gdb.base/auxv.exp: info auxv on live process
info auxv
4294969310 ??? 0x7fffbfffe410
9225589753816 ??? 0x7fffbfffe45c
[...]
WARNING: Unrecognized tag value: 4294969310 ??? 0x7fffbfffe410
WARNING: Unrecognized tag value: 9225589753816 ??? 0x7fffbfffe45c
WARNING: Unrecognized tag value: 140733193388037 ??? 0x6
[...]
2009 AT_SUN_HWCAP Machine-dependent CPU capability hints 0x3f5ff7
2023 ??? 0x0
0 AT_NULL End of vector 0x0
(gdb) WARNING: Unrecognized tag value: 2023 ??? 0x0
UNRESOLVED: gdb.base/auxv.exp: info auxv on native core dump
info auxv
[...]
2009 AT_SUN_HWCAP Machine-dependent CPU capability hints 0x3f5ff7
2023 ??? 0x0
0 AT_NULL End of vector 0x0
(gdb) WARNING: Unrecognized tag value: 2023 ??? 0x0
FAIL: gdb.base/auxv.exp: info auxv on gcore-created dump
The following patch fixes this by introducing the missing AT_SUN_*
values from Solaris 11.4+ <sys/auxv.h>. This lets the live and
gcore-created dump tests PASS.
I don't know yet what's the reason for those weird 'Unrecognized tag
value' warnings with native core dumps is; elfdump -n certainly doesn't
show them. However, native core dumps still need quite some work
(mostly in bfd) in this and other areas.
Tested on amd64-pc-solaris2.11.
gdb:
* auxv.c (default_print_auxv_entry): Reflect AT_SUN_CAP_HW1
renaming.
Handle AT_SUN_EMULATOR, AT_SUN_BRANDNAME, AT_SUN_BRAND_AUX1,
AT_SUN_BRAND_AUX2, AT_SUN_BRAND_AUX3, AT_SUN_CAP_HW2.
include:
* elf/common.h (AT_SUN_HWCAP): Rename to ...
(AT_SUN_CAP_HW1): ... this. Retain old name for backward
compatibility.
(AT_SUN_EMULATOR, AT_SUN_BRANDNAME, AT_SUN_BRAND_AUX1)
(AT_SUN_BRAND_AUX2, AT_SUN_BRAND_AUX3, AT_SUN_CAP_HW2): Define.
2018-09-20 10:23:46 +02:00
|
|
|
TAG (AT_SUN_CAP_HW1, _("Machine-dependent CPU capability hints"),
|
2016-06-11 15:51:38 -07:00
|
|
|
AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_SUN_IFLUSH, _("Should flush icache?"), AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_SUN_CPU, _("CPU name string"), AUXV_FORMAT_STR);
|
|
|
|
TAG (AT_SUN_EMUL_ENTRY, _("COFF entry point address"), AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_SUN_EMUL_EXECFD, _("COFF executable file descriptor"),
|
|
|
|
AUXV_FORMAT_DEC);
|
|
|
|
TAG (AT_SUN_EXECNAME,
|
|
|
|
_("Canonicalized file name given to execve"), AUXV_FORMAT_STR);
|
|
|
|
TAG (AT_SUN_MMU, _("String for name of MMU module"), AUXV_FORMAT_STR);
|
|
|
|
TAG (AT_SUN_LDDATA, _("Dynamic linker's data segment address"),
|
|
|
|
AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_SUN_AUXFLAGS,
|
|
|
|
_("AF_SUN_ flags passed from the kernel"), AUXV_FORMAT_HEX);
|
Handle missing Solaris auxv entries
Currently, three tests FAIL on Solaris 11.4+ (amd64-pc-solaris2.11 and
sparcv9-sun-solaris2.11):
info auxv
[...]
2009 AT_SUN_HWCAP Machine-dependent CPU capability hints 0x3f5ff7
2023 ??? 0x0
0 AT_NULL End of vector 0x0
(gdb) WARNING: Unrecognized tag value: 2023 ??? 0x0
FAIL: gdb.base/auxv.exp: info auxv on live process
info auxv
4294969310 ??? 0x7fffbfffe410
9225589753816 ??? 0x7fffbfffe45c
[...]
WARNING: Unrecognized tag value: 4294969310 ??? 0x7fffbfffe410
WARNING: Unrecognized tag value: 9225589753816 ??? 0x7fffbfffe45c
WARNING: Unrecognized tag value: 140733193388037 ??? 0x6
[...]
2009 AT_SUN_HWCAP Machine-dependent CPU capability hints 0x3f5ff7
2023 ??? 0x0
0 AT_NULL End of vector 0x0
(gdb) WARNING: Unrecognized tag value: 2023 ??? 0x0
UNRESOLVED: gdb.base/auxv.exp: info auxv on native core dump
info auxv
[...]
2009 AT_SUN_HWCAP Machine-dependent CPU capability hints 0x3f5ff7
2023 ??? 0x0
0 AT_NULL End of vector 0x0
(gdb) WARNING: Unrecognized tag value: 2023 ??? 0x0
FAIL: gdb.base/auxv.exp: info auxv on gcore-created dump
The following patch fixes this by introducing the missing AT_SUN_*
values from Solaris 11.4+ <sys/auxv.h>. This lets the live and
gcore-created dump tests PASS.
I don't know yet what's the reason for those weird 'Unrecognized tag
value' warnings with native core dumps is; elfdump -n certainly doesn't
show them. However, native core dumps still need quite some work
(mostly in bfd) in this and other areas.
Tested on amd64-pc-solaris2.11.
gdb:
* auxv.c (default_print_auxv_entry): Reflect AT_SUN_CAP_HW1
renaming.
Handle AT_SUN_EMULATOR, AT_SUN_BRANDNAME, AT_SUN_BRAND_AUX1,
AT_SUN_BRAND_AUX2, AT_SUN_BRAND_AUX3, AT_SUN_CAP_HW2.
include:
* elf/common.h (AT_SUN_HWCAP): Rename to ...
(AT_SUN_CAP_HW1): ... this. Retain old name for backward
compatibility.
(AT_SUN_EMULATOR, AT_SUN_BRANDNAME, AT_SUN_BRAND_AUX1)
(AT_SUN_BRAND_AUX2, AT_SUN_BRAND_AUX3, AT_SUN_CAP_HW2): Define.
2018-09-20 10:23:46 +02:00
|
|
|
TAG (AT_SUN_EMULATOR, _("Name of emulation binary for runtime linker"),
|
|
|
|
AUXV_FORMAT_STR);
|
|
|
|
TAG (AT_SUN_BRANDNAME, _("Name of brand library"), AUXV_FORMAT_STR);
|
|
|
|
TAG (AT_SUN_BRAND_AUX1, _("Aux vector for brand modules 1"),
|
|
|
|
AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_SUN_BRAND_AUX2, _("Aux vector for brand modules 2"),
|
|
|
|
AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_SUN_BRAND_AUX3, _("Aux vector for brand modules 3"),
|
|
|
|
AUXV_FORMAT_HEX);
|
|
|
|
TAG (AT_SUN_CAP_HW2, _("Machine-dependent CPU capability hints 2"),
|
|
|
|
AUXV_FORMAT_HEX);
|
2016-06-11 15:51:38 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
fprint_auxv_entry (file, name, description, format, type, val);
|
|
|
|
}
|
|
|
|
|
2010-12-31 19:16:37 +00:00
|
|
|
/* Print the contents of the target's AUXV on the specified file. */
|
2016-06-11 15:51:38 -07:00
|
|
|
|
2022-09-29 15:19:23 -04:00
|
|
|
static int
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
fprint_target_auxv (struct ui_file *file)
|
2004-02-01 22:35:24 +00:00
|
|
|
{
|
2023-09-29 14:24:38 -04:00
|
|
|
gdbarch *gdbarch = current_inferior ()->arch ();
|
2004-02-01 22:35:24 +00:00
|
|
|
CORE_ADDR type, val;
|
|
|
|
int ents = 0;
|
2023-10-13 09:27:48 +00:00
|
|
|
const std::optional<gdb::byte_vector> &auxv = target_read_auxv ();
|
2004-02-01 22:35:24 +00:00
|
|
|
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
if (!auxv.has_value ())
|
Make target_read_alloc & al return vectors
This patch started by changing target_read_alloc_1 to return a
byte_vector, to avoid manual memory management (in target_read_alloc_1
and in the callers). To communicate failures to the callers, it
actually returns a gdb::optional<gdb::byte_vector>.
Adjusting target_read_stralloc was a bit more tricky, since it wants to
return a buffer of char, and not gdb_byte. Since you can't just cast a
gdb::byte_vector into a gdb::def_vector<char>, I made
target_read_alloc_1 templated, so both versions (that return vectors of
gdb_byte and char) are generated. Since target_read_stralloc now
returns a gdb::char_vector instead of a gdb::unique_xmalloc_ptr<char>, a
few callers need to be adjusted.
gdb/ChangeLog:
* common/byte-vector.h (char_vector): New type.
* target.h (target_read_alloc): Return
gdb::optional<byte_vector>.
(target_read_stralloc): Return gdb::optional<char_vector>.
(target_get_osdata): Return gdb::optional<char_vector>.
* target.c (target_read_alloc_1): Templatize. Replacement
manual memory management with vector.
(target_read_alloc): Change return type, adjust.
(target_read_stralloc): Change return type, adjust.
(target_get_osdata): Change return type, adjust.
* auxv.c (struct auxv_info) <length>: Remove.
<data>: Change type to gdb::optional<byte_vector>.
(auxv_inferior_data_cleanup): Free auxv_info with delete.
(get_auxv_inferior_data): Allocate auxv_info with new, adjust.
(target_auxv_search): Adjust.
(fprint_target_auxv): Adjust.
* avr-tdep.c (avr_io_reg_read_command): Adjust.
* linux-tdep.c (linux_spu_make_corefile_notes): Adjust.
(linux_make_corefile_notes): Adjust.
* osdata.c (get_osdata): Adjust.
* remote.c (remote_get_threads_with_qxfer): Adjust.
(remote_memory_map): Adjust.
(remote_traceframe_info): Adjust.
(btrace_read_config): Adjust.
(remote_read_btrace): Adjust.
(remote_pid_to_exec_file): Adjust.
* solib-aix.c (solib_aix_get_library_list): Adjust.
* solib-dsbt.c (decode_loadmap): Don't free buf.
(dsbt_get_initial_loadmaps): Adjust.
* solib-svr4.c (svr4_current_sos_via_xfer_libraries): Adjust.
* solib-target.c (solib_target_current_sos): Adjust.
* tracepoint.c (sdata_make_value): Adjust.
* xml-support.c (xinclude_start_include): Adjust.
(xml_fetch_content_from_file): Adjust.
* xml-support.h (xml_fetch_another): Change return type.
(xml_fetch_content_from_file): Change return type.
* xml-syscall.c (xml_init_syscalls_info): Adjust.
* xml-tdesc.c (file_read_description_xml): Adjust.
(fetch_available_features_from_target): Change return type.
(target_fetch_description_xml): Adjust.
(target_read_description_xml): Adjust.
2018-04-07 13:19:12 -04:00
|
|
|
return -1;
|
2004-02-01 22:35:24 +00:00
|
|
|
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
const gdb_byte *data = auxv->data ();
|
2022-09-29 15:13:09 -04:00
|
|
|
const gdb_byte *ptr = data;
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
size_t len = auxv->size ();
|
2011-11-15 13:17:05 +00:00
|
|
|
|
2023-09-29 14:24:38 -04:00
|
|
|
while (parse_auxv (current_inferior ()->top_target (), gdbarch, &ptr,
|
|
|
|
data + len, &type, &val) > 0)
|
2004-02-01 22:35:24 +00:00
|
|
|
{
|
2016-06-11 15:51:38 -07:00
|
|
|
gdbarch_print_auxv_entry (gdbarch, file, type, val);
|
2004-02-01 22:35:24 +00:00
|
|
|
++ents;
|
2008-07-17 20:56:11 +00:00
|
|
|
if (type == AT_NULL)
|
|
|
|
break;
|
2004-02-01 22:35:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return ents;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
Constify add_info
This patch constifies add_info and updates all the info commands. The
bulk of this patch was written using a script; and then I did a manual
pass to fix up the remaining compilation errors.
I could not compile every changed file; in particular nto-procfs.c,
gnu-nat.c, and darwin-nat-info.c; but I at least tried to check the
correctness by inspection.
gdb/ChangeLog
2017-11-07 Tom Tromey <tom@tromey.com>
* frame.h (info_locals_command, info_args_command): Constify.
* auto-load.h (auto_load_info_scripts): Constify.
* inferior.h (registers_info): Constify.
* copying.c: Rebuild.
* copying.awk: Constify generated commands.
* auto-load.c (auto_load_info_scripts)
(info_auto_load_gdb_scripts): Constify.
* cli/cli-decode.c (struct cmd_list_element): Take a
cmd_const_cfunc_ftype.
* command.h (add_info): Take a cmd_const_cfunc_ftype.
* tui/tui-win.c (tui_all_windows_info): Constify.
* python/py-auto-load.c (info_auto_load_python_scripts):
Constify.
* cli/cli-cmds.c (show_command): Remove non-const overload.
* tracepoint.c (info_tvariables_command, info_scope_command):
Constify.
(info_static_tracepoint_markers_command): Constify.
* thread.c (info_threads_command): Constify.
(print_thread_info_1): Constify.
* target.c (info_target_command): Constify.
* symtab.c (info_sources_command, info_functions_command)
(info_types_command): Constify.
(info_variables_command): Remove non-const overload.
* symfile.c (info_ext_lang_command): Constify.
* stack.c (info_frame_command, info_locals_command)
(info_args_command): Constify.
(backtrace_command): Remove non-const overload.
* source.c (info_source_command, info_line_command): Constify.
* solib.c (info_sharedlibrary_command): Constify.
* skip.c (info_skip_command): Constify.
* ser-go32.c (info_serial_command): Constify.
* reverse.c (info_bookmarks_command): Constify.
* printcmd.c (info_symbol_command, info_address_command)
(info_display_command): Constify.
* osdata.c (info_osdata_command): Constify.
* objc-lang.c (info_selectors_command, info_classes_command):
Constify.
* nto-procfs.c (procfs_pidlist, procfs_meminfo): Constify.
* memattr.c (info_mem_command): Constify.
* macrocmd.c (info_macro_command, info_macros_command): Constify.
* linux-fork.c (info_checkpoints_command): Constify.
* infrun.c (info_signals_command): Constify.
* inflow.c (info_terminal_command): Constify.
* inferior.c (info_inferiors_command): Constify.
(print_inferior): Constify.
* infcmd.c (info_program_command, info_all_registers_command)
(info_registers_command, info_vector_command)
(info_float_command): Constify.
(registers_info): Constify.
* gnu-nat.c (info_send_rights_cmd, info_recv_rights_cmd)
(info_port_sets_cmd, info_dead_names_cmd, info_port_rights_cmd):
Constify.
* f-valprint.c (info_common_command): Constify.
* dcache.c (info_dcache_command): Constify.
(dcache_info_1): Constify.
* darwin-nat-info.c (info_mach_tasks_command)
(info_mach_task_command, info_mach_ports_command)
(info_mach_port_command, info_mach_threads_command)
(info_mach_thread_command, info_mach_regions_command)
(info_mach_regions_recurse_command, info_mach_region_command)
(info_mach_exceptions_command): Constify.
(get_task_from_args): Constify.
* cp-support.c (info_vtbl_command): Constify.
* breakpoint.c (info_watchpoints_command)
(info_tracepoints_command): Constify.
(info_breakpoints_command): Remove non-const overload.
* avr-tdep.c (avr_io_reg_read_command): Constify.
* auxv.c (info_auxv_command): Constify.
* ada-tasks.c (info_tasks_command): Constify.
(info_task): Constify.
* ada-lang.c (info_exceptions_command): Constify.
2017-10-13 22:07:26 -06:00
|
|
|
info_auxv_command (const char *cmd, int from_tty)
|
2004-02-01 22:35:24 +00:00
|
|
|
{
|
2020-09-28 19:38:25 -06:00
|
|
|
if (! target_has_stack ())
|
2005-01-05 Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
Committed by Andrew Cagney.
* ada-valprint.c, aix-thread.c, alpha-nat.c: I18n markup.
* alphabsd-nat.c, alphanbsd-tdep.c, amd64-linux-nat.c: I18n markup.
* amd64-tdep.c, amd64bsd-nat.c, amd64fbsd-nat.c: I18n markup.
* arch-utils.c, arm-linux-nat.c, arm-tdep.c: I18n markup.
* armnbsd-nat.c, armnbsd-tdep.c, auxv.c, avr-tdep.c: I18n markup.
* aix-thread.c (_initialize_aix_thread): Get rid of the
deprecated_add_show_from_set call.
* alpha-tdep.c (_initialize_alpha_tdep): Ditto.
* arm-tdep.c (_initialize_arm_tdep): Ditto.
* command.h (add_setshow_enum_cmd): Add arguments for returning
new list elements.
* cli/cli-decode.c (add_setshow_enum_cmd): Ditto.
* mips-tdep.c (_initialize_mips_tdep): Modify calls to
add_setshow_enum_cmd.
2005-01-05 15:43:50 +00:00
|
|
|
error (_("The program has no auxiliary information now."));
|
2004-02-01 22:35:24 +00:00
|
|
|
else
|
|
|
|
{
|
gdb: fix auxv caching
There's a flaw in the interaction of the auxv caching and the fact that
target_auxv_search allows reading auxv from an arbitrary target_ops
(passed in as a parameter). This has consequences as explained in this
thread:
https://inbox.sourceware.org/gdb-patches/20220719144542.1478037-1-luis.machado@arm.com/
In summary, when loading an AArch64 core file with MTE support by
passing the executable and core file names directly to GDB, we see the
MTE info:
$ ./gdb -nx --data-directory=data-directory -q aarch64-mte-gcore aarch64-mte-gcore.core
...
Program terminated with signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0000ffff8ef5e000
Allocation tag 0x1
Logical tag 0x0.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
But if we do it as two separate commands (file and core) we don't:
$ ./gdb -nx --data-directory=data-directory -q -ex "file aarch64-mte-gcore" -ex "core aarch64-mte-gcore.core"
...
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000aaaade3d0b4c in ?? ()
(gdb)
The problem with the latter is that auxv data gets improperly cached
between the two commands. When executing the file command, auxv gets
first queried here, when loading the executable:
#0 target_auxv_search (ops=0x55555b842400 <exec_ops>, match=0x9, valp=0x7fffffffc5d0) at /home/simark/src/binutils-gdb/gdb/auxv.c:383
#1 0x0000555557e576f2 in svr4_exec_displacement (displacementp=0x7fffffffc8c0) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2482
#2 0x0000555557e594d1 in svr4_relocate_main_executable () at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2878
#3 0x0000555557e5989e in svr4_solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib-svr4.c:2933
#4 0x0000555557e6e49f in solib_create_inferior_hook (from_tty=1) at /home/simark/src/binutils-gdb/gdb/solib.c:1253
#5 0x0000555557f33e29 in symbol_file_command (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/symfile.c:1655
#6 0x00005555573319c3 in file_command (arg=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/exec.c:555
#7 0x0000555556e47185 in do_simple_func (args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1, c=0x612000047740) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:95
#8 0x0000555556e551c9 in cmd_func (cmd=0x612000047740, args=0x7fffffffe01c "aarch64-mte-gcore", from_tty=1) at /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2543
#9 0x00005555580e63fd in execute_command (p=0x7fffffffe02c "e", from_tty=1) at /home/simark/src/binutils-gdb/gdb/top.c:692
#10 0x0000555557771913 in catch_command_errors (command=0x5555580e55ad <execute_command(char const*, int)>, arg=0x7fffffffe017 "file aarch64-mte-gcore", from_tty=1, do_bp_actions=true) at /home/simark/src/binutils-gdb/gdb/main.c:513
#11 0x0000555557771fba in execute_cmdargs (cmdarg_vec=0x7fffffffd570, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffd230) at /home/simark/src/binutils-gdb/gdb/main.c:608
#12 0x00005555577755ac in captured_main_1 (context=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1299
#13 0x0000555557775c2d in captured_main (data=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1320
#14 0x0000555557775cc2 in gdb_main (args=0x7fffffffda10) at /home/simark/src/binutils-gdb/gdb/main.c:1345
#15 0x00005555568bdcbe in main (argc=10, argv=0x7fffffffdba8) at /home/simark/src/binutils-gdb/gdb/gdb.c:32
Here, target_auxv_search is called on the inferior's target stack. The
target stack only contains the exec target, so the query returns empty
auxv data. This gets cached for that inferior in `auxv_inferior_data`.
In its constructor (before it is pushed to the inferior's target stack),
the core_target needs to identify the right target description from the
core, and for that asks the gdbarch to read a target description from
the core file. Because some implementations of
gdbarch_core_read_description (such as AArch64's) need to read auxv data
from the core in order to determine the right target description, the
core_target passes a pointer to itself, allowing implementations to call
target_auxv_search it. However, because we have previously cached
(empty) auxv data for that inferior, target_auxv_search searched that
cached (empty) auxv data, not auxv data read from the core. Remember
that this data was obtained by reading auxv on the inferior's target
stack, which only contained an exec target.
The problem I see is that while target_auxv_search offers the
flexibility of reading from an arbitrary (passed as an argument) target,
the caching doesn't do the distinction of which target is being queried,
and where the cached data came from. So, you could read auxv from a
target A, it gets cached, then you try to read auxv from a target B, and
it returns the cached data from target A. That sounds wrong. In our
case, we expect to read different auxv data from the core target than
what we have read from the target stack earlier, so it doesn't make
sense to hit the cache in this case.
To fix this, I propose splitting the code paths that read auxv data from
an inferior's target stack and those that read from a passed-in target.
The code path that reads from the target stack will keep caching,
whereas the one that reads from a passed-in target won't. And since,
searching in auxv data is independent from where this data came from,
split the "read" part from the "search" part.
From what I understand, auxv caching was introduced mostly to reduce
latency on remote connections, when doing many queries. With the change
I propose, only the queries done while constructing the core_target
end up not using cached auxv data. This is fine, because there are just
a handful of queries max, done at this point, and reading core files is
local.
The changes to auxv functions are:
- Introduce 2 target_read_auxv functions. One reads from an explicit
target_ops and doesn't do caching (to be used in
gdbarch_core_read_description context). The other takes no argument,
reads from the current inferior's target stack (it looks just like a
standard target function wrapper) and does caching.
The first target_read_auxv actually replaces get_auxv_inferior_data,
since it became a trivial wrapper around it.
- Change the existing target_auxv_search to not read auxv data from the
target, but to accept it as a parameter (a gdb::byte_vector). This
function doesn't care where the data came from, it just searches in
it. It still needs to take a target_ops and gdbarch to know how to
parse auxv entries.
- Add a convenience target_auxv_search overload that reads auxv
data from the inferior's target stack and searches in it. This
overload is useful to replace the exist target_auxv_search calls that
passed the `current_inferior ()->top_target ()` target and keep the
call sites short.
- Modify parse_auxv to accept a target_ops and gdbarch to use for
parsing entries. Not strictly related to the rest of this change,
but it seems like a good change in the context.
Changes in architecture-specific files (tdep and nat):
- In linux-tdep, linux_get_hwcap and linux_get_hwcap2 get split in two,
similar to target_auxv_search. One version receives auxv data,
target and arch as parameters. The other gets everything from the
current inferior. The latter is for convenience, to avoid making
call sites too ugly.
- Call sites of linux_get_hwcap and linux_get_hwcap2 are adjusted to
use either of the new versions. The call sites in
gdbarch_core_read_description context explicitly read auxv data from
the passed-in target and call the linux_get_hwcap{,2} function with
parameters. Other call sites use the versions without parameters.
- Same idea for arm_fbsd_read_description_auxv.
- Call sites of target_auxv_search that passed
`current_inferior ()->top_target ()` are changed to use the
target_auxv_search overload that works in the current inferior.
Reviewed-By: John Baldwin <jhb@FreeBSD.org>
Reviewed-By: Luis Machado <luis.machado@arm.com>
Change-Id: Ib775a220cf1e76443fb7da2fdff8fc631128fe66
2022-09-29 16:14:40 -04:00
|
|
|
int ents = fprint_target_auxv (gdb_stdout);
|
2010-05-18 19:23:37 +00:00
|
|
|
|
2004-02-01 22:35:24 +00:00
|
|
|
if (ents < 0)
|
2005-01-05 Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
Committed by Andrew Cagney.
* ada-valprint.c, aix-thread.c, alpha-nat.c: I18n markup.
* alphabsd-nat.c, alphanbsd-tdep.c, amd64-linux-nat.c: I18n markup.
* amd64-tdep.c, amd64bsd-nat.c, amd64fbsd-nat.c: I18n markup.
* arch-utils.c, arm-linux-nat.c, arm-tdep.c: I18n markup.
* armnbsd-nat.c, armnbsd-tdep.c, auxv.c, avr-tdep.c: I18n markup.
* aix-thread.c (_initialize_aix_thread): Get rid of the
deprecated_add_show_from_set call.
* alpha-tdep.c (_initialize_alpha_tdep): Ditto.
* arm-tdep.c (_initialize_arm_tdep): Ditto.
* command.h (add_setshow_enum_cmd): Add arguments for returning
new list elements.
* cli/cli-decode.c (add_setshow_enum_cmd): Ditto.
* mips-tdep.c (_initialize_mips_tdep): Modify calls to
add_setshow_enum_cmd.
2005-01-05 15:43:50 +00:00
|
|
|
error (_("No auxiliary vector found, or failed reading it."));
|
2004-02-01 22:35:24 +00:00
|
|
|
else if (ents == 0)
|
2005-01-05 Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
Committed by Andrew Cagney.
* ada-valprint.c, aix-thread.c, alpha-nat.c: I18n markup.
* alphabsd-nat.c, alphanbsd-tdep.c, amd64-linux-nat.c: I18n markup.
* amd64-tdep.c, amd64bsd-nat.c, amd64fbsd-nat.c: I18n markup.
* arch-utils.c, arm-linux-nat.c, arm-tdep.c: I18n markup.
* armnbsd-nat.c, armnbsd-tdep.c, auxv.c, avr-tdep.c: I18n markup.
* aix-thread.c (_initialize_aix_thread): Get rid of the
deprecated_add_show_from_set call.
* alpha-tdep.c (_initialize_alpha_tdep): Ditto.
* arm-tdep.c (_initialize_arm_tdep): Ditto.
* command.h (add_setshow_enum_cmd): Add arguments for returning
new list elements.
* cli/cli-decode.c (add_setshow_enum_cmd): Ditto.
* mips-tdep.c (_initialize_mips_tdep): Modify calls to
add_setshow_enum_cmd.
2005-01-05 15:43:50 +00:00
|
|
|
error (_("Auxiliary vector is empty."));
|
2004-02-01 22:35:24 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-01-13 14:01:38 -05:00
|
|
|
void _initialize_auxv ();
|
2004-02-01 22:35:24 +00:00
|
|
|
void
|
2020-01-13 14:01:38 -05:00
|
|
|
_initialize_auxv ()
|
2004-02-01 22:35:24 +00:00
|
|
|
{
|
|
|
|
add_info ("auxv", info_auxv_command,
|
2005-01-05 Baurjan Ismagulov <ibr@ata.cs.hun.edu.tr>
Committed by Andrew Cagney.
* ada-valprint.c, aix-thread.c, alpha-nat.c: I18n markup.
* alphabsd-nat.c, alphanbsd-tdep.c, amd64-linux-nat.c: I18n markup.
* amd64-tdep.c, amd64bsd-nat.c, amd64fbsd-nat.c: I18n markup.
* arch-utils.c, arm-linux-nat.c, arm-tdep.c: I18n markup.
* armnbsd-nat.c, armnbsd-tdep.c, auxv.c, avr-tdep.c: I18n markup.
* aix-thread.c (_initialize_aix_thread): Get rid of the
deprecated_add_show_from_set call.
* alpha-tdep.c (_initialize_alpha_tdep): Ditto.
* arm-tdep.c (_initialize_arm_tdep): Ditto.
* command.h (add_setshow_enum_cmd): Add arguments for returning
new list elements.
* cli/cli-decode.c (add_setshow_enum_cmd): Ditto.
* mips-tdep.c (_initialize_mips_tdep): Modify calls to
add_setshow_enum_cmd.
2005-01-05 15:43:50 +00:00
|
|
|
_("Display the inferior's auxiliary vector.\n\
|
|
|
|
This is information provided by the operating system at program startup."));
|
2011-11-15 13:17:05 +00:00
|
|
|
|
|
|
|
/* Observers used to invalidate the auxv cache when needed. */
|
2021-04-24 19:26:04 -04:00
|
|
|
gdb::observers::inferior_exit.attach (invalidate_auxv_cache_inf, "auxv");
|
|
|
|
gdb::observers::inferior_appeared.attach (invalidate_auxv_cache_inf, "auxv");
|
gdb: add all_objfiles_removed observer
The new_objfile observer is currently used to indicate both when a new
objfile is added to program space (when passed non-nullptr) and when all
objfiles of a program space were just removed (when passed nullptr).
I think this is confusing (and Andrew apparently thinks so too [1]).
Add a new "all_objfiles_removed" observer to remove the second role from
"new_objfile".
Some existing users of new_objfile do nothing if the passed objfile is
nullptr. For them, we can simply drop the nullptr check. For others,
add a new all_objfiles_removed callback, and refactor things a bit to
keep the existing behavior as much as possible.
Some callbacks relied on current_program_space, and following
the refactoring now use either objfile->pspace or the pspace passed to
all_objfiles_removed. I think this should be relatively safe, and in
general a step in the right direction.
On the notify side, I found only one call site to change from
new_objfile to all_objfiles_removed, in clear_symtab_users. It is not
entirely clear to me that this is entirely correct. clear_symtab_users
appears to be called in spots that don't remove all objfiles
(functions finish_new_objfile, remove_symbol_file_command, reread_symbols,
do_module_cleanups). But I think that this patch at least makes the
current code clearer.
[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/a0a031bce0527b1521788b5dad640e7883b3a252
Change-Id: Icb648f72862e056267f30f44dd439bd4ec766f13
Approved-By: Tom Tromey <tom@tromey.com>
2023-10-03 22:20:21 -04:00
|
|
|
gdb::observers::all_objfiles_removed.attach (auxv_all_objfiles_removed,
|
|
|
|
"auxv");
|
2004-02-01 22:35:24 +00:00
|
|
|
}
|