aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2025-03-23testsuite: libsframest: more renamesusers/ibhagat/sframe-stacktracer-testsuiteIndu Bhagat4-36/+36
and fixing some formatting issues. ChangeLog: * include/sframe-stacktrace-api.h * sframe-stacktrace.c * sframe-state.c * sframe-state.h
2025-03-23testsuite: libsframest: create new sframest_sfinfo_initIndu Bhagat2-65/+36
ChangeLog: * sframe-state.c * sframe-state.h
2025-03-23testsuite: libsframest: define a new function sframest_sfinfo_addr_range_pIndu Bhagat3-38/+23
Use this function consistently and remove unnecessary API sframest_update_sfinfo. ChangeLog: * sframe-stacktrace.c * sframe-state.c * sframe-state.h
2025-03-23more renames for readabilityIndu Bhagat3-48/+49
ChangeLog: * sframe-stacktrace.c * sframe-state.c * sframe-state.h
2025-03-23testsuite: libsframest: rename for readabilityIndu Bhagat3-116/+129
Some struct names and member names were long and unintuitive. Reduce the technical debt and make the code hopefully easier to maintain. libsframe/testsuite/ * libsframe.stacktrace/libsframest/sframe-stacktrace.c * libsframe.stacktrace/libsframest/sframe-state.c * libsframe.stacktrace/libsframest/sframe-state.h
2025-03-23testsuite: libsframest: use shorter version in conditionalsIndu Bhagat2-31/+33
libsframe/testsuite/ * libsframe.stacktrace/libsframest/sframe-stacktrace.c * libsframe.stacktrace/libsframest/sframe-state.c
2025-03-23libsframest: use access API instead of direct access using FRE infoIndu Bhagat1-2/+2
libsframe/testsuite/ * libsframe.stacktrace/libsframest/sframe-backtrace.c
2025-03-23lisbframest: remove unnecessary arch-specific codeIndu Bhagat1-20/+4
ChangeLog: * libsframe/testsuite/libsframe.stacktrace/libsframest /sframe-stacktrace.c (sframe_unwind): Remove unnecessary guards and arch-specific handling.
2025-03-23testsuite: minor housekeepingIndu Bhagat5-25/+24
Fix some code formatting nits. libsframe/testsuite/ * libsframe.stacktrace/libsframest/sframe-stacktrace-err.c: * libsframe.stacktrace/libsframest/sframe-stacktrace.c: * libsframe.stacktrace/libsframest/sframe-state.c: * libsframe.stacktrace/libsframest/sframe-state.h: * libsframe.stacktrace/stacktrace-inline-2.c:
2025-03-23testsuite: libsframest: use as, ld, collect-ld from build dirIndu Bhagat11-96/+70
instead of host's as and ld. Also disable libsframest build if cross compiling. The testsuite will consequently also be skipped. Override the check-am make target and first execute setup.sh to bring in the as-new / ld-new and use -B<path> to ensure these are picked up for building: - libsframest - libsframe.stacktrace testsuite Remove the configure time variable HAVE_SFRAME_AS as it is now unnecessary. TBD: - Get review on whether the whole setup.sh way of doing this is OK. But it seems there is no other way ? - Check the portability of the setup.sh script. ChangeLog: * libsframe/Makefile.am: Override check-am to first run setup.sh before invoking make. This ensures libsframest is built with the newly setup tmpdir/libsframe. * libsframe/Makefile.in: Regenerate. * libsframe/acinclude.m4: Delete. * libsframe/aclocal.m4: Remove include for acinclude.m4. * libsframe/configure: Regenerate. * libsframe/configure.ac: Remove HAVE_SFRAME_AS. Add a new AM_CONDITIONAL for CROSS_COMPILE. * libsframe/setup.sh: New file. * libsframe/testsuite/config/default.exp: Remove the creation and setup of tmpdir/lisframe. * libsframe/testsuite/lib/sframe-lib.exp: Use -B<path> to use the as/ld from build tree. * libsframe/testsuite/libsframe.stacktrace/libsframest/local.mk: Use -B<path> and use the as/ld from build tree. * libsframe/testsuite/libsframe.stacktrace/stacktrace.exp: Skip testing if cross build.
2025-03-23libsframest: use as a test tool insteadIndu Bhagat48-787/+1066
Add a configure time check for dl_iterate_phdr and run libsframe.stacktrace testsuite using libsframest. libsframest is the library for stack tracing using the SFrame stack trace format. libsframest is not installed anymore but used in the testsuite only. TBD: - More renamings are in order. - Cleanup the .exp files. - Disable (libsframest based) stack tracer tests in a cross build
2025-03-23testsuite: sframebt: Add backtrace-1 which uses -O2 alwaysIndu Bhagat2-0/+116
Keep a testcase with an explicit -O2 for testing purposes.
2025-03-23testsuite: sframebt: Use -fno-optimize-sibling-callsWeimin Pan2-2/+2
With -O2 and above, the compiler performs a sibling call optimization as main () and it's callee have compatible stack usage. As for generating stack traces though, there is nothing that any stack trace or unwind format can do here. Use -fno-optimize-sibling-calls to at least ensure the testcase checkes for the complete stack trace. ChangeLog: * libsframe/testsuite/libsframe.unwind/backtrace-fp-attr-1.lk: Use -fno-optimize-sibling-calls. * libsframe/testsuite/libsframe.unwind/backtrace-fp-attr-2.lk: Likewise.
2025-03-23sframebt: Factor register access code into a header fileWeimin Pan2-14/+84
ChangeLog: * libsframe/sframe-backtrace-regs.h: New file. * libsframe/sframe-backtrace.c: Use the new abstractions.
2025-03-23unwinder: Add SFrame unwinder testsWeimin Pan27-2/+1402
[Changes in V4] - Addressed Mike's review comments. - Be careful with the use of # and dnl in configure.ac - Add AC_CANONICAL_TARGET as we check for target. - Remove the LC_ALL=C bits. - Minor code fixups in the testcases - Removed unnecessary unistd.h. - use ATTRIBUTE_NOCLONE consistently. - Other minor cleanups. [End of changes in V4] [Changes in V3] - Added two new tests with attributes -f(no-)omit-frame-pointer. - Minor adjustments due to buildsystem changes in libsframe. [End of changes in V3] [Changes in V2] - minor changes in filenames in the testsuite. [End of changes in V2] Add tests for backtracing using SFrame section. ChangeLog: * libsframe/Makefile.in: Regenerated. * libsframe/configure: Regenerated. * libsframe/configure.ac: Check for cross compilation. * libsframe/testsuite/Makefile.in: Regenerated. * libsframe/testsuite/config/default.exp: Load sframe-lib.exp. * libsframe/testsuite/libsframe.decode/Makefile.in: Regenerated. * libsframe/testsuite/libsframe.encode/Makefile.in: Regenerated. * libsframe/testsuite/lib/sframe-lib.exp: New file. Add procedures for handling unwinder tests. * libsframe/testsuite/libsframe.unwind/backtrace.c: New test. * libsframe/testsuite/libsframe.unwind/backtrace.lk: New test. * libsframe/testsuite/libsframe.unwind/inline-cmds.c: New test. * libsframe/testsuite/libsframe.unwind/inline-cmds.lk: New test. * libsframe/testsuite/libsframe.unwind/inline.c: New test. * libsframe/testsuite/libsframe.unwind/inline.lk: New test. * libsframe/testsuite/libsframe.unwind/solib-lib1.c: New test. * libsframe/testsuite/libsframe.unwind/solib-lib2.c: New test. * libsframe/testsuite/libsframe.unwind/solib-main.c: New test. * libsframe/testsuite/libsframe.unwind/solib-main.d: New test. * libsframe/testsuite/libsframe.unwind/solib.exp: New file. * libsframe/testsuite/libsframe.unwind/solib-lib1.h: New test. * libsframe/testsuite/libsframe.unwind/solib-lib2.h: New test. * libsframe/testsuite/libsframe.unwind/tailcall.c: New test. * libsframe/testsuite/libsframe.unwind/tailcall.lk: New test. * libsframe/testsuite/libsframe.unwind/ttest.c: New test. * libsframe/testsuite/libsframe.unwind/ttest.lk: New test. * libsframe/testsuite/libsframe.unwind/unwind.exp: New file. * libsframe/testsuite/libsframe.unwind/backtrace-fp-attr-1.c: Likewise. * libsframe/testsuite/libsframe.unwind/backtrace-fp-attr-1.lk: Likewise. * libsframe/testsuite/libsframe.unwind/backtrace-fp-attr-2.c: Likewise. * libsframe/testsuite/libsframe.unwind/backtrace-fp-attr-2.lk: Likewise.
2025-03-23unwinder: generate backtrace using SFrame formatWeimin Pan9-17/+878
[Changes in V4] - Renamed ESFRAME_* enum error code names to SFRAME_ERR_*. - Addressed review comments by Mike. - Use AC_CACHE_CHECK macro in sframe.m4 - Delete config/sframe.m4. Add into libsframe/acinclude.m4. - Code fixups. [End of changes in V4] [Changes in V3] - Use the updated APIs from libsframe. - Use sframe_decoder_get_fixed_ra_offset on AMD64 instead of magic number -8. [End of changes in V3] [Changes in V2] - Minor formatting fixes. [End of changes in V2] A simple unwinder based on SFrame format. The unwinder is made available via libsframebt library. Buildsystem changes have been made to build libsframebt only when --gsframe support is available in the assembler. These buildsystem changes are necessary because the SFrame based unwinder the SFrame unwind info for itself to work. include/ChangeLog: * sframe-backtrace-api.h: New file. ChangeLog: * libsframe/acinclude.m4: New file. * libsframe/Makefile.am: Build backtrace functionality in its own library. Install libsframebt conditionally. * libsframe/Makefile.in: Regenerate. * libsframe/aclocal.m4: Regenerate. * libsframe/configure: Regenerate. * libsframe/configure.ac: Check if gas supports --gsframe command line option. * libsframe/sframe-backtrace-err.c: New file. * libsframe/sframe-backtrace.c: New file.
2025-03-23Automatic date update in version.inGDB Administrator1-1/+1
2025-03-22Automatic date update in version.inGDB Administrator1-1/+1
2025-03-21gdb/testsuite: Test the effect of amdgpu-precise memoryLancelot SIX2-1/+30
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>
2025-03-21gdb/testsuite/lib/rocm: Drop hip_devices_support_precise_memoryLancelot SIX1-19/+0
Remove hip_devices_support_precise_memory as this is not used anymore. Change-Id: If5e19cf81f8b8778ee11b27d99b8488562804967 Approved-by: Pedro Alves <pedro@palves.net>
2025-03-21gdb/testsuise: gdb.rocm/precise-memory.exp to not require ↵Lancelot SIX1-8/+11
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>
2025-03-21Introduce die_info::children and use itTom Tromey2-166/+72
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>
2025-03-21Rename die_info::sibling to die_info::nextTom Tromey3-44/+44
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>
2025-03-21Simplify warning_pre_printTom Tromey2-6/+6
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>
2025-03-21Do not use warning_pre_print in linux-thread-db.cTom Tromey1-3/+0
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>
2025-03-21gdb: check styled status of source cache entriesAndrew Burgess4-20/+121
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>
2025-03-21strip: don't corrupt PE binary's section/file alignmentJan Beulich1-2/+2
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.
2025-03-21aarch64: simplify RCPC3 unpredictable logicJan Beulich5-66/+32
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.
2025-03-21RISC-V: Ssnpm, smnpm and smmpm imply zicsr.Dongyan Chen1-0/+3
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.
2025-03-21Automatic date update in version.inGDB Administrator1-1/+1
2025-03-20[gdbsupport] Fix typo in common-inferior.hTom de Vries1-1/+1
Fix the following typo: ... $ codespell --config gdbsupport/setup.cfg gdbsupport/ gdbsupport/common-inferior.h:57: elemets ==> elements ...
2025-03-20x86-64: Remove the unused pr19636-3d.dH.J. Lu1-10/+0
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>
2025-03-20[gdb/testsuite] Fix typos in gdb.threads/infcall-from-bp-cond-simple.expTom de Vries1-2/+2
Fix two typos in gdb.threads/infcall-from-bp-cond-simple.exp.
2025-03-20Fix grammar error in dwarf2/attribute.hTom Tromey1-2/+2
A recent patch of mine had a comment with bad grammar; apparently I didn't finish editing it. This patch cleans it up.
2025-03-20[gdb/testsuite] Add missing returns in gdb.threads/infcall-from-bp-cond-simple.cTom de Vries1-0/+2
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.
2025-03-20[gdb/build] Fix build with gcc 9Tom de Vries1-1/+1
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.
2025-03-20Automatic date update in version.inGDB Administrator1-1/+1
2025-03-19gcore: quote PKGVERSIONSam James1-2/+2
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
2025-03-19gdb-add-index: quote PKGVERSIONSam James1-2/+2
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
2025-03-19gdb/python: convert gdb.Symtab_and_line to use gdbpy_registryJan Vrany1-36/+11
This commit converts gdb.Symtab_and_line to use gdbpy_registry for lifecycle management. Approved-By: Tom Tromey <tom@tromey.com>
2025-03-19gdb/python: convert gdb.Symtab to use gdbpy_registryJan Vrany1-59/+14
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>
2025-03-19gdb/python: convert gdb.Type to use gdbpy_registryJan Vrany1-92/+21
This commit converts gdb.Type to use gdbpy_registry for lifecycle management. Approved-By: Tom Tromey <tom@tromey.com>
2025-03-19gdb/python: convert gdb.Symbol to use gdbpy_registryJan Vrany1-67/+12
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>
2025-03-19gdb/python: introduce gdbpy_registryJan Vrany1-0/+195
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>
2025-03-19gdb/python: do not hold on gdb.Type object from gdb.ValueJan Vrany1-33/+7
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>
2025-03-19gdb/python: preserve identity for gdb.Type objectsJan Vrany3-15/+96
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>
2025-03-19gdb/python: do not hold on gdb.Symtab object from gdb.Symtab_and_lineJan Vrany2-53/+22
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>
2025-03-19gdb/python: preserve identity for gdb.Symbol objectsJan Vrany1-12/+50
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>
2025-03-19gdb/python: preserve identity for gdb.Symtab objectsJan Vrany2-1/+45
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>
2025-03-19gdb: change set_internalvar_function to take a unique pointerSimon Marchi1-7/+7
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>