| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
People, including me, had forgotten that the bfd_error_handler just
handled standard printf format strings, not MSC %I64 and suchlike.
Using PRIx64 and similar in errors does not work if the host compiler
headers define those formats as the Microsoft %I64 variety. (We
handled %ll OK, editing it to %I64 on such hosts.)
PR 32507
* bfd.c (_bfd_doprnt, _bfd_doprnt_scan): Handle %I64 and %I32
in input strings if the host defines PRId64 as "I64d".
Edit %ll to %I64 on detecting PRId64 as "I64d" rather than on
a preprocessor define.
(cherry picked from commit b38cf91f230bc3892ab9c3deb4f1b6639c657c47)
|
|
|
|
|
|
|
|
|
|
This commit changes gdb/version.in to 16.0.90.DATE-git.
|
|
This commit changes gdb/version.in to 16.0.90.
|
|
|
|
This is done by setting the "development" variable to "false"
in bfd/development.sh.
|
|
Now that the GDB 16 branch has been created,
this commit bumps the version number in gdb/version.in to
16.0.90.DATE-git
For the record, the GDB 16 branch was created
from commit ee29a3c4ac7adc928ae6ed1fed3b59c940a519a4.
|
|
|
|
|
|
Reporting an internal loop index isn't helpful for the user to determine
which segment the problem is with. Report the PHDR index instead.
|
|
Using $srcdir/$subdir directly doesn't work, at least not with expect
5.45, dejagnu 1.6, and an out-of-tree build (I assume it's the latter
aspect which is crucial here). Make use of load_file instead.
|
|
For PDE, "recompiling with -fPIE" just makes no sense.
For PIE, "recompiling with -fPIE" makes sense for unresolvable absolute
relocs, but not unresolveable PC-relative relocs: if the reloc is
already PC-relative, the problem is not the reloc is PC-relative or
absolute, but the reloc is not applicable for external symbols.
If we hit an unresolvable reloc in PDE or an unresolvable PC-relative
reloc in PIE, it means the programmer has somehow wrongly instructed the
compiler to treat external symbols as local symbols. A misuse of
-mdirect-extern-access can cause the issue, so we can suggest
-mno-direct-extern-access. And in all cases (DSO/PIE/PDE) a mismatching
symbol visibility can also cause the issue, so we should also suggest to
check the visibility.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
|
|
weak symbols for static PIE
In a static PIE, undefined weak symbols should be just resolved to
runtime address 0, like those symbols with non-default visibility. This
was silently broken in all prior Binutils releases with "-static-pie
-mdirect-extern-access":
$ cat t.c
int x (void) __attribute__ ((weak));
int
main (void)
{
__builtin_printf("%p\n", x);
}
$ gcc t.c -static-pie -mdirect-extern-access
$ ./a.out
0x7ffff1d64000
Since commit 4cb77761d687 ("LoongArch: Check PC-relative relocations for
shared libraries), the situation has been improved: the linker errors
out instead of silently producing a wrong output file.
But logically, using -mdirect-extern-access for a static PIE perfectly
makes sense, and we should not prevent that even if the programmer uses
weak symbols. Linux kernel is such an example, and Linux < 6.10 now
fails to build with Binutils trunk. (The silent breakage with prior
Binutils releases was "benign" due to some blind luck.)
While since the 6.10 release Linux has removed those potentially
undefined weak symbols (due to performance issue), we still should
support weak symbols in -mdirect-extern-access -static-pie and unbreak
building old kernels.
Link: https://lore.kernel.org/loongarch/20241206085810.112341-1-chenhuacai@loongson.cn/
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
|
|
An undefined weak hidden/protect symbol should be resolved to runtime
address 0, but we were actually resolving it to link-time address 0. So
in PIE or DSO the runtime address would be incorrect.
Fix the issue by rewriting pcalau12i to lu12i.w, and pcaddi to addi.w.
The latter does not always work because the immediate field of addi.w is
narrower, report an error in the case the addend is too large.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
|
|
|
|
|
|
PR 32391 commit 9f2e3c21f6 fallout again. Also fix another 'macro'
may be used uninitialized.
|
|
This testcase:
.irp x x x "
.end #
.endr
manages to access lex[EOF].
xxx: Warning: end of file in string; '"' inserted
xxx:1: Warning: missing closing `"'
gas/app.c:844:16: runtime error: index -1 out of bounds for type 'char [256]
Following that there is a buffer overflow.
Stop this happening, and in other similar places, by checking for EOF.
|
|
|
|
There are two tests that fail in gdb.base/startup-with-shell.exp when
using the native-extended-remote board. I plan to fix these issues,
and I've posted a series that does just that:
https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com
But until that series is reviewed, I thought I'd merge this commit,
which marks the FAIL as XFAIL and links them to the relevant bug
number.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392
Tested-By: Guinevere Larsen <guinevere@redhat.com>
|
|
This commit implements the gdbarch_core_parse_exec_context method for
FreeBSD.
This is much simpler than for Linux. On FreeBSD, at least the
version (13.x) that I have installer, there are additional entries in
the auxv vector that point directly to the argument and environment
vectors, this makes it trivial to find this information.
If these extra auxv entries are not available on earlier FreeBSD, then
that's fine. The fallback behaviour will be for GDB to act as it
always has up to this point, you'll just not get the extra
functionality.
Other differences compared to Linux are that FreeBSD has
AT_FREEBSD_EXECPATH instead of AT_EXECFN, the AT_FREEBSD_EXECPATH is
the full path to the executable. On Linux AT_EXECFN is the command
the user typed, so this can be a relative path.
This difference is handy as on FreeBSD we don't parse the mapped files
from the core file (are they even available?). So having the EXECPATH
means we can use that as the absolute path to the executable.
However, if the user ran a symlink then AT_FREEBSD_EXECPATH will be
the absolute path to the symlink, not to the underlying file. This is
probably a good thing, but it does mean there is one case we test on
Linux that fails on FreeBSD.
On Linux if we create a symlink to an executable, then run the symlink
and generate a corefile. Now delete the symlink and load the core
file. On Linux GDB will still find (and open) the original
executable. This is because we use the mapped file information to
find the absolute path to the executable, and the mapped file
information only stores the real file names, not symlink names.
This is a total edge case, I only added the deleted symlink test
originally because I could see that this would work on Linux. Though
it is neat that Linux finds this, I don't feel too bad that this fails
on FreeBSD.
Other than this, everything seems to work on x86-64 FreeBSD (13.4)
which is all I have setup right now. I don't see why other
architectures wouldn't work too, but I haven't tested them.
|
|
GDB already has a limited mechanism for auto-loading the executable
corresponding to a core file, this can be found in the function
locate_exec_from_corefile_build_id in corelow.c.
However, this approach uses the build-id of the core file to look in
either the debug directory (for a symlink back to the executable) or
by asking debuginfod. This is great, and works fine if the core file
is a "system" binary, but often, when I'm debugging a core file, it's
part of my development cycle, so there's no build-id symlink in the
debug directory, and debuginfod doesn't know about the binary either,
so GDB can't auto load the executable....
... but the executable is right there!
This commit builds on the earlier commits in this series to make GDB
smarter.
On GNU/Linux, when we parse the execution context from the core
file (see linux-tdep.c), we already grab the command pointed to by
AT_EXECFN. If this is an absolute path then GDB can use this to
locate the executable, a build-id check ensures we've found the
correct file. With this small change GDB suddenly becomes a lot
better at auto-loading the executable for a core file.
But we can do better! Often the AT_EXECFN is not an absolute path.
If it is a relative path then we check for this path relative to the
core file. This helps if a user does something like:
$ ./build/bin/some_prog
Aborted (core dumped)
$ gdb -c corefile
In this case the core file in the current directory will have an
AT_EXECFN value of './build/bin/some_prog', so if we look for that
path relative to the location of the core file this might result in a
hit, again, a build-id check ensures we found the right file.
But we can do better still! What if the user moves the core file? Or
the user is using some tool to manage core files (e.g. the systemd
core file management tool), and the user downloads the core file to a
location from which the relative path no longer works?
Well in this case we can make use of the core file's mapped file
information (the NT_FILE note). The executable will be included in
the mapped file list, and the path within the mapped file list will be
an absolute path. We can search for mapped file information based on
an address within the mapped file, and the auxv vector happens to
include an AT_ENTRY value, which is the entry address in the main
executable. If we look up the mapped file containing this address
we'll have the absolute path to the main executable, a build-id check
ensures this really is the file we're looking for.
It might be tempting to jump straight to the third approach, however,
there is one small downside to the third approach: if the executable
is a symlink then the AT_EXECFN string will be the name of the
symlink, that is, the thing the user asked to run. The mapped file
entry will be the name of the actual file, i.e. the symlink target.
When we auto-load the executable based on the third approach, the file
loaded might have a different name to that which the user expects,
though the build-id check (almost) guarantees that we've loaded the
correct binary.
But there's one more thing we can check for!
If the user has placed the core file and the executable into a
directory together, for example, as might happen with a bug report,
then neither the absolute path check, nor the relative patch check
will find the executable. So GDB will also look for a file with the
right name in the same directory as the core file. Again, a build-id
check is performed to ensure we find the correct file.
Of course, it's still possible that GDB is unable to find the
executable using any of these approaches. In this case, nothing
changes, GDB will check in the debug info directory for a build-id
based link back to the executable, and if that fails, GDB will ask
debuginfod for the executable. If this all fails, then, as usual, the
user is able to load the correct executable with the 'file' command,
but hopefully, this should be needed far less from now on.
|
|
We have a few tests that load core files, which depend on GDB not
auto-loading the executable that matches the core file. One of these
tests (corefile-buildid.exp) exercises GDB's ability to load the
executable via the build-id links in the debug directory, while the
other two tests are just written assuming that GDB hasn't auto-loaded
the executable.
In the next commit, GDB is going to get better at finding the
executable for a core file, and as a consequence these tests could
start to fail if the testsuite is being run using a compiler that adds
build-ids by default, and is on a target (currently only Linux) with
the improved executable auto-loading.
To avoid these test failures, this commit updates some of the tests.
coredump-filter.exp and corefile.exp are updated to unload the
executable should it be auto-loaded. This means that the following
output from GDB will match the expected patterns. If the executable
wasn't auto-loaded then the new step to unload is harmless.
The corefile-buildid.exp test needed some more significant changes.
For this test it is important that the executable be moved aside so
that GDB can't locate it, but we do still need the executable around
somewhere, so that the debug directory can link to it. The point of
the test is that the executable _should_ be auto-loaded, but using the
debug directory, not using GDB's context parsing logic.
While looking at this test I noticed two additional problems, first we
were creating the core file more times than we needed. We only need
to create one core file for each test binary (total two), while we
previously created one core file for each style of debug info
directory (total four). The extra core files should be identical, and
were just overwriting each other, harmless, but still pointless work.
The other problem is that after running an earlier test we modified
the test binary in order to run a later test. This means it's not
possible to manually re-run the first test as the binary for that test
is destroyed.
As part of the rewrite in this commit I've addressed these issues.
This test does change many of the test names, but there should be no
real changes in what is being tested after this commit. However, when
the next commit is added, and GDB gets better at auto-loading the
executable for a core file, these tests should still be testing what
is expected.
|
|
Extend the core file context parsing mechanism added in the previous
commit to also store the environment parsed from the core file.
This environment can then be injected into the inferior object.
The benefit of this is that when examining a core file in GDB, the
'show environment' command will now show the environment extracted
from a core file.
Consider this example:
$ env -i GDB_TEST_VAR=FOO ./gen-core
Segmentation fault (core dumped)
$ gdb -c ./core.1669829
...
[New LWP 1669829]
Core was generated by `./gen-core'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000401111 in ?? ()
(gdb) show environment
GDB_TEST_VAR=foo
(gdb)
There's a new test for this functionality.
|
|
Add a new gdbarch method which can read the execution context from a
core file. An execution context, for this commit, means the filename
of the executable used to generate the core file and the arguments
passed to the executable.
In later commits this will be extended further to include the
environment in which the executable was run, but this commit is
already pretty big, so I've split that part out into a later commit.
Initially this new gdbarch method is only implemented for Linux
targets, but a later commit will add FreeBSD support too.
Currently when GDB opens a core file, GDB reports the command and
arguments used to generate the core file. For example:
(gdb) core-file ./core.521524
[New LWP 521524]
Core was generated by `./gen-core abc def'.
However, this information comes from the psinfo structure in the core
file, and this struct only allows 80 characters for the command and
arguments combined. If the command and arguments exceed this then
they are truncated.
Additionally, neither the executable nor the arguments are quoted in
the psinfo structure, so if, for example, the executable was named
'aaa bbb' (i.e. contains white space) and was run with the arguments
'ccc' and 'ddd', then when this core file was opened by GDB we'd see:
(gdb) core-file ./core.521524
[New LWP 521524]
Core was generated by `./aaa bbb ccc ddd'.
It is impossible to know if 'bbb' is part of the executable filename,
or another argument.
However, the kernel places the executable command onto the user stack,
this is pointed to by the AT_EXECFN entry in the auxv vector.
Additionally, the inferior arguments are all available on the user
stack. The new gdbarch method added in this commit extracts this
information from the user stack and allows GDB to access it.
The information on the stack is writable by the user, so a user
application can start up, edit the arguments, override the AT_EXECFN
string, and then dump core. In this case GDB will report incorrect
information, however, it is worth noting that the psinfo structure is
also filled (by the kernel) by just copying information from the user
stack, so, if the user edits the on stack arguments, the values
reported in psinfo will change, so the new approach is no worse than
what we currently have.
The benefit of this approach is that GDB gets to report the full
executable name and all the arguments without the 80 character limit,
and GDB is aware which parts are the executable name, and which parts
are arguments, so we can, for example, style the executable name.
Another benefit is that, now we know all the arguments, we can poke
these into the inferior object. This means that after loading a core
file a user can 'show args' to see the arguments used. A user could
even transition from core file debugging to live inferior debugging
using, e.g. 'run', and GDB would restart the inferior with the correct
arguments.
Now the downside: finding the AT_EXECFN string is easy, the auxv entry
points directly too it. However, finding the arguments is a little
trickier. There's currently no easy way to get a direct pointer to
the arguments. Instead, I've got a heuristic which I believe should
find the arguments in most cases. The algorithm is laid out in
linux-tdep.c, I'll not repeat it here, but it's basically a search of
the user stack, starting from AT_EXECFN.
If the new heuristic fails then GDB just falls back to the old
approach, asking bfd to read the psinfo structure for us, which gives
the old 80 character limited answer.
For testing, I've run this series on (all GNU/Linux) x86-64. s390,
ppc64le, and the new test passes in each case. I've done some very
basic testing on ARM which does things a little different than the
other architectures mentioned, see ARM specific notes in
linux_corefile_parse_exec_context_1 for details.
|
|
Given objdump -Mcpu=archs -D or similar, add_to_decodelist adds three
entries to decodelist for each instruction disassembled. That can
waste a lot of cpu when the list grows large. What's more,
decodelist is static and nothing clears the list. So the list
persists from one file to the next if objdump is disassembling
multiple files in one invocation. Wrong disassembly might result.
To fix this problem, I've moved decodelist to the arc private_data and
made it an array. I believe that init_disassemble_data will be
called, clearing private_data, for each file disassembled. That's
certainly true for objdump, and if I can see my way around gdb
constructors, it's also true for gdb. I don't think there is a
possibility of info.disassembler_options changing unless there is
first a call to init_disassebled_data. That means all of the option
parsing and bfd mach and e_flags decoding need only be done when
initialising the arc private_data.
* arc-dis.c (addrtypenames_max, addrtypeunknown): Delete..
(get_addrtype): ..substitute values here. Tidy.
(skipclass_t, linkclass, decodelist): Delete.
(enforced_isa_mask, print_hex): Delete.
(struct arc_disassemble_info): Add decode[], decode_count,
isa_mask, print_hex.
(init_arc_disasm_info): Tidy.
(add_to_decodelist): Delete, replacing with..
(add_to_decode): ..this. Don't duplicate entries.
(skip_this_opcode): Adjust to suit.
(find_format_from_table, parse_option): Likewise.
(parse_disassembler_options): Likewise. Move code dealing
with bfd mach and eflags from..
(print_insn_arc): ..here. Adjust for other changes.
|
|
This patch corrects layout for a PT_LOAD header that doesn't include
the ELF file header but does contain PHDRs and sections requiring
alignment. The required alignment (which was missing) is placed
before the PHDRs.
|
|
The new testcase results in these regressions:
hppa64-hp-hpux11.23 +FAIL: Nested macros (PR 32391)
hppa-hp-hpux10 +FAIL: Nested macros (PR 32391)
i386-darwin +FAIL: Nested macros (PR 32391)
Fix the hppa regressions by ensuring that only symbols start on the
first column.
|
|
PR 32391 commit 9f2e3c21f6 fallout
|
|
|
|
In this patch, we will support AVX10.2 minmax, vector copy and compare
instructions. This will finish the new instruction form support for
AVX10.2. Most of them are new instructions forms except for vmovd
and vmovw, which are extended usage from the old ones.
gas/ChangeLog:
* NEWS: Mention AVX10.2.
* testsuite/gas/i386/i386.exp: Add AVX10.2 tests.
* testsuite/gas/i386/x86-64.exp: Ditto.
* testsuite/gas/i386/avx10_2-256-5-intel.d: New test.
* testsuite/gas/i386/avx10_2-256-miscs.d: Ditto.
* testsuite/gas/i386/avx10_2-256-miscs.s: Ditto.
* testsuite/gas/i386/avx10_2-512-miscs-intel.d: Ditto.
* testsuite/gas/i386/avx10_2-512-miscs.d: Ditto.
* testsuite/gas/i386/avx10_2-512-miscs.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-miscs-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-miscs.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-512-miscs.s: Ditto.
opcodes/ChangeLog:
* i386-dis-evex-len.h: Add EVEX_LEN_0F7E_P_1_W_1,
EVEX_LEN_0FD6_P_2_W_0, EVEX_LEN_MAP5_6E and EVEX_LEN_MAP5_7E.
* i386-dis-evex-prefix.h: Add PREFIX_EVEX_0F2E, PREFIX_EVEX_0F2F,
PREFIX_EVEX_0F3A52, PREFIX_EVEX_0F3A53, PREFIX_EVEX_MAP5_2E,
PREFIX_EVEX_MAP5_2F, PREFIX_EVEX_MAP5_6E and PREFIX_EVEX_MAP5_7E.
* i386-dis-evex-w.h: Adjust EVEX_W_0F3A42, EVEX_W_0F7E_P_1
and EVEX_W_0FD6. Add EVEX_W_MAP5_6E_P_1 and EVEX_W_MAP5_7E_P_1.
* i386-dis-evex.h: Add and adjust table entries for AVX10.2.
* i386-dis.c (PREFIX_EVEX_0F2E): New.
(PREFIX_EVEX_0F2F): Ditto.
(PREFIX_EVEX_0F3A52): Ditto.
(PREFIX_EVEX_0F3A53): Ditto.
(PREFIX_EVEX_MAP5_2E): Ditto.
(PREFIX_EVEX_MAP5_2F): Ditto.
(PREFIX_EVEX_MAP5_6E_L_0): Ditto.
(PREFIX_EVEX_MAP5_7E_L_0): Ditto.
(EVEX_LEN_0F7E_P_1_W_1): Ditto.
(EVEX_LEN_0FD6_P_2_W_0): Ditto.
(EVEX_LEN_MAP5_6E): Ditto.
(EVEX_LEN_MAP5_7E): Ditto.
(EVEX_W_MAP5_6E_P_1): Ditto.
(EVEX_W_MAP5_7E_P_1): Ditto.
* i386-opc.tbl: Add AVX10.2 instructions.
* i386-mnem.h: Regenerated.
* i386-tbl.h: Ditto.
Co-authored-by: Jun Zhang <jun.zhang@intel.com>
Co-authored-by: Zewei Mo <zewei.mo@intel.com>
|
|
|
|
This fixes PR 31331:
https://sourceware.org/bugzilla/show_bug.cgi?id=31331
Currently, enum-flags.h is suppressing the warning
-Wenum-constexpr-conversion coming from recent versions of Clang.
This warning is intended to be made a compiler error
(non-downgradeable) in future versions of Clang:
https://github.com/llvm/llvm-project/issues/59036
The rationale is that casting a value of an integral type into an
enumeration is Undefined Behavior if the value does not fit in the
range of values of the enum:
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766
Undefined Behavior is not allowed in constant expressions, leading to
an ill-formed program.
In this case, in enum-flags.h, we are casting the value -1 to an enum
of a positive range only, which is UB as per the Standard and thus not
allowed in a constexpr context.
The purpose of doing this instead of using std::underlying_type is
because, for C-style enums, std::underlying_type typically returns
"unsigned int". However, when operating with it arithmetically, the
enum is promoted to *signed* int, which is what we want to avoid.
This patch solves this issue as follows:
* Use std::underlying_type and remove the custom enum_underlying_type.
* Ensure that operator~ is called always on an unsigned integer. We do
this by casting the input enum into std::size_t, which can fit any
unsigned integer. We have the guarantee that the cast is safe,
because we have checked that the underlying type is unsigned. If the
enum had negative values, the underlying type would be signed.
This solves the issue with C-style enums, but also solves a hidden
issue: enums with underlying type of std::uint8_t or std::uint16_t are
*also* promoted to signed int. Now they are all explicitly casted
to the largest unsigned int type and operator~ is safe to use.
* There is one more thing that needs fix. Currently, operator~ is
implemented as follows:
return (enum_type) ~underlying(e);
After applying ~underlying(e), the result is a very large value,
which we then cast to "enum_type". This cast is Undefined Behavior
if the large value does not fit in the range of the enum. For
C++ enums (scoped and/or with explicit underlying type), the range
of the enum is the entire range of the underlying type, so the cast
is safe. However, for C-style enums, the range is the smallest
bit-field that can hold all the values of the enumeration. So the
range is a lot smaller and casting a large value to the enum would
invoke Undefined Behavior.
To solve this problem, we create a new trait
EnumHasFixedUnderlyingType, to ensure operator~ may only be called
on C++-style enums. This behavior is roughly the same as what we
had on trunk, but relying on different properties of the enums.
* Once this is implemented, the following tests fail to compile:
CHECK_VALID (true, int, true ? EF () : EF2 ())
This is because it expects the enums to be promoted to signed int,
instead of unsigned int (which is the true underlying type).
I propose to remove these tests altogether, because:
- The comment nearby say they are not very important.
- Comparing 2 enums of different type like that is strange, relies
on integer promotions and thus hurts readability. As per comments
in the related PR, we likely don't want this type of code in gdb
code anyway, so there's no point in testing it.
- Most importantly, this type of comparison will be ill-formed in
C++26 for regular enums, so enum_flags does not need to emulate
that.
Since this is the only place where the warning was suppressed, remove
also the corresponding macro in include/diagnostics.h.
The change has been tested by running the entire gdb test suite
(make check) and comparing the results (testsuite/gdb.sum) against
trunk. No noticeable differences have been observed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31331
Tested-by: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Compilation will fail with -Werror=vla, which seems to be the default.
Note that we don't need to allocate num_threads + 1 since the matching
algorithm works only on the num_threads as returned by task_threads.
Change-Id: I276928d0ff3c52c7c7fe4edb857e5789cdabfcf7
|
|
|
|
|
|
This commit adds support for a `gstack' command which Fedora has
been carrying for many years. gstack is a natural counterpart to
the gcore command. Whereas gcore dumps a core file, gstack prints
stack traces of a running process.
There are many improvements over Fedora's version of this script.
The dependency on procfs is gone; gstack will run anywhere gdb
runs. The only runtime dependencies are bash and awk.
The script includes suggestions from gdb/32325 to include
versioning and help. [If this approach to gdb/32325 is acceptable,
I could propagate the solution to gcore/gdb-add-index.]
I've rewritten the documentation, integrating it into the User Manual.
The manpage is now output using this one source.
Example run (on x86_64 Fedora 40)
$ gstack --help
Usage: gstack [-h|--help] [-v|--version] PID
Print a stack trace of a running program
-h, --help Print this message then exit.
-v, --version Print version information then exit.
$ gstack -v
GNU gstack (GDB) 16.0.50.20241119-git
$ gstack 12345678
Process 12345678 not found.
$ gstack $(pidof emacs)
Thread 6 (Thread 0x7fd5ec1c06c0 (LWP 2491423) "pool-spawner"):
#0 0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6
#1 0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
#3 0x00007fd60b2f1a03 in g_thread_pool_spawn_thread () at /lib64/libglib-2.0.so.0
#4 0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5 0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6
#6 0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6
#7 0x0000000000000000 in ??? ()
Thread 5 (Thread 0x7fd5eb9bf6c0 (LWP 2491424) "gmain"):
#0 0x00007fd6015be87d in poll () at /lib64/libc.so.6
#1 0x0000000000000001 in ??? ()
#2 0xffffffff00000001 in ??? ()
#3 0x0000000000000001 in ??? ()
#4 0x000000002104cfd0 in ??? ()
#5 0x00007fd5eb9be320 in ??? ()
#6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0
Thread 4 (Thread 0x7fd5eb1be6c0 (LWP 2491425) "gdbus"):
#0 0x00007fd6015be87d in poll () at /lib64/libc.so.6
#1 0x0000000020f9b558 in ??? ()
#2 0xffffffff00000003 in ??? ()
#3 0x0000000000000003 in ??? ()
#4 0x00007fd5d8000b90 in ??? ()
#5 0x00007fd5eb1bd320 in ??? ()
#6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0
Thread 3 (Thread 0x7fd5ea9bd6c0 (LWP 2491426) "emacs"):
#0 0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6
#1 0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0
#2 0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0
#3 0x00007fd60b28a67c in g_async_queue_pop () at /lib64/libglib-2.0.so.0
#4 0x00007fd603f4d0d9 in fc_thread_func () at /lib64/libpangoft2-1.0.so.0
#5 0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#6 0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6
#7 0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6
#8 0x0000000000000000 in ??? ()
Thread 2 (Thread 0x7fd5e9e6d6c0 (LWP 2491427) "dconf worker"):
#0 0x00007fd6015be87d in poll () at /lib64/libc.so.6
#1 0x0000000000000001 in ??? ()
#2 0xffffffff00000001 in ??? ()
#3 0x0000000000000001 in ??? ()
#4 0x00007fd5cc000b90 in ??? ()
#5 0x00007fd5e9e6c320 in ??? ()
#6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0
Thread 1 (Thread 0x7fd5fcc45280 (LWP 2491417) "emacs"):
#0 0x00007fd6015c9197 in pselect () at /lib64/libc.so.6
#1 0x0000000000000000 in ??? ()
Since this is essentially a complete rewrite of the original
script and documentation, I've chosen to only keep a 2024 copyright date.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This patch is a few minor cleanups to rust-lang.c: renaming a
badly-named local variable, moving a couple of declarations into 'for'
headers, and using 'bool' in one spot.
|
|
PR/32363.
Gas was incorrectly translating
stm sp!, {regs}
into
push {regs}
but this is invalid. Conversely, it was also failing to translate
stmfd sp!, {lowregs[, lr]}
into a 16-bit push instruction. Fortunately stmia SP! is unlikely to be
a common idiom on a full-descending stack as it writes values to the stack,
then immediately deallocates that bit of the stack.
Fixed this and cleaned up the logic somewhat. While there, change some of
the ordering so that "ldm base, {base}" is transformed preferentially to
LDR. This is in keeping with the general preference in the Arm ARM for
avoiding single register LDM instructions.
|
|
Consider operate-and-get-next [1] in bash:
...
$ <echo 1>echo 1<enter>
1
$ <echo 2>echo 2<enter>
2
$ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o>
1
$ echo 2<Ctrl-o>
2
$ echo 1
...
So, typing Ctrl-o:
- executes the recalled command, and
- prefills the next one (which then can be executed again with Ctrl-o).
We have the same functionality in gdb, but when recalling the last command
from history with bash we have no prefill:
...
$ <echo 1>echo 1<enter>
1
$ <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1<Ctrl-o>
1
$
...
but with gdb do we have a prefill:
...
(gdb) echo 1\n
1
(gdb) <Ctrl-r>(reverse-i-search)`': <echo 1>echo 1\n<Ctrl-o>
1
(gdb) echo 1\n
...
Following the principle of least surprise [2], I think gdb should do what bash
does.
Fix this by:
- signalling this case in gdb_rl_operate_and_get_next using
"operate_saved_history = -1", and
- handling operate_saved_history == -1 in
gdb_rl_operate_and_get_next_completion.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR cli/32485
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32485
[1] https://www.man7.org/linux/man-pages/man3/readline.3.html
[2] https://en.wikipedia.org/wiki/Principle_of_least_astonishment
|
|
This changes one spot in ada-lang.c to use block::is_static_block
rather than a hand-rolled implementation. Note this also fixes the
call -- what is currently written there is wrong.
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
gdbpy_lookup_static_symbols is missing an error check for the case
where symbol_to_symbol_object returns NULL.
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
|
|
On openSUSE Leap 15.6 ppc64le-linux, with gdb.linespec/explicit.exp I run
into:
...
(gdb) b -source thread_pointer.h FAIL: $exp: complete after -source: tab complete "b -source thr"
Quit^M
...
The test-case already contains a related workaround:
...
# Get rid of symbols from shared libraries, otherwise
# "b -source thr<tab>" could find some system library's
# source.
gdb_test_no_output "nosharedlibrary"
...
but that doesn't work in this case because the debug info is in the executable
itself:
...
The File Name Table (offset 0xb5):
Entry Dir Time Size Name
1 0 0 0 abi-note.c
2 1 0 0 types.h
3 2 0 0 stdint-intn.h
4 2 0 0 stdint-uintn.h
5 3 0 0 elf.h
6 4 0 0 thread_pointer.h
...
due to debug info in some glibc object file.
Fix this by:
- using -nostdlib, ensuring only debug info from the three test-case sources
is present in the executable, and
- adding a _start wrapping main.
Tested on x86_64-linux and ppc64le-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
PR testsuite/31229
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31229
|
|
|
|
Also add the post DWARF5 language codes to gold/gdb-index.cc
Gdb_index_info_reader::visit_top_die check as --gdb-index only
supports C and C++ languages and emits warning otherwise.
|
