| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
If you add an initialization function to a .y file, it will not show
up in init.c, because if the yacc output is in the build tree, it
won't be found.
This patch changes the Makefile to be more robust in this situation.
|
|
This removes the current test 'main' from cp-name-parser.y. There
aren't any tests using this, and nowadays it would be better as a unit
test.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
Make target check//% is the gdb variant of a similar gcc make target [1].
When running tests using check//%:
...
$ cd build/gdb
$ make check//unix/{-fPIE/-pie,-fno-PIE/-no-pie} -j2 TESTS=gdb.server/*.exp
...
we get:
...
$ cat build/gdb/testsuite.unix.-fPIE.-pie/cache/portnum
2427
$ cat build/gdb/testsuite.unix.-fno-PIE.-no-pie/cache/portnum
2423
...
The problem is that there are two portnum files used in parallel.
Fix this by:
- creating a common lockdir build/gdb/testsuite.lockdir for make target
check//%,
- passing this down to the runtests invocations using variable GDB_LOCK_DIR,
and
- using GDB_LOCK_DIR in lock_dir.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31632
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31632
[1] https://gcc.gnu.org/install/test.html
|
|
Most files including gdbcmd.h currently rely on it to access things
actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make
things easy, replace all includes of gdbcmd.h with includes of
cli/cli-cmds.h. This might lead to some unused includes of
cli/cli-cmds.h, but it's harmless, and much faster than going through
the 170 or so files by hand.
Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Move the declarations out of defs.h, and the implementations out of
findvar.c.
I opted for a new file, because this functionality of converting
integers to bytes and vice-versa seems a bit to generic to live in
findvar.c.
Change-Id: I524858fca33901ee2150c582bac16042148d2251
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
For some reason install-dvi is missing although other targets of the
same family are present. This looks like an oversight.
This enables calling 'make install-dvi' from the top-level build
directory.
Fix what looks like another oversight: include 'pdf' in 'all-doc' in
gdb/doc/Makefile.in.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
The targets that use config.status to regenerate themselves don't
currently follow the silent rules that the rest of GDB's Makefile
does. For example, touch the gdb/gcore.in file and then 'make all' in
the gdb/ directory prints:
/bin/sh config.status gcore
config.status: creating gcore
In this commit I make use of the silent-rules.mk mechanism for these
targets, now we get:
GEN gcore
Which matches the rest of our Makefile. Obviously, if you pass 'V=1'
to the build then you'll get the old output back.
There's no change in what is generated after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I noticed that for the build targets jit-reader.h, gcore, gdb-gdb.py,
and gdb-gdb.gdb the rules all use the config.status script, but don't
have a dependency on the config.status target. This means we might
fail to regenerate these targets in a case where config.status, or one
of its dependencies changes.
Two other targets that use config.status do correctly have a
dependency on config.status.
Fixed in this commit by adding the missing dependencies.
There should be no changes in _what_ is generated after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I noticed something weird, the rule for the config.status target looks
like this:
config.status: $(srcdir)/configure configure.nat configure.tgt configure.host ../bfd/development.sh
$(SHELL) config.status --recheck
What bothered me is that 'configure' is specified as being in
$(srcdir), while all of the other files are not, even though those
files are in the same $(srcdir) as the configure script.
However, I tried touching one of those files, and the config.status
rule does trigger!
This is thanks to the VPATH variable, which is set to $(srcdir), so
make looks in $(srcdir) for any dependencies.
However, this inconsistency bothers me. Better, I think, to add the
$(srcdir) prefix to each of these files.
I also spotted that the configure script also includes the files
../bfd/config.bfd, yet that is missing from the include list, so in
this commit I plan to add this as a dependency.
The configure script also pulls in two TCL and TK related files:
. ${TCL_BIN_DIR}/tclConfig.sh
. ${TK_BIN_DIR}/tkConfig.sh
However, I don't think ${TCL_BIN_DIR} and ${TK_BIN_DIR} are currently
visible in GDB's Makefile, so I'm not planning to add these
dependencies at this time.
In this commit I add a new variable config_status_deps which holds the
list of all the dependencies for config.status, with the $(srcdir)
prefix included, and then I use this in the config.status rule.
After this commit config.status will regenerate if config.bfd changes,
which it wouldn't before, but nothing else changes.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The gcore script is initially generated by the configure process, just
like gdb-gdb.gdb and gdb-gdb.py. However if the gdb/gcore.in input
source is modified then 'make all' in the gdb/ directory does not
regenerate the gcore script.
This is different than the gdb-gdb.gdb and gdb-gdb.py files, if their
input is updated then 'make all' will regenerate these files.
The difference is that for gdb-gdb.* there is an explicit dependency
between the 'all' target and the generated file, this dependency is
missing for gcore.
This commit adds the dependency. Now, if gcore.in is changed, running
'make all' will regenerate the gcore script.
There is no change in _what_ is generated after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The motivation for this change is for analysis tools and IDEs to be
better at analyzing header files on their own.
There are some definitions and includes we want to occur at the very
beginning of all translation units. The way we currently do that is by
requiring all source files (.c and .cc files) to include one of defs.h
(for gdb), server.h (for gdbserver) of common-defs.h (for gdbsupport and
shared source files). These special header files define and include
everything that needs to be included at the very beginning. Other
header files are written in a way that assume that these special
"prologue" header files have already been included.
My problem with that is that my editor (clangd-based) provides a very
bad experience when editing header files. Since clangd doesn't know
that one of defs.h/server.h/common-defs.h was included already, a lot of
things are flagged as errors. For instance, CORE_ADDR is not known.
It's possible to edit the files in this state, but a lot of the power of
the editor is unavailable.
My proposal to help with this is to include those things we always want
to be there using the compilers' `-include` option. Tom Tromey said
that the current approach might exist because not all compilers used to
have an option like this. But I believe that it's safe to assume they
do today.
With this change, clangd picks up the -include option from the compile
command, and is able to analyze the header file correctly, as it sees
all that stuff included or defined by that -include option. That works
because when editing a header file, clangd tries to get the compilation
flags from a source file that includes said header file.
This change is a bit self-serving, because it addresses one of my
frustrations when editing header files, but it might help others too.
I'd be curious to know if others encounter the same kinds of problems
when editing header files. Also, even if the change is not necessary by
any means, I think the solution of using -include for stuff we always
want to be there is more elegant than the current solution.
Even with this -include flag, many header files currently don't include
what they use, but rather depend on files included before them. This
will still cause errors when editing them, but it should be easily
fixable by adding the appropriate include. There's no rush to do so, as
long as the code still compiles, it's just a convenience thing.
The changes are:
- Add the appropriate `-include` option to the various Makefiles.
- There is one particularity for gdbserver's Makefile: we do not want
to include server.h when building `gdbreplay.o`, as `gdbreplay.cc`
doesn't include it. So we can't simply put the `-include` in
`INTERNAL_CFLAGS`. Add the `-include server.h` option to the
`COMPILE` and `IPAGENT_COMPILE` variables, and added a special rule
to compile `gdbreplay.o` with `-include gdbsupport/common-defs.h`.
- Remove the `-include` option from the `check-headers` rule in
gdb/Makefile.in, since it is already included in `INTERNAL_CFLAGS`.
Change-Id: If3e345d00a9fc42336322f1d8286687d22134340
Approved-By: Pedro Alves <pedro@palves.net>
|
|
Remove `INTERNAL_CFLAGS_BASE` and `INTERNAL_WARN_CFLAGS`, inline their
contents in `INTERNAL_CFLAGS`. Not functional changes expected.
Change-Id: I6a09794835ca2cfd4a88a3e9f2e627c8f5bd569f
Approved-By: Pedro Alves <pedro@palves.net>
|
|
Reformat some variables definitions. I think it makes them easier to
read, and it also makes diffs clearer.
Change-Id: I82f63ba0e6d0fe268eb1f1ad5ab22c3cd016ab02
Approved-By: Pedro Alves <pedro@palves.net>
|
|
This reverts commit cd9b374ffe372dcaf7e4c15548cf53a301d8dcdd.
|
|
This commit is part of a series to share more of the x86 target
description creation code between GDB and gdbserver.
Unlike previous commits which were mostly refactoring, this commit is
the first that makes a real change, though that change should mostly
be for gdbserver; I've largely adopted the "GDB" way of doing things
for gdbserver, and this fixes a real gdbserver bug.
On a x86-64 Linux target, running the test:
gdb.server/connect-with-no-symbol-file.exp
results in two core files being created. Both of these core files are
from the inferior process, created after gdbserver has detached.
In this test a gdbserver process is started and then, after gdbserver
has started, but before GDB attaches, we either delete the inferior
executable, or change its permissions so it can't be read. Only after
doing this do we attempt to connect with GDB.
As GDB connects to gdbserver, gdbserver attempts to figure out the
target description so that it can send the description to GDB, this
involves a call to x86_linux_read_description.
In x86_linux_read_description one of the first things we do is try to
figure out if the process is 32-bit or 64-bit. To do this we look up
the executable via the thread-id, and then attempt to read the
architecture size from the executable. This isn't going to work if
the executable has been deleted, or is no longer readable.
And so, as we can't read the executable, we default to an i386 target
and use an i386 target description.
A consequence of using an i386 target description is that addresses
are assumed to be 32-bits. Here's an example session that shows the
problems this causes. This is run on an x86-64 machine, and the test
binary (xx.x) is a standard 64-bit x86-64 binary:
shell_1$ gdbserver --once localhost :54321 /tmp/xx.x
shell_2$ gdb -q
(gdb) set sysroot
(gdb) shell chmod 000 /tmp/xx.x
(gdb) target remote :54321
Remote debugging using :54321
warning: /tmp/xx.x: Permission denied.
0xf7fd3110 in ?? ()
(gdb) show architecture
The target architecture is set to "auto" (currently "i386").
(gdb) p/x $pc
$1 = 0xf7fd3110
(gdb) info proc mappings
process 2412639
Mapped address spaces:
Start Addr End Addr Size Offset Perms objfile
0x400000 0x401000 0x1000 0x0 r--p /tmp/xx.x
0x401000 0x402000 0x1000 0x1000 r-xp /tmp/xx.x
0x402000 0x403000 0x1000 0x2000 r--p /tmp/xx.x
0x403000 0x405000 0x2000 0x2000 rw-p /tmp/xx.x
0xf7fcb000 0xf7fcf000 0x4000 0x0 r--p [vvar]
0xf7fcf000 0xf7fd1000 0x2000 0x0 r-xp [vdso]
0xf7fd1000 0xf7fd3000 0x2000 0x0 r--p /usr/lib64/ld-2.30.so
0xf7fd3000 0xf7ff3000 0x20000 0x2000 r-xp /usr/lib64/ld-2.30.so
0xf7ff3000 0xf7ffb000 0x8000 0x22000 r--p /usr/lib64/ld-2.30.so
0xf7ffc000 0xf7ffe000 0x2000 0x2a000 rw-p /usr/lib64/ld-2.30.so
0xf7ffe000 0xf7fff000 0x1000 0x0 rw-p
0xfffda000 0xfffff000 0x25000 0x0 rw-p [stack]
0xff600000 0xff601000 0x1000 0x0 r-xp [vsyscall]
(gdb) info inferiors
Num Description Connection Executable
* 1 process 2412639 1 (remote :54321)
(gdb) shell cat /proc/2412639/maps
00400000-00401000 r--p 00000000 fd:03 45907133 /tmp/xx.x
00401000-00402000 r-xp 00001000 fd:03 45907133 /tmp/xx.x
00402000-00403000 r--p 00002000 fd:03 45907133 /tmp/xx.x
00403000-00405000 rw-p 00002000 fd:03 45907133 /tmp/xx.x
7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0 [vvar]
7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0 [vdso]
7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904 /usr/lib64/ld-2.30.so
7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904 /usr/lib64/ld-2.30.so
7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904 /usr/lib64/ld-2.30.so
7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904 /usr/lib64/ld-2.30.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
(gdb)
Notice the difference between the mappings reported via GDB and those
reported directly from the kernel via /proc/PID/maps, the addresses of
every mapping is clamped to 32-bits for GDB, while the kernel reports
real 64-bit addresses.
Notice also that the $pc value is a 32-bit value. It appears to be
within one of the mappings reported by GDB, but is outside any of the
mappings reported from the kernel.
And this is where the problem arises. When gdbserver detaches from
the inferior we pass the inferior the address from which it should
resume. Due to the 32/64 bit confusion we tell the inferior to resume
from the 32-bit $pc value, which is not within any valid mapping, and
so, as soon as the inferior resumes, it segfaults.
If we look at how GDB (not gdbserver) figures out its target
description then we see an interesting difference. GDB doesn't try to
read the executable. Instead GDB uses ptrace to query the thread's
state, and uses this to figure out the if the thread is 32 or 64 bit.
If we update gdbserver to do it the "GDB" way then the above problem
is resolved, gdbserver now sees the process as 64-bit, and when we
detach from the inferior we give it the correct 64-bit address, and
the inferior no longer segfaults.
Now, I could just update the gdbserver code, but better, I think, to
share one copy of the code between GDB and gdbserver in gdb/nat/.
That is what this commit does.
The cores of x86_linux_read_description from gdbserver and
x86_linux_nat_target::read_description from GDB are moved into a new
file gdb/nat/x86-linux-tdesc.c and combined into a single function
x86_linux_tdesc_for_tid which is called from each location.
This new function does things the GDB way, the only changes are to
allow for the sharing; we now have a callback function to call the
first time that the xcr0 state is read, this allows for GDB and
gdbserver to perform their own initialisation as needed, and
additionally, the new function takes a pointer for where to cache the
xcr0 value, this isn't needed for this commit, but will be useful in a
later commit where gdbserver will want to read this cached xcr0
value.
Another thing to note about this commit is how the functions
i386_linux_read_description and amd64_linux_read_description are
handled. For now I've left these function as implemented separately
in GDB and gdbserver. I've moved the declarations of these functions
into gdb/nat/x86-linux-tdesc.h, but the implementations are left as
separate.
A later commit in this series will make these functions shared too,
but doing this is not trivial, so I've left that for a separate
commit. Merging the declarations as I've done here ensures that
everyone implements the function to the same API, and once these
functions are shared (in a later commit) we'll want a shared
declaration anyway.
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
The other day on irc, we were discussing the "m_line" hack in
tui-out.c, and I mentioned that it would be nice to replace this with
a new ui_out_flag.
Later, I looked at ui_out_flag and found:
ui_source_list = (1 << 0),
... and sure enough, this is tested already.
This patch removes tui-out.[ch] and changes the TUI to use an ordinary
cli-out object without this flag set.
As far as I can tell, this doesn't affect behavior at all -- the TUI
tests all pass, and interactively I tried switching stack frames,
"list", etc, and it all seems to work.
New in v2: fixed the problem pointed out by Keith, and added a test
case for that scenario.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
aclocal picks up the relevant include paths from AC_CONFIG_MACRO_DIRS in
configure.ac, so there's no need to pass `-I ../config` here.
Passing `-I ../config` is actually annoying, because it makes the output
different between when the update is triggered by the maintainer mode
and when aclocal or autoreconf is ran with no special flags. The
difference in the output is due to the order of include paths being
different.
Change-Id: I2c963876516570842f20b4a6a470867e7a941006
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
The TUI status line is called the "status" window in the
documentation, but not in the source. There, the relevant files are
named "tui-stack", which to me makes it sound like they have something
to do with backtraces. This patch renames them to "tui-status".
|
|
The gdb/testsuite/README file documents GDB_DEBUG and GDBSERVER_DEBUG
flags, which can be passed to make in order to enable debugging within
GDB or gdbserver respectively.
However, when I do:
make check-gdb GDB_DEBUG=infrun
I don't see the corresponding debug feature within GDB being enabled.
Nor does:
make check-gdb GDBSERVER_DEBUG=debug \
RUNTESTFLAGS="--target_board=native-extended-gdbserver"
Appear to enable gdbserver debugging.
I tracked this down to the GDB_DEBUG and GDBSERVER_DEBUG flags being
missing from the TARGET_FLAGS_TO_PASS variable in gdb/Makefile. This
variable already contains lots of testing related flags, like
RUNTESTFLAGS and TESTS, so I think it makes sense to add GDB_DEBUG and
GDBSERVER_DEBUG here too.
With this done, this debug feature is now working as expected.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The make-check-all.sh script (gdb/testsuite/make-check-all.sh) is
great, it makes it super easy to run some test(s) using all the
available board files.
This commit aims to make this script even easier to access by adding a
check-all-boards target to the GDB Makefile. This new target checks
for (and requires) a number of environment variables, so the target
should be used like this:
make check-all-boards GDB_TARGET_USERNAME=remote-target \
GDB_HOST_USERNAME=remote-host \
TESTS="gdb.base/break.exp"
Where GDB_TARGET_USERNAME and GDB_HOST_USERNAME are the user names
that should be passed to the make-check-all.sh --target-user and
--host-user command line options respectively.
My personal intention is to set these variables in my environment, so
all I'll need to do is:
make check-all-boards TESTS="gdb.base/break.exp"
The make rule always passes --keep-results to the make-check-all.sh
script, as I find that the most useful. It's super frustrating to run
the tests and realise you forgot that option and the results have been
discarded.
|
|
Now that all places using gdb::string_view have been updated to use
std::string_view, this patch drops the gdb::string_view implementation
and the tests which came with it.
As this drops the unittests/string_view-selftests.c, this also
implicitly solves PR build/23676, as pointed-out by Tom Tromey.
Change-Id: Idf5479b09e0ac536917b3f0e13aca48424b90df0
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23676
|
|
The previous patch migrated all the uses of gdb::optional to use
std::optional instead, so gdb::optional can be removed entirely
as well as the self-tests which came with it.
Change-Id: I96ecd67b850b01be10ef00eb85a78ac647d5adc7
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
|
|
In the interest of shrinking dwarf2/read.c a little more, this patch
moves the code that deciphers .debug_aranges into a new file.
Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
|
|
The SME (Scalable Matrix Extension) [1] exposes a new matrix register ZA with
variable sizes. It also exposes a new mode called streaming mode.
Similarly to SVE, the ZA register size is dictated by a vector length, but the
SME vector length is called streaming vetor length. The total size for
ZA in a given moment is svl x svl.
In streaming mode, the SVE registers have their sizes based on svl rather than
the regular vector length (vl).
The feature detection is controlled by the HWCAP2_SME bit, but actual support
should be validated by attempting a ptrace call for one of the new register
sets: NT_ARM_ZA and NT_ARM_SSVE.
Due to its large size, the ZA register is exposed as a vector of bytes, but we
introduce a number of pseudo-registers that gives various different views
into the ZA contents. These can be arranged in a couple categories: tiles and
tile slices.
Tiles are matrices the same size or smaller than ZA. Tile slices are vectors
which map to ZA's rows/columns in different ways.
A new dynamic target description is provided containing the ZA register, the SVG
register and the SVCR register. The size of ZA, like the SVE vector registers,
is based on the vector length register SVG (VG for SVE).
This patch enables SME register support for gdb.
[1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/scalable-matrix-extension-armv9-a-architecture
Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
|
|
In preparation to the SME support patches, rename the SVE-specific files to
something a bit more meaningful that can be shared with the SME code.
In this case, I've renamed the "sve" in the names to "scalable".
No functional changes.
Regression-tested on aarch64-linux Ubuntu 22.04/20.04.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
|
|
psympriv.h was intended for use by code that created partial symbols.
Now that no generic code needs psymtab.h any more, psympriv.h can be
merged into psymtab.h.
|
|
When building gdb with -O2 -flto on openSUSE Tumbleweed (using bison 3.8.2) I
run into:
...
ada-exp.c.tmp:653: warning: type 'yysymbol_kind_t' violates the C++ One \
Definition Rule [-Wodr]
c-exp.c.tmp:398: note: an enum with different value name is defined in \
another translation unit
ada-exp.c.tmp:660: note: name 'YYSYMBOL_NULL_PTR' differs from name \
'YYSYMBOL_COMPLEX_INT' defined in another translation unit
c-exp.c.tmp:405: note: mismatching definition
...
Fix this by renaming to ada_exp_yysymbol_kind_t and likewise for other .y
files.
Tested on x86_64-linux.
PR build/22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
|
|
When building gdb with -O2 -flto I run into:
...
ada-exp.c.tmp:576:7: error: type ‘union YYSTYPE’ violates the C++ One \
Definition Rule [-Werror=odr]
...
Fix this by renaming to ada_exp_YYSTYPE and likewise for other .y files.
Likewise for yyalloc.
Tested on x86_64-linux. Also tested with byacc rather than bison on
suggestion of Tom Tromey.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
|
|
This reverts commit 02601231fdd91a7bd4837ce202906ea2ce661489.
This commit was a refactoring to remove an xrealloc and simplify
utils.[ch]. However, it has a flaw -- it mishandles a substitution
like "$datadir/subdir".
I am backing out the patch in the interests of fixing the regression
before GDB 14. It can be reinstated (with modifications) later if we
like.
Regression tested on x86-64 Fedora 36.
|
|
This adds a new Python function, gdb.execute_mi, that can be used to
invoke an MI command but get the output as a Python object, rather
than a string. This is done by implementing a new ui_out subclass
that builds a Python object.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11688
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
Ada can import C APIs and also export Ada constructs to C via Pragma
Import and Pragma Export. This patch adds support for these to gdb,
by arranging to either defer some aspects of a symbol to the
underlying C symbol (for Import) or by introducing a second symbol
(for Export). A somewhat tricky approach is needed, both because gdb
doesn't generally handle symbol aliasing, and because Ada treats
symbol names in an unusual way (as compared to the rest of gdb).
|
|
This simplifies auto_load_expand_dir_vars to first split the string,
then do any needed substitutions. This was suggested by Simon, and is
much simpler than the current approach.
Then this patch also removes substitute_path_component, as it is no
longer called. This is nice because it helps with the long term goal
of removing utils.h.
Regression tested on x86-64 Fedora 36.
|
|
I'd like to move some things so they become methods on struct ui. But
first, I think that struct ui and the related things are big enough to
deserve their own file, instead of being scattered through top.{c,h} and
event-top.c.
Change-Id: I15594269ace61fd76ef80a7b58f51ff3ab6979bc
|
|
Some systems may install binutils headers into a system location
(e.g. /usr/local/include on FreeBSD) which may also include headers
for other external packages used by GDB such as zlib or zstd. If a
system include path such as /usr/local/include is added before local
include paths to directories within a clone or release tarball, then
headers from the external binutils package are used which can result
in build failures if the external binutils package is out of sync with
the version of GDB being built.
To fix, sort the include paths in INTERNAL_CFLAGS_BASE to add CFLAGS
for "local" componenets before external components.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30214
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
The recent work to have gdb link via libtool means that there are a
couple more generated files in the build directory that should be
removed by "distclean".
Note that gdb can't really fully implement distclean due to the desire
to put certain generated files into the distribution. Still, it can
get pretty close.
|
|
I noticed that the --disable-gdbmi option was broken for almost a year
(since 740b42ceb7c "gdb/python/mi: create MI commands using python").
The problem today is the python/py-cmd.c file. It is included in the
build if Python support is enabled, and it calls into some MI functions
(e.g. insert_mi_cmd_entry). If MI support is disabled, we get some
undefined symbols like:
mold: error: undefined symbol: insert_mi_cmd_entry(std::unique_ptr<mi_command, std::default_delete<mi_command> >)
>>> referenced by py-micmd.c
>>> python/py-micmd.o:(micmdpy_install_command(micmdpy_object*))
The python/py-cmd.c file should be included in the build if both Python
and MI support are enabled. It is not a case we support today, but it
could be done with a bit more configure code. However, I think we
should just remove the --disable-gdbmi option, and just include MI
support unconditionally.
Tom Tromey proposed a while ago to remove this option, but it ended
staying:
https://inbox.sourceware.org/gdb-patches/20180628172132.28843-1-tom@tromey.com/
However, there was no strong opposition to remove it. The argument was
just "bah, it doesn't hurt anybody".
But given today's case, I would rather remove complexity rather than add
some. I couldn't find anybody caring deeply for that option, and it's
not like MI adds any external dependency. It's just a bit more code.
Removing the option will not break anybody using --disable-gdbmi (it can
be found in many build scripts [1]), since we don't flag invalid
configure flags.
So, remove the option from configure.ac, and adjust Makefile.in
accordingly to always include the MI objects in the build.
[1] https://github.com/search?q=%22--disable-gdbmi%22&type=code
Change-Id: Ifcaa8c9fc4abc6fa686ed5fd984598644f745240
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Commit 18b4d0736bc5 ("gdb: initial support for ROCm platform (AMDGPU)
debugging") missed adding these header files to the HFILES_NO_SRCDIR
list in the Makefile. Fix that now.
Change-Id: Ifd387096aef3d147b51aefa2037da5bf6373ea64
|
|
Move everything related to reading .debug_names from read.c to
read-debug-names.c. The only entry point exposed by
read-debug-names.{c,h} is dwarf2_read_debug_names.
Change-Id: I18b23f3c7a61b14abc3a46e4bf559bc2d078e8bc
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Move everything related to reading .gdb_index from read.c to
read-gdb-index.c. The only entry point exposed by read-gdb-index.{c,h}
is dwarf2_read_gdb_index.
Change-Id: I1e32c8f0720086538de8d2f612f27545377099bc
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch introduces a new file, dwarf2/die.c, and moves some
DIE-related code out of dwarf2/read.c and into this new file. This is
just a small part of the long-term project to split up read.c.
(According to 'wc', dwarf2/read.c is the largest file in gdb by around
8000 LOC.)
Regression tested on x86-64 Fedora 36.
|
|
This patch adds the foundation for GDB to be able to debug programs
offloaded to AMD GPUs using the AMD ROCm platform [1]. The latest
public release of the ROCm release at the time of writing is 5.4, so
this is what this patch targets.
The ROCm platform allows host programs to schedule bits of code for
execution on GPUs or similar accelerators. The programs running on GPUs
are typically referred to as `kernels` (not related to operating system
kernels).
Programs offloaded with the AMD ROCm platform can be written in the HIP
language [2], OpenCL and OpenMP, but we're going to focus on HIP here.
The HIP language consists of a C++ Runtime API and kernel language.
Here's an example of a very simple HIP program:
#include "hip/hip_runtime.h"
#include <cassert>
__global__ void
do_an_addition (int a, int b, int *out)
{
*out = a + b;
}
int
main ()
{
int *result_ptr, result;
/* Allocate memory for the device to write the result to. */
hipError_t error = hipMalloc (&result_ptr, sizeof (int));
assert (error == hipSuccess);
/* Run `do_an_addition` on one workgroup containing one work item. */
do_an_addition<<<dim3(1), dim3(1), 0, 0>>> (1, 2, result_ptr);
/* Copy result from device to host. Note that this acts as a synchronization
point, waiting for the kernel dispatch to complete. */
error = hipMemcpyDtoH (&result, result_ptr, sizeof (int));
assert (error == hipSuccess);
printf ("result is %d\n", result);
assert (result == 3);
return 0;
}
This program can be compiled with:
$ hipcc simple.cpp -g -O0 -o simple
... where `hipcc` is the HIP compiler, shipped with ROCm releases. This
generates an ELF binary for the host architecture, containing another
ELF binary with the device code. The ELF for the device can be
inspected with:
$ roc-obj-ls simple
1 host-x86_64-unknown-linux file://simple#offset=8192&size=0
1 hipv4-amdgcn-amd-amdhsa--gfx906 file://simple#offset=8192&size=34216
$ roc-obj-extract 'file://simple#offset=8192&size=34216'
$ file simple-offset8192-size34216.co
simple-offset8192-size34216.co: ELF 64-bit LSB shared object, *unknown arch 0xe0* version 1, dynamically linked, with debug_info, not stripped
^
amcgcn architecture that my `file` doesn't know about ----´
Running the program gives the very unimpressive result:
$ ./simple
result is 3
While running, this host program has copied the device program into the
GPU's memory and spawned an execution thread on it. The goal of this
GDB port is to let the user debug host threads and these GPU threads
simultaneously. Here's a sample session using a GDB with this patch
applied:
$ ./gdb -q -nx --data-directory=data-directory ./simple
Reading symbols from ./simple...
(gdb) break do_an_addition
Function "do_an_addition" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (do_an_addition) pending.
(gdb) r
Starting program: /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff5db7640 (LWP 1082911)]
[New Thread 0x7ffef53ff640 (LWP 1082913)]
[Thread 0x7ffef53ff640 (LWP 1082913) exited]
[New Thread 0x7ffdecb53640 (LWP 1083185)]
[New Thread 0x7ffff54bf640 (LWP 1083186)]
[Thread 0x7ffdecb53640 (LWP 1083185) exited]
[Switching to AMDGPU Wave 2:2:1:1 (0,0,0)/0]
Thread 6 hit Breakpoint 1, do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
24 *out = a + b;
(gdb) info inferiors
Num Description Connection Executable
* 1 process 1082907 1 (native) /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple
(gdb) info threads
Id Target Id Frame
1 Thread 0x7ffff5dc9240 (LWP 1082907) "simple" 0x00007ffff5e9410b in ?? () from /opt/rocm-5.4.0/lib/libhsa-runtime64.so.1
2 Thread 0x7ffff5db7640 (LWP 1082911) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
5 Thread 0x7ffff54bf640 (LWP 1083186) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
* 6 AMDGPU Wave 2:2:1:1 (0,0,0)/0 do_an_addition (
a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
(gdb) bt
Python Exception <class 'gdb.error'>: Unhandled dwarf expression opcode 0xe1
#0 do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
(gdb) continue
Continuing.
result is 3
warning: Temporarily disabling breakpoints for unloaded shared library "file:///home/smarchi/build/binutils-gdb-amdgpu/gdb/simple#offset=8192&size=67208"
[Thread 0x7ffff54bf640 (LWP 1083186) exited]
[Thread 0x7ffff5db7640 (LWP 1082911) exited]
[Inferior 1 (process 1082907) exited normally]
One thing to notice is the host and GPU threads appearing under
the same inferior. This is a design goal for us, as programmers tend to
think of the threads running on the GPU as part of the same program as
the host threads, so showing them in the same inferior in GDB seems
natural. Also, the host and GPU threads share a global memory space,
which fits the inferior model.
Another thing to notice is the error messages when trying to read
variables or printing a backtrace. This is expected for the moment,
since the AMD GPU compiler produces some DWARF that uses some
non-standard extensions:
https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html
There were already some patches posted by Zoran Zaric earlier to make
GDB support these extensions:
https://inbox.sourceware.org/gdb-patches/20211105113849.118800-1-zoran.zaric@amd.com/
We think it's better to get the basic support for AMD GPU in first,
which will then give a better justification for GDB to support these
extensions.
GPU threads are named `AMDGPU Wave`: a wave is essentially a hardware
thread using the SIMT (single-instruction, multiple-threads) [3]
execution model.
GDB uses the amd-dbgapi library [4], included in the ROCm platform, for
a few things related to AMD GPU threads debugging. Different components
talk to the library, as show on the following diagram:
+---------------------------+ +-------------+ +------------------+
| GDB | amd-dbgapi target | <-> | AMD | | Linux kernel |
| +-------------------+ | Debugger | +--------+ |
| | amdgcn gdbarch | <-> | API | <=> | AMDGPU | |
| +-------------------+ | | | driver | |
| | solib-rocm | <-> | (dbgapi.so) | +--------+---------+
+---------------------------+ +-------------+
- The amd-dbgapi target is a target_ops implementation used to control
execution of GPU threads. While the debugging of host threads works
by using the ptrace / wait Linux kernel interface (as usual), control
of GPU threads is done through a special interface (dubbed `kfd`)
exposed by the `amdgpu` Linux kernel module. GDB doesn't interact
directly with `kfd`, but instead goes through the amd-dbgapi library
(AMD Debugger API on the diagram).
Since it provides execution control, the amd-dbgapi target should
normally be a process_stratum_target, not just a target_ops. More
on that later.
- The amdgcn gdbarch (describing the hardware architecture of the GPU
execution units) offloads some requests to the amd-dbgapi library,
so that knowledge about the various architectures doesn't need to be
duplicated and baked in GDB. This is for example for things like
the list of registers.
- The solib-rocm component is an solib provider that fetches the list of
code objects loaded on the device from the amd-dbgapi library, and
makes GDB read their symbols. This is very similar to other solib
providers that handle shared libraries, except that here the shared
libraries are the pieces of code loaded on the device.
Given that Linux host threads are managed by the linux-nat target, and
the GPU threads are managed by the amd-dbgapi target, having all threads
appear in the same inferior requires the two targets to be in that
inferior's target stack. However, there can only be one
process_stratum_target in a given target stack, since there can be only
one target per slot. To achieve it, we therefore resort the hack^W
solution of placing the amd-dbgapi target in the arch_stratum slot of
the target stack, on top of the linux-nat target. Doing so allows the
amd-dbgapi target to intercept target calls and handle them if they
concern GPU threads, and offload to beneath otherwise. See
amd_dbgapi_target::fetch_registers for a simple example:
void
amd_dbgapi_target::fetch_registers (struct regcache *regcache, int regno)
{
if (!ptid_is_gpu (regcache->ptid ()))
{
beneath ()->fetch_registers (regcache, regno);
return;
}
// handle it
}
ptids of GPU threads are crafted with the following pattern:
(pid, 1, wave id)
Where pid is the inferior's pid and "wave id" is the wave handle handed
to us by the amd-dbgapi library (in practice, a monotonically
incrementing integer). The idea is that on Linux systems, the
combination (pid != 1, lwp == 1) is not possible. lwp == 1 would always
belong to the init process, which would also have pid == 1 (and it's
improbable for the init process to offload work to the GPU and much less
for the user to debug it). We can therefore differentiate GPU and
non-GPU ptids this way. See ptid_is_gpu for more details.
Note that we believe that this scheme could break down in the context of
containers, where the initial process executed in a container has pid 1
(in its own pid namespace). For instance, if you were to execute a ROCm
program in a container, then spawn a GDB in that container and attach to
the process, it will likely not work. This is a known limitation. A
workaround for this is to have a dummy process (like a shell) fork and
execute the program of interest.
The amd-dbgapi target watches native inferiors, and "attaches" to them
using amd_dbgapi_process_attach, which gives it a notifier fd that is
registered in the event loop (see enable_amd_dbgapi). Note that this
isn't the same "attach" as in PTRACE_ATTACH, but being ptrace-attached
is a precondition for amd_dbgapi_process_attach to work. When the
debugged process enables the ROCm runtime, the amd-dbgapi target gets
notified through that fd, and pushes itself on the target stack of the
inferior. The amd-dbgapi target is then able to intercept target_ops
calls. If the debugged process disables the ROCm runtime, the
amd-dbgapi target unpushes itself from the target stack.
This way, the amd-dbgapi target's footprint stays minimal when debugging
a process that doesn't use the AMD ROCm platform, it does not intercept
target calls.
The amd-dbgapi library is found using pkg-config. Since enabling
support for the amdgpu architecture (amdgpu-tdep.c) depends on the
amd-dbgapi library being present, we have the following logic for
the interaction with --target and --enable-targets:
- if the user explicitly asks for amdgcn support with
--target=amdgcn-*-* or --enable-targets=amdgcn-*-*, we probe for
the amd-dbgapi and fail if not found
- if the user uses --enable-targets=all, we probe for amd-dbgapi,
enable amdgcn support if found, disable amdgcn support if not found
- if the user uses --enable-targets=all and --with-amd-dbgapi=yes,
we probe for amd-dbgapi, enable amdgcn if found and fail if not found
- if the user uses --enable-targets=all and --with-amd-dbgapi=no,
we do not probe for amd-dbgapi, disable amdgcn support
- otherwise, amd-dbgapi is not probed for and support for amdgcn is not
enabled
Finally, a simple test is included. It only tests hitting a breakpoint
in device code and resuming execution, pretty much like the example
shown above.
[1] https://docs.amd.com/category/ROCm_v5.4
[2] https://docs.amd.com/bundle/HIP-Programming-Guide-v5.4
[3] https://en.wikipedia.org/wiki/Single_instruction,_multiple_threads
[4] https://docs.amd.com/bundle/ROCDebugger-API-Guide-v5.4
Change-Id: I591edca98b8927b1e49e4b0abe4e304765fed9ee
Co-Authored-By: Zoran Zaric <zoran.zaric@amd.com>
Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com>
Co-Authored-By: Tony Tye <Tony.Tye@amd.com>
Co-Authored-By: Lancelot SIX <lancelot.six@amd.com>
Co-Authored-By: Pedro Alves <pedro@palves.net>
|
|
This patch teaches frame_info_ptr to reinflate user-created frames
(frames created through create_new_frame, with the "select-frame view"
command).
Before this patch, frame_info_ptr doesn't support reinflating
user-created frames, because it currently reinflates by getting the
current target frame (for frame 0) or frame_find_by_id (for other
frames). To reinflate a user-created frame, we need to call
create_new_frame, to make it lookup an existing user-created frame, or
otherwise create one.
So, in prepare_reinflate, get the frame id even if the frame has level
0, if it is user-created. In reinflate, if the saved frame id is user
create it, call create_new_frame.
In order to test this, I initially enhanced the gdb.base/frame-view.exp
test added by the previous patch by setting a pretty-printer for the
type of the function parameters, in which we do an inferior call. This
causes print_frame_args to not reinflate its frame (which is a
user-created one) properly. On one machine (my Arch Linux one), it
properly catches the bug, as the frame is not correctly restored after
printing the first parameter, so it messes up the second parameter:
frame
#0 baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40
40 return z1.m + z2.n;
(gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame
frame
#0 baz (z1=hahaha, z2=<error reading variable: frame address is not available.>) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/frame-view.c:40
40 return z1.m + z2.n;
(gdb) FAIL: gdb.base/frame-view.exp: with_pretty_printer=true: frame again
However, on another machine (my Ubuntu 22.04 one), it just passes fine,
without the appropriate fix. I then thought about writing a selftest
for that, it's more reliable. I left the gdb.base/frame-view.exp pretty
printer test there, it's already written, and we never know, it might
catch some unrelated issue some day.
Change-Id: I5849baf77991fc67a15bfce4b5e865a97265b386
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
A patch later in this series will make frame_info_ptr access some
fields internal to frame_info, which we don't want to expose outside of
frame.c. Move the frame_info_ptr class to frame.h, and the definitions
to frame.c. Remove frame-info.c and frame-info.h.
Change-Id: Ic5949759e6262ea0da6123858702d48fe5673fea
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
|
|
The Debugger Adapter Protocol is a JSON-RPC protocol that IDEs can use
to communicate with debuggers. You can find more information here:
https://microsoft.github.io/debug-adapter-protocol/
Frequently this is implemented as a shim, but it seemed to me that GDB
could implement it directly, via the Python API. This patch is the
initial implementation.
DAP is implemented as a new "interp". This is slightly weird, because
it doesn't act like an ordinary interpreter -- for example it doesn't
implement a command syntax, and doesn't use GDB's ordinary event loop.
However, this seemed like the best approach overall.
To run GDB in this mode, use:
gdb -i=dap
The DAP code will accept JSON-RPC messages on stdin and print
responses to stdout. GDB redirects the inferior's stdout to a new
pipe so that output can be encapsulated by the protocol.
The Python code uses multiple threads to do its work. Separate
threads are used for reading JSON from the client and for writing JSON
to the client. All GDB work is done in the main thread. (The first
implementation used asyncio, but this had some limitations, and so I
rewrote it to use threads instead.)
This is not a complete implementation of the protocol, but it does
implement enough to demonstrate that the overall approach works.
There is a rudimentary test suite. It uses a JSON parser written in
pure Tcl. This parser is under the same license as Tcl itself, so I
felt it was acceptable to simply import it into the tree.
There is also a bit of documentation -- just documenting the new
interpreter name.
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
This patch uses the toplevel configure parts for GMP/MPFR for
gdb. The only thing is that gdb now requires MPFR for building.
Before it was a recommended but not required library.
Also this allows building of GMP and MPFR with the toplevel
directory just like how it is done for GCC.
We now error out in the toplevel configure of the version
of GMP and MPFR that is wrong.
OK after GDB 13 branches? Build gdb 3 ways:
with GMP and MPFR in the toplevel (static library used at that point for both)
With only MPFR in the toplevel (GMP distro library used and MPFR built from source)
With neither GMP and MPFR in the toplevel (distro libraries used)
Changes from v1:
* Updated gdb/README and gdb/doc/gdb.texinfo.
* Regenerated using unmodified autoconf-2.69
Thanks,
Andrew Pinski
ChangeLog:
* Makefile.def: Add configure-gdb dependencies
on all-gmp and all-mpfr.
* configure.ac: Split out MPC checking from MPFR.
Require GMP and MPFR if the gdb directory exist.
* Makefile.in: Regenerate.
* configure: Regenerate.
gdb/ChangeLog:
PR bug/28500
* configure.ac: Remove AC_LIB_HAVE_LINKFLAGS
for gmp and mpfr.
Use GMPLIBS and GMPINC which is provided by the
toplevel configure.
* Makefile.in (LIBGMP, LIBMPFR): Remove.
(GMPLIBS, GMPINC): Add definition.
(INTERNAL_CFLAGS_BASE): Add GMPINC.
(CLIBS): Exchange LIBMPFR and LIBGMP
for GMPLIBS.
* target-float.c: Make the code conditional on
HAVE_LIBMPFR unconditional.
* top.c: Remove code checking HAVE_LIBMPFR.
* configure: Regenerate.
* config.in: Regenerate.
* README: Update GMP/MPFR section of the config
options.
* doc/gdb.texinfo: Likewise.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28500
|
|
The libtool patch broke install-strip of gdb:
/bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/share/gdb/python/gdb
transformed_name=`t='s,y,y,'; \
echo gdb | sed -e "$t"` ; \
if test "x$transformed_name" = x; then \
transformed_name=gdb ; \
else \
true ; \
fi ; \
/bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/bin ; \
/bin/sh ./libtool --mode=install STRIPPROG='strip' /bin/sh /src/gdb/gdb.git/install-sh -c -s \
gdb \
/src/gdb/inst/bin/$transformed_name ; \
/bin/sh ../../gdb/../mkinstalldirs /src/gdb/inst/include/gdb ; \
/usr/bin/install -c -m 644 jit-reader.h /src/gdb/inst/include/gdb/jit-reader.h
libtool: install: `/src/gdb/inst/bin/gdb' is not a directory
libtool: install: Try `libtool --help --mode=install' for more information.
Since INSTALL_PROGRAM_ENV is no longer at the beginning of the command, the
gdb executable is not installed with install-strip.
|
|
I don't see any particular reason why the implementations of the
frame_info_ptr object are in the header file. It only seems to add some
complexity. Since we can't include frame.h in frame-info.h, we have to
add declarations of functions defined in frame.c, in frame-info.h. By
moving the implementations to a new frame-info.c, we can avoid that.
Change-Id: I435c828f81b8a3392c43ef018af31effddf6be9c
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
Reviewed-By: Tom Tromey <tom@tromey.com>
|
|
The switch to linking with libtool now shows a very long link line
even when V=0. This patch arranges to silence libtool in this
situation.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
