| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Looking at `cooked_index_shard::find`, I thought that we could make a
small optimization: when finding the upper bound, we already know the
lower bound. And we know that the upper bound is >= the lower bound.
So we could pass `lower` as the first argument of the `std::upper_bound`
call to cut the part of the search space that is below `lower`.
It then occured to me that what we do is basically what
`std::equal_range` is for, so why not use it. Implementations of
`std::equal_range` are likely do to things as efficiently as possible.
Unfortunately, because `cooked_index_entry::compare` is sensitive to the
order of its parameters, we need to provide two different comparison
functions (just like we do know, to the lower_bound and upper_bound
calls). But I think that the use of equal_range makes it clear what the
intent of the code is.
Regression tested using the various DWARF target boards on Debian 12.
Change-Id: Idfad812fb9abae1b942d81ad9976aeed7c2cf762
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I believe that the `(mode == MATCH && a == munge ('<'))` part of the
condition is unnecesary. Or perhaps I don't understand the algorithm.
The use of "munge" above effectively makes it so that the template
portion of names is completely ignored for the sake of the comparison.
Then, in the condition, this:
a == munge ('<')
is functionally equivalent to
a == '\0'
If `a` is indeed '\0', and `b` is also '\0', then we would have taken
the earlier branch:
if (a == b)
return 0;
If `b` is not '\0', then we won't take this branch and we'll go into the
final comparison:
return a < b ? -1 : 1;
So, as far as I can see, there is no case where `mode == MATCH`, where
we're going to use this special `return 0`.
Regression tested using the various DWARF target boards on Debian 12.
Change-Id: I5ea0463c1fdbbc1b003de2f0a423fd0073cc9dec
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
|
|
We have this pattern of check in multiple places:
/* Skip dummy compilation units. */
if (m_info_ptr >= begin_info_ptr + this_cu->length ()
|| peek_abbrev_code (abfd, m_info_ptr) == 0)
m_dummy_p = true;
In all places except one (read_cutu_die_from_dwo), this is done after
reading the unit header but before potentially reading the first DIE.
The effect is that we consider dummy units that have no DIE at all.
Either the "data" portion of the unit (the portion after the header) has
a size of zero, or the first abbrev code is 0, i.e. "end of list".
According to this old commit I found [1], dummy CUs were used as filler
for incremental LTO linking. A comment reads:
WARNING: If THIS_CU is a "dummy CU" (used as filler by the incremental
linker) then DIE_READER_FUNC will not get called.
In read_cutu_die_from_dwo, however, this check is done after having read
the first DIE. So at the time of the check, m_info_ptr has already been
advanced just past the first DIE. As a result, compilations units with
a single DIE are considered (erroneously, IMO) as dummy.
In commit aab6de1613df ("gdb/dwarf: fix spurious error when encountering
dummy CU") [2], I mentioned a real world case where compilation units
with a single top-level DIE were being considered dummy. I believe that
those units should not actually have been treated as dummy. A CU with
just one DIE may not be very interesting, but I don't see any reason to
consider it dummy.
Move the dummy check above the read_toplevel_die call, and return early
if the CU is dummy.
I am 99% convinced that it's not even possible to encounter an empty
unit here, and considered turning it into an assert (it did pass the
testsuite). This function is passed a dwo_unit, and functions that
create a dwo_unit are:
- create_debug_type_hash_table (creates a dwo_unit for each type unit
found in a dwo file)
- create_cus_hash_table (creates a dwo_unit for each comp unit found in
a dwo file)
- create_dwo_unit_in_dwp_v1
- create_dwo_unit_in_dwp_v2
- create_dwo_unit_in_dwp_v5
In the first two, there are already dummy checks, so we wouldn't even
get to read_cutu_die_from_dwo for such an empty CU. However, in the
last three, there is no such checks, we just trust the dwp file's index
and create dwo_units out of that. So I guess it would be possible to
craft a broken dwp file with a CU that has no DIE. Out of caution, I
didn't switch that to an assert, but I also don't really know what would
be the mode of failure if that were to happen.
Regtested using the various DWARF target boards on Debian 12.
[1] https://gitlab.com/gnutools/binutils-gdb/-/commit/dee91e82ae87f379c90fddff8db7c4b54a116609#dd409f60ba6f9c066432dafbda7093ac5eec76d1_3434_3419
[2] https://gitlab.com/gnutools/binutils-gdb/-/commit/aab6de1613df693059a6a2b505cc8f20d479d109
Change-Id: I90e6fa205cb2d23ebebeae6ae7806461596f9ace
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This parameter is always used to set cutu_reader::m_dwo_abbrev_table.
Remove the parameter, and have read_cutu_die_from_dwo set the field
directly.
Change-Id: I6c0c7d23591fb2c3d28cdea1befa4e6b379fd0d3
Approved-By: Tom Tromey <tom@tromey.com>
|
|
FEAT_MEC support was introduced in [1]. However, the dc instruction was
missing these encodings:
- DC CIPAE
- DC CIGDPAE
Furthermore, the Arm ARM states that FEAT_MEC is an optional extension,
introduced for v9.2-a.
Therefore, these sysregs:
- MECIDR_EL2
- MECID_P0_EL2
- MECID_A0_EL2
- MECID_P1_EL2
- MECID_A1_EL2
- VMECID_P_EL2
- VMECID_A_EL2
- MECID_RL_A_EL3
which were introduced in that commit now require -march=armv9.2-a at the very
least to be enabled, as well as the dc encodings.
opcodes/ChangeLog:
* aarch64-opc.c (aarch64_sys_regs_dc): Add "cipae" and "cigdpae".
* aarch64-sys-regs.def: Add V8_7A as a requirement for the above system
registers.
gas/testsuite/gas/ChangeLog
* aarch64/mec-invalid.s: Add .arch directive.
* aarch64/mec.d: Add .arch directive and check for cipae, cigdpae.
* aarch64/mec.s: Add MEC data cache operations test.
* aarch64/mec-arch-bad.d: New test to check for bad arch version.
* aarch64/mec-arch-bad.l: Above.
[1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=31f2faf5cf112931cfb8c0564a2b78477c907fe3
Regression tested on aarch64-none-elf
|
|
bfd_canonicalize_symtab stores the symbols in the BFD, and returns
pointers to these. The ELF reader does not reuse these stored
symbols, so each call to bfd_canonicalize_symtab causes an allocation.
This interacts poorly with code like arm_pikeos_osabi_sniffer, which
searches the BFD symbol when called.
PR gdb/32758 points out a particularly pathological case: using "maint
info sections" on a program with a large number of sections (10000)
will cause 10000 calls to arm_pikeos_osabi_sniffer, allocating 20G.
I'm not sure BFD always worked this way. And, fixing BFD was an
option. However it seemed maybe better for GDB to adapt, since
adapting would mean that the fix would apply to all BFD back ends, and
not just ELF.
To that end, this patch adds a new gdb_bfd_canonicalize_symtab and
changes all callers of bfd_canonicalize_symtab to use it instead.
This new function caches the result in the per-BFD object.
I looked into having this return a view of "const asymbol *". However
both the compile module and machoread modify the returned symbols.
And while I think this is wrong, I haven't tried to fix this here.
Regression tested on x86-64 Fedora 40.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32758
|
|
Commit 3aaca06b672 ("gdb: fix color_option_def compile error (clang)")
fixed a compilation error in color_option_def when building with
clang. It seemed to me that it would be good to add a compile test
for this code.
|
|
|
|
|
|
|
|
The gdb.rocm/precise-memory.exp test currently checks that the "amdgpu
precise-memory" setting can be set. It does not test that this setting
has any meaningful effect.
This patch extends this test to ensure that precise-memory has the
expected behaviour.
Change-Id: I58f72a51a566f04fc89114b94ee656c2e7ac35bb
Approved-by: Pedro Alves <pedro@palves.net>
|
|
Remove hip_devices_support_precise_memory as this is not used anymore.
Change-Id: If5e19cf81f8b8778ee11b27d99b8488562804967
Approved-by: Pedro Alves <pedro@palves.net>
|
|
hip_devices_support_precise_memory
The gdb.rocm/precise-memory.exp test adjusts its behaviour based on the
value returned by hip_devices_support_precise_memory. This function has
static assumption regarding HW capabilities, which might not be
accurate.
Adjust the test so it does not assume anything about HW capabilities,
but instead just ensure that GDB behaves consistently.
Change-Id: Ie1f9c6219b88b94f6d461a254b2ad616b92db6b9
Approved-by: Pedro Alves <pedro@palves.net>
|
|
This adds a new die_info::children method. This returns a range that
can be used to iterate over a DIE's children.
Then this goes through and updates all the relevant loops to use
foreach instead. This is a net code reduction.
You'll note that in some places the code was checking the tag as well,
like:
while (child_die && child_die->tag)
I believe this can't happen and is just a copy-paste oddity from the
old days.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I want to add support for C++ foreach iteration over DIE siblings.
I considered writing a custom iterator for this, but it would be
largely identical to the already-existing next_iterator. I didn't
want to duplicate the code...
Then I tried parameterizing next_iterator by having it take an
optional pointer-to-member template argument. However, this would
involve changes in many places, because currently a next_iterator can
be instantiated before the underlying type is complete.
So in the end I decided to rename die_info::sibling to die_info::next.
This name is slightly worse but (1) IMO it isn't really all that bad,
nobody would have blinked if it was called 'next' in the initial
patch, and (2) with the change to iteration it is barely used.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
This changes warning_pre_print to not include the text "warning",
which is now unconditional. I think this is a bit clearer, and anyway
it is convenient to support the next patch.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
linux-thread-db.c may print "warning_pre_print" before displaying an
error message. This seems like a mistake to me, and furthermore I
think it's best to be as sparing as possible with uses of
warning_pre_print, so this patch removes the prefix.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
Currently GDB's source cache doesn't track whether the entries within
the cache are styled or not. This is pretty much fine, the assumption
is that any time we are fetching source code, we do so in order to
print it to the terminal, so where possible we always want styling
applied, and if styling is not applied, then it is because that file
cannot be styled for some reason.
Changes to 'set style enabled' cause the source cache to be flushed,
so future calls to fetch source code will regenerate the cache entries
with styling enabled or not as appropriate.
But this all assumes that styling is either on or off, and that
switching between these two states isn't done very often.
However, the Python API allows for individual commands to be executed
with styling turned off via gdb.execute(). See commit:
commit e5348a7ab3f11f4c096ee4ebcdb9eb2663337357
Date: Thu Feb 13 15:39:31 2025 +0000
gdb/python: new styling argument to gdb.execute
Currently the source cache doesn't handle this case. Consider this:
(gdb) list main
... snip, styled source code displayed here ...
(gdb) python gdb.execute("list main", True, False, False)
... snip, styled source code is still shown here ...
In the second case, the final `False` passed to gdb.execute() is
asking for unstyled output.
The problem is that, `get_source_lines` calls `ensure` to prime the
cache for the file in question, then `extract_lines` just pulls the
lines of interest from the cached contents.
In `ensure`, if there is a cache entry for the desired filename, then
that is considered good enough. There is no consideration about
whether the cache entry is styled or not.
This commit aims to fix this, after this commit, the `ensure` function
will make sure that the cache entry used by `get_source_lines` is
styled correctly.
I think there are two approaches I could take:
1. Allow multiple cache entries for a single file, a styled, and
non-styled entry. The `ensure` function would then place the
correct cache entry into the last position so that
`get_source_lines` would use the correct entry, or
2. Have `ensure` recalculate entries if the required styling mode is
different to the styling mode of the current entry.
Approach #1 is better if we are rapidly switching between styling
modes, while #2 might be better if we want to keep more files in the
cache and we only rarely switch styling modes.
In the end I chose approach #2, but the good thing is that the changes
are all contained within the `ensure` function. If in the future we
wanted to change to strategy #1, this could be done transparently to
the rest of GDB.
So after this commit, the `ensure` function checks if styling is
currently possible or not. If it is not, and the current entry is
styled, then the current entry only is dropped from the cache, and a
new, unstyled entry is created. Likewise, if the current entry is
non-styled, but styling is required, we drop one entry and
recalculate.
With this change in place, I have updated set_style_enabled (in
cli/cli-style.c) so the source cache is no longer flushed when the
style settings are changed, the source cache will automatically handle
changes to the style settings now.
This problem was discovered in PR gdb/32676.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Section and file alignment are supposed to remain unaltered when PE
binaries are stripped. While this is the case when they're strip-ed
individually, passing multiple such files to strip would reset the
two values to their defaults in all but the first of those binaries.
|
|
The original observation was that STILP is warned about when everything
is fine. Documentation, not just for STILP, says explicitly that
behavior is identical to respective pre-existing insns (for STILP in
particular that's STP). With that it's unclear why distinct logic was
added: Other code can be re-used, simply distinguishing by the number of
operands. This was diagnostics also end up more consistent.
Along with adding some STILP uses to the (positive) testcase, also add a
pair of STLR to similarly demonstrate that the register overlap goes
without warning when there's no write-back.
|
|
According to the spec[1], imply zicsr for ssnpm, smnpm and smmpm.
[1] https://github.com/riscv/riscv-j-extension/blob/master/zjpm/instructions.adoc
bfd/ChangeLog:
* elfxx-riscv.c: imply zicsr.
|
|
|
|
Fix the following typo:
...
$ codespell --config gdbsupport/setup.cfg gdbsupport/
gdbsupport/common-inferior.h:57: elemets ==> elements
...
|
|
Remove the unused pr19636-3d.d since static Position Dependent Executable
doesn't have a dynamic symbol table.
PR ld/32807
* testsuite/ld-x86-64/pr19636-3d.d: Removed.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Fix two typos in gdb.threads/infcall-from-bp-cond-simple.exp.
|
|
A recent patch of mine had a comment with bad grammar; apparently I
didn't finish editing it. This patch cleans it up.
|
|
While investigating PR32785 I noticed a missing return statement in
worker_func, and compiling with -Wreturn-type showed another in
function_that_segfaults:
...
$ gcc gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c -Wreturn-type
infcall-from-bp-cond-simple.c: In function ‘function_that_segfaults’:
infcall-from-bp-cond-simple.c:46:1: warning: \
control reaches end of non-void function [-Wreturn-type]
46 | }
| ^
infcall-from-bp-cond-simple.c: In function ‘worker_func’:
infcall-from-bp-cond-simple.c:58:1: warning: \
control reaches end of non-void function [-Wreturn-type]
58 | }
| ^
...
Fix these by adding the missing returns.
|
|
Since commit a691853148f ("gdb/python: introduce gdbpy_registry"), when
building gdb with gcc 9, I run into:
...
In file included from gdb/varobj.c:38:0:
gdb/python/python-internal.h:1211:47: error: expected ‘;’ before ‘<’ token
using StorageKey = typename registry<O>::key<Storage>;
^
...
due to this code:
...
template <typename Storage>
class gdbpy_registry
{
...
template<typename O>
using StorageKey = typename registry<O>::key<Storage>;
template<typename O>
Storage *get_storage (O *owner, const StorageKey<O> &key) const
{ ... }
...
}
...
As an experiment, I tried out eliminating the type alias:
...
template<typename O>
Storage *get_storage (O *owner,
const typename registry<O>::key<Storage> &key) const
{ ... }
...
and got instead:
...
In file included from gdb/varobj.c:38:0:
gdb/python/python-internal.h:1211:63: error: non-template ‘key’ used as template
Storage *get_storage (O *owner,
const typename registry<O>::key<Storage> &key) const
^~~
gdb/python/python-internal.h:1211:63: note: use ‘registry<O>::template key’ \
to indicate that it is a template
...
Following that suggestion, I tried:
...
template<typename O>
Storage *
get_storage (O *owner,
const typename registry<O>::template key<Storage> &key) const
{ ... }
...
which fixed the problem.
Likewise, adding the template keyword in the type alias fixes the original
problem, so fix it like that.
Tested on x86_64-linux.
|
|
|
|
Same as 3bed686102cb14552d2ed1b83336453d7ce0dd47. I didn't hit an issue
here -- I think because my /bin/sh is dash and gdb-add-index has a /bin/sh
shebang, while gcore uses bash, but it's still worth fixing (we certainly
do NOT want this to be an array).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
|
|
In Gentoo, we configure our gdb with `--with-pkgversion=` with
"Gentoo VERSION XXXX" where XXX depends on patching (not that we patch
gdb really these days) or vanilla.
Since 71f193a5c1cb02dcde6ac160cdab88e9725862bb, this goes wrong, yielding
```
/usr/bin/gdb-add-index: 25: Syntax error: "(" unexpected
```
with lines 25-26 being:
```
PKGVERSION=(Gentoo 9999 vanilla)
VERSION=17.0.50.20250319-git
```
Quote both assignments (PKGVERSION by necessity, VERSION for consistency
or symmetry).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32325
|
|
This commit converts gdb.Symtab_and_line to use gdbpy_registry for
lifecycle management.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit converts gdb.Symtab to use gdbpy_registry for lifecycle
management. Since gdb.Symtab only holds on the struct symtab * (and
prev/next links) the default invalidator can be used.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit converts gdb.Type to use gdbpy_registry for lifecycle
management.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit converts gdb.Symbol to use gdbpy_registry for lifecycle
management. Since gdb.Symbol only holds on the struct symbol * (and
prev/next links) the default invalidator can be used.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit introduces new template class gdbpy_registry to simplify
Python object lifecycle management. As of now, each of the Python
object implementations contain its own (copy of) lifecycle management
code that is largely very similar. The aim of gdbpy_registry is to
factor out this code into a common (template) class in order to simplify
the code.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Previous commit changed type_to_type_object() so each time it is
called with particular struct value* it returns the same object.
Therefore there's no longer need to hold on type objects (gdb.Type)
from struct value_object in order to preserve identity of gdb.Type
objects held in value_object::type and value_object::dynamic_type
members. This in turn allowed for some simplification in various
functions.
While at it I changed a couple of NULLs to nullptrs.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit changes type_to_type_object() so that each it is called
with a particular struct type * it returns the very same gdb.Type
object.
This is done in the same way as for gdb.Symtab objects in earlier commit
("gdb/python: preserve identity for gdb.Symtab objects") except that
types may be either objfile-owned or arch-owned.
Prior this commit, arch-owned objects we not put into any list (like
objfile-owned ones) so they could not be easily looked up. This commit
changes the code so arch-owned list are put into per-architecture list
which is then used (solely) for looking up arch-owned gdb.Type.
Another complication comes from the fact that when objfile is about to
be freed, associated gdb.Type instances are not merely invalidated
(like it is done with gdb.Symtab or gdb.Symbol objects) but instead the
type is copied and the copy is arch-owned. So we need two different
"deleters", one for objfile-owned types that copies the type (as before)
and then insert the object to per-architecture list and another one
for arch-owned types.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Previous commit changed symtab_to_symtab_object() so each time it is
called with particula struct symtab* it returns the same object.
Therefore there's no longer need to hold on symtab object (gdb.Symtab)
from struct sal_object in order to preserve identity of Symtab object
held in gdb.Symtab_and_line.symtab property. This in turn allowed for
some simplification in various functions.
While at it I changed a couple of NULLs to nullptrs.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit changes symbol_to_symbol_object() so that each it is called
with a particular struct symbol * it returns the very same gdb.Symbol
object.
This is done in the same way as for gdb.Symtab objects in earlier commit
("gdb/python: preserve identity for gdb.Symtab objects") except that
symbols may be either objfile-owned or arch-owned.
Prior this commit, arch-owned objects we not put into any list (like
objfile-owned ones) so they could not be easily looked up. This commit
changes the code so arch-owned list are put into per-architecture list
which is then used (solely) for looking up arch-owned gdb.Symbol.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This commit changes symtab_to_symtab_object() so that each it is called
with a particular struct symtab * it returns the very same gdb.Symtab
object.
This is done by searching per-objfile linked list of instances and - if
found - return it rather than creating new gdb.Symtab.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This makes the transfer of ownership a bit clearer, even though the
internal_function is still held with a raw pointer inside internalval.
Change-Id: Ie8d13270b64737b92291532acfbfcbc992b482b5
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
While checking the list of leaks reported by ASan, I found that
clear_internalvar doesn't free the internal_function object owned by the
internalvar when the internalvar is of kind INTERNALVAR_FUNCTION, fix
that.
Change-Id: I78f53b83b97bae39370a7b5ba5e1cec70626d66a
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
The data associated to an internalvar is destroyed when changing the
kind of the internalvar, but not when it is destroyed. Fix that by
calling clear_internalvar in ~internalvar.
A move constructor becomes needed to avoid freeing things multiple times
when internalvars are moved (and if we forget it, clang helpfully gives
us a -Wdeprecated-copy-with-user-provided-dtor warning).
Change-Id: I427718569208fd955ea25e94d341dde356725033
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Change the `name` field to std::string, add constructor. Remove
function `create_internal_function`, since it becomes a trivial wrapper
around the constructor.
Change-Id: Ifc8b1282c442e1930bcd69d6e140128067e49563
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Currently, gdb.execute emits styled output when the command is sending
its output to GDB's stdout, and produces unstyled output when the
output is going to a string.
But it is not unreasonable that a user might wish to capture styled
output from a gdb.execute call, for example, the user might want to
display the styled output are part of some larger UI output block.
At the same time, I don't think it makes sense to always produce
styled output when capturing the output in a string; if what the user
wants is to parse the output, then the style escape sequences make
this far harder.
I propose that gdb.execute gain a new argument 'styling'. When False
we would always produce unstyled output, and when True we would
produce styled output if styling is not disabled by some other means.
For example, if GDB's 'set style enabled' is off, then I think
gdb.execute() should respect that. My assumption here is that
gdb.execute() might be executed by some extension. If the extension
thinks "styled output world work here", but the user hates styled
output, and has turned it off, then the extension should not be
forcing styled output on the user.
I chose 'styling' instead of 'styled' as the Python argument name
because we already use 'styling' in gdb.Value.format_string, and we
don't use 'styled' anywhere else. This is only a little bit of
consistency, but I still think it's a good thing.
The default for 'styling' will change depending on where the output is
going. When gdb.execute is sending the output to GDB's stdout then
the default for 'styling' is True. When the output is going to a
string, then the default for 'styling' will be False. Not only does
this match the existing behaviour, but I think this makes sense. By
default we assume that output captured in a string is going to be
parsed, and therefore styling markup is unhelpful, while output going
to stdout should receive styling.
This fixes part of the problem described in PR gdb/32676. That bug
tries to capture styled source listing in a string, which wasn't
previously possible.
There are some additional issues with capturing source code; GDB
caches the source code in the source code cache. However, GDB doesn't
check if the cached content is styled or not. As a consequence, if
the first time the source of a file is shown it is unstyled, then the
cached will hold the unstyled source code, and future requests will
return that unstyled source. I'll address this issue in a separate
patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32676
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On GNU/Linux (and other targets that use solib-svr4.c) the 'info
sharedlibrary' command displays the address range for the .text
section of each library. This is a fallback behaviour implemented in
solib_map_sections (in solib.c), for targets which are not able to
provide any better information.
The manual doesn't really explain what the address range given means,
and the .text fallback certainly isn't described. The manual for
'info sharedlibrary' just says:
'info share REGEX'
'info sharedlibrary REGEX'
Print the names of the shared libraries which are currently loaded
that match REGEX. If REGEX is omitted then print all shared
libraries that are loaded.
In this commit I propose that we should change GDB so that the full
library address range is listed for GNU/Linux (and other solib-svr4
targets). Though it is certainly useful to know where the .text for a
library is, not all code is placed into the .text section, and data,
or course, is stored elsewhere, so the choice of .text, though not a
crazy default, is still a pretty arbitrary choice.
We do also have 'maintenance info sections', which can be used to find
the location of a specific section. This is of course, a maintenance
command, but we could make this into a real user command if we wanted,
so the information lost by this change to 'info sharedlibrary' is
still available if needed.
There is one small problem. After this commit, GDB is still under
reporting the extents of some libraries, in some cases.
What I observe is that sometimes, for reasons that I don't currently
understand, the run-time linker will over allocate memory for the .bss
like sections, e.g. the ELF says that 1 page is required, but 2 or 4
pages will be allocated instead. As a result, GDB will under report
the extent of the library, with the end address being lower than
expected. This isn't always the case though, in many cases the
allocates are as I would expect, and GDB reports the correct values.
However, as we have been under reporting for many years, I think this
update, which gets things a lot closer to reality, is a big step in
the right direction. We can always improve the results more later
on if/when the logic behind the over allocations become clearer.
For testing I've compared the output of 'info proc mappings' with the
output of 'info sharedlibrary' (using a script), using GDB to debug
itself, on Fedora Linux running on AArch64, PPC64, S390, and X86-64,
and other than the over allocation problem described above, the
results all look good to me.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
The function remove_thread() was changed to a method in 2500e7d7d (gdbserver:
make remove_thread a method of process_info).
Signed-off-by: Wataru Ashihara <wsh@iij.ad.jp>
Change-Id: I4b2d8a6f84b5329b8d450b268fa9453fe424914e
|
