aboutsummaryrefslogtreecommitdiff
path: root/gdb/symtab.c
AgeCommit message (Collapse)AuthorFilesLines
2024-01-02gdb/dwarf2: Add support for DW_LNS_set_epilogue_begin in line-tableGuinevere Larsen1-0/+41
This commit adds a mechanism for GDB to detect the linetable opcode DW_LNS_set_epilogue_begin. This opcode is set by compilers to indicate that a certain instruction marks the point where the frame is destroyed. While the standard allows for multiple points marked with epilogue_begin in the same function, for performance reasons, the function that searches for the epilogue address will only find the last address that sets this flag for a given block. This commit also changes amd64_stack_frame_destroyed_p_1 to attempt to use the epilogue begin directly, and only if an epilogue can't be found will it attempt heuristics based on the current instruction. Finally, this commit also changes the dwarf assembler to be able to emit epilogue-begin instructions, to make it easier to test this patch Approved-By: Tom Tromey <tom@tromey.com>
2023-12-08gdb: Guarantee that an SAL's end is right before the next statementGuinevere Larsen1-2/+8
When examining a failure that happens when testing gdb.python/py-symtab.c with clang, I noticed that it was going wrong because the test assumed that whenever we get an SAL, its end would always be right before statement in the line table. This is true for GCC compiled binaries, since gcc only adds statements to the line table, but not true for clang compiled binaries. This is the second time I run into a problem where GDB doesn't handle non-statement line table entries correctly. The other was eventually committed as 9ab50efc463ff723b8e9102f1f68a6983d320517: "gdb: fix until behavior with trailing !is_stmt lines", but that commit only changes the behavior for the 'until' command. In this patch I propose a more general solution, making it so every time we generate the SAL for a given pc, we set the end of the SAL to before the next statement or the first instruciton in the next line, instead of naively assuming that to be the case. With this new change, the edge case is removed from the processing of the 'until' command without regressing the accompanying test case, and no other regressions were observed in the testsuite. Approved-By: Tom Tromey <tom@tromey.com>
2023-11-29Remove gdb_static_assertTom Tromey1-1/+1
C++17 makes the second parameter to static_assert optional, so we can remove gdb_static_assert now.
2023-11-21gdb: Use std::string_view instead of gdb::string_viewLancelot Six1-7/+7
Given that GDB now requires a C++17, replace all uses of gdb::string_view with std::string_view. This change has mostly been done automatically: - gdb::string_view -> std::string_view - #include "gdbsupport/gdb_string_view.h" -> #include <string_view> One things which got brought up during review is that gdb::stging_view does support being built from "nullptr" while std::sting_view does not. Two places are manually adjusted to account for this difference: gdb/tui/tui-io.c:tui_getc_1 and gdbsupport/format.h:format_piece::format_piece. The above automatic change transformed "gdb::to_string (const gdb::string_view &)" into "gdb::to_string (const std::string_view &)". The various direct users of this function are now explicitly including "gdbsupport/gdb_string_view.h". A later patch will remove the users of gdb::to_string. The implementation and tests of gdb::string_view are unchanged, they will be removed in a following patch. Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-21gdb: Replace gdb::optional with std::optionalLancelot Six1-12/+12
Since GDB now requires C++17, we don't need the internally maintained gdb::optional implementation. This patch does the following replacing: - gdb::optional -> std::optional - gdb::in_place -> std::in_place - #include "gdbsupport/gdb_optional.h" -> #include <optional> This change has mostly been done automatically. One exception is gdbsupport/thread-pool.* which did not use the gdb:: prefix as it already lives in the gdb namespace. Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-10-25gdb: make get_symbol_address a private method of symbolSimon Marchi1-5/+5
get_symbol_address is only used symbol::value_address, make it a private helper method. Change-Id: I318ddcfcf1269d95045b8efe9137812df9c5113c Approved-By: Tom Tromey <tom@tromey.com>
2023-10-25gdb: make get_msymbol_address a private method of minimal_symbolSimon Marchi1-6/+6
get_msymbol_address is only used in minimal_symbol::value_address. Make it a private helper method. Change-Id: I3f30e1b9d89ace6682fb08a7ebb91746db0ccf0f Approved-By: Tom Tromey <tom@tromey.com>
2023-10-10gdb: remove target_gdbarchSimon Marchi1-3/+3
This function is just a wrapper around the current inferior's gdbarch. I find that having that wrapper just obscures where the arch is coming from, and that it's often used as "I don't know which arch to use so I'll use this magical target_gdbarch function that gets me an arch" when the arch should in fact come from something in the context (a thread, objfile, symbol, etc). I think that removing it and inlining `current_inferior ()->arch ()` everywhere will make it a bit clearer where that arch comes from and will trigger people into reflecting whether this is the right place to get the arch or not. Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-05gdb: add all_objfiles_removed observerSimon Marchi1-6/+13
The new_objfile observer is currently used to indicate both when a new objfile is added to program space (when passed non-nullptr) and when all objfiles of a program space were just removed (when passed nullptr). I think this is confusing (and Andrew apparently thinks so too [1]). Add a new "all_objfiles_removed" observer to remove the second role from "new_objfile". Some existing users of new_objfile do nothing if the passed objfile is nullptr. For them, we can simply drop the nullptr check. For others, add a new all_objfiles_removed callback, and refactor things a bit to keep the existing behavior as much as possible. Some callbacks relied on current_program_space, and following the refactoring now use either objfile->pspace or the pspace passed to all_objfiles_removed. I think this should be relatively safe, and in general a step in the right direction. On the notify side, I found only one call site to change from new_objfile to all_objfiles_removed, in clear_symtab_users. It is not entirely clear to me that this is entirely correct. clear_symtab_users appears to be called in spots that don't remove all objfiles (functions finish_new_objfile, remove_symbol_file_command, reread_symbols, do_module_cleanups). But I think that this patch at least makes the current code clearer. [1] https://gitlab.com/gnutools/binutils-gdb/-/commit/a0a031bce0527b1521788b5dad640e7883b3a252 Change-Id: Icb648f72862e056267f30f44dd439bd4ec766f13 Approved-By: Tom Tromey <tom@tromey.com>
2023-10-05gdb: add program_space parameters to some functions in symtab.cSimon Marchi1-18/+21
Add some program_space parameters to functions related to getting and setting the main name, making the references to current_program_space bubble up a bit. find_main_name calls ada_main_name, which implicitly relies on the current program space, so I didn't add a parameter to that function. Change-Id: I9996955e8ae56832bbd461964d978e700e6feaf4 Approved-By: Tom Tromey <tom@tromey.com>
2023-09-28gdb: remove one user of the executable changed observerAndrew Burgess1-11/+7
My goal for the next few commits is to expose the executable_changed observable from the Python API. However, there is call to the executable_changed observable in the reread_symbols function (in symfile.c), and this doesn't actually correspond to the executable changing. My idea then, is to remove this use of the executable_changed observable, but, before I can do that, I need to check that nothing is going to break, and that requires my to think about the current users of this observable. One current user of executable_changed is in symtab.c. We add an executable_changed observer that calls: set_main_name (nullptr, language_unknown); to discard all information about the main function when the executable changes. However, changing the executable doesn't actually change the debug information. The debug information changes when the symbol-file changes, so I think this observer is in slightly the wrong place. The new_objfile observable is (unfortunately) overloaded, it is called when a new objfile is loaded, and also (when its argument is nullptr), when all debug information should be discarded. It turns out that there is already a new_objfile observer in symtab.c. I propose that, when the argument is nullptr (indicating all debug info should be discarded), that we should call set_main_name to discard the information about the main function. We can then remove the executable_changed observer from symtab.c. All tests still pass, and, in my local world, I added some debug printf calls, and I think we are still discarded the main information everywhere we need to. Approved-By: Tom Tromey <tom@tromey.com>
2023-09-20Remove explanatory comments from includesTom Tromey1-1/+1
I noticed a comment by an include and remembered that I think these don't really provide much value -- sometimes they are just editorial, and sometimes they are obsolete. I think it's better to just remove them. Tested by rebuilding. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-09-07Simplify block_find_symbolTom Tromey1-6/+7
block_find_symbol takes a callback function, but only two callbacks are ever passed to it -- and they are similar enough that it seems cleaner to just have block_find_symbol do the work itself. Also, block_find_symbol can take a lookup_name_info as an argument, following the general idea of pushing the construction of these objects as high in the call chain as feasible. Regression tested on x86-64 Fedora 38. Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
2023-09-06[gdb/symtab] Handle PU in iterate_over_some_symtabsTom de Vries1-0/+4
When running test-case gdb.base/setshow.exp with target board cc-with-dwz I run into: ... (gdb) info line 1^M Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code.^M (gdb) FAIL: gdb.base/setshow.exp: test_setshow_annotate: annotation_level 1 ... while the expected output is: ... Line 1 of "setshow.c" is at address 0x400527 <main> but contains no code. ��setshow.c:1:0:beg:0x400527 ... The second line of the expected output is missing due to the first line of the expected output being repeated, so the problem is that the "Line 1" line is printed twice. This happens because the PU imported by the CU reuses the filetab of the CU, and both the CU and PU are visited by iterate_over_some_symtabs. Fix this by skipping PUs in iterate_over_some_symtabs. Tested on x86_64-linux, target boards unix, cc-with-dwz and cc-with-dwz-m. Approved-By: Tom Tromey <tom@tromey.com> PR symtab/30797 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30797
2023-08-31Add symbol::matches methodTom Tromey1-3/+2
This adds symbol::matches, a wrapper for symbol_matches_domain. Most places calling symbol_matches_domain can call this method instead, which is a bit less wordy and also (IMO) clearer. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-08-31[symtab/27831] Fix OBJF_MAINLINE assertKevin Buettner1-2/+12
This commit fixes a bug mentioned by Florian Weimer during the libpthread/ld.so load order discussion from 2021. Florian provided instructions for reproducing the bug here: https://sourceware.org/pipermail/gdb-patches/2021-April/177923.html That particular test does some interesting things involving forks, threads, and thread local storage. Fortunately, none of that is needed to reproduce the problem. I've made a new test case (which is now found in a separate commit) contained in the files gdb.base/add-symbol-file-attach.{c,exp}. The .c file is fairly simple as is the recipe for reproducing the problem. After separately starting the test case and noting the process id, start gdb (w/ no arguments), and do the following to reproduce the assertion failure - for this run, the process id of the separately started add-symbol-file-attach process is 4103218: (gdb) add-symbol-file add-symbol-file-attach add symbol table from file "add-symbol-file-attach" (y or n) y Reading symbols from add-symbol-file-attach... (gdb) attach 4103218 Attaching to process 4103218 Load new symbol table from "/tmp/add-symbol-file-attach"? (y or n) y Reading symbols from /tmp/add-symbol-file-attach... Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007f502130bf27 in pause () from /lib64/libc.so.6 (gdb) p foo symtab.c:6417: internal-error: CORE_ADDR get_msymbol_address(objfile*, const minimal_symbol*): Assertion `(objf->flags & OBJF_MAINLINE) == 0' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. The add-symbol-file command causes the symbols to be loaded without the SYMFILE_MAINLINE (and hence the OBJFILE_MAINLINE) flags being set. This, in turn, causes the "maybe_copied" flag to be set for the global symbol (named "foo" in the provided test case). The attach command will cause another objfile to be created, but it will reuse the symtabs from the objfile created by add-symbol-file, leading to a situation in which the OBJFILE_MAINLINE flag will be set for the new (attach-created) objfile, however the "maybe_copied" flag will still be set for the global symbol. Had it been loaded anew, this flag would not be set due to OBJFILE_MAINLINE being set for the objfile. At present, minimal_symbol::value_address looks like this: CORE_ADDR minimal_symbol::value_address (objfile *objfile) const { if (this->maybe_copied (objfile)) return get_msymbol_address (objfile, this); else return (CORE_ADDR (this->unrelocated_address ()) + objfile->section_offsets[this->section_index ()]); } So, we can now see the problem: When the "maybe_copied" flag is set, get_msymbol_address() will be called. However, get_msymbol_address() assumes that it won't be called with the OBF_MAINLINE flag set for the objfile in question. It, in fact, contains an assert() which makes sure that this is the case: gdb_assert ((objf->flags & OBJF_MAINLINE) == 0); (If this assert is removed, then get_msymbol_address() recurses infinitely for the case under consideration.) So, the problem here is that the maybe_copied flag is set for the symbol AND the OBJF_MAINLINE flag is set for the objfile. As noted earlier, this happens due to add-symbol-file being used; this causes the maybe_copied flag to be set. Later, when the attach is performed, OBJF_MAINLINE will be set for that objfile, leading to this unfortunate situation. My first cut at a solution involved adjusting the MSYMBOL_VALUE_ADDRESS macro (which has since been changed to be the method noted above) to include a test of the OBJFILE_MAINLINE flag. However, Simon Marchi, in his review of my patch, suggested a better solution. Simon observed that the 'maybe_copied' flag is (was, after this commit) being set/initialized in record_minimal_symbol() using using the objfile in the context in which the symbol was created. Simon further observed: Today, a single copy is created, as symtabs are shared between objfiles. This means that everything that we store into a symbol must be independent of any objfile. However, the value of the maybe_copied field is dependent on the objfile in the context of which the symbol was created. Meaning that when the symbol is re-used in the context of another objfile, the maybe_copied value is not right in the context of that objfile. So I think it means there isn't a single "is this symbol maybe copied" value, but instead "is this symbol maybe copied, in the context of this given objfile". And the answer is yes or no, depending on whether the objfile is mainline. So maybe_copied should become a method that takes an objfile and returns an answer based on that. Simon's full review can be found here: https://sourceware.org/pipermail/gdb-patches/2021-May/178855.html Simon also provided a patch which implements this suggestion. The current patch is mostly his work, though I did make some adjustments during a rebase in addition to making some changes to account for a concern from Tom Tromey. During his review of the v3 series, Tom noted, "The old approach was specific to ELF, while the new approach will be used by any object format." Tom further observed, "...it seems like it could result in an incorrect evaluation in some scenario." This seemed plausible to me, so I introduced the flag 'object_format_has_copy_relocs' to struct objfile. It is set at the end of elf_symfile_read() in elfread.c. The minimal_symbol::maybe_copied method tests this new flag, forcing this method to return false when the flag is not set. If we find that other object file formats use the same copy reloc mechanism as ELF, then 'object_format_has_copy_relocs' should be set for objfiles using those formats. Lastly, I'll note that this is a strange use case. It's far more common to either let gdb figure out which file to load by itself when attaching, i.e. (gdb) attach 4104360 Attaching to process 4104360 Reading symbols from /tmp/add-symbol-file-attach... Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6 (gdb) p foo $1 = 42 ...or to use the "file" command prior to the attach, like this: (gdb) file add-symbol-file-attach Reading symbols from add-symbol-file-attach... (gdb) attach 4104360 Attaching to program: /tmp/add-symbol-file-attach, process 4104360 Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007fdb1fc33f27 in pause () from /lib64/libc.so.6 Both of these more common scenarios work perfectly fine; using "add-symbol-file" to load the program to which you will attach isn't recommended as a normal use case. That said, it's bad for gdb to assert, hence this fix. Reviewed-by: Simon Marchi <simon.marchi@polymtl.ca> Co-Authored-by: Simon Marchi <simon.marchi@polymtl.ca> Approved-by: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831
2023-06-05Use "unrelocated" terminology in linetable_entryTom Tromey1-7/+10
I forgot to convert struct linetable_entry to use the "unrelocated" (as opposed to "raw") terminology. This patch corrects the oversight.
2023-06-05Use unrelocated_addr in the DWARF readerTom Tromey1-2/+3
This changes various spots in the DWARF reader to use unrelocated_addr.
2023-06-03[gdb/cli] Fix help text of maint set ignore-prologue-end-flagTom de Vries1-1/+1
I noticed here: ... (gdb) help maint set ignore-prologue-end-flag Set if the PROLOGUE-END flag is ignored. The PROLOGUE-END flag from the line-table entries is used to place \ breakpoints past the prologue of functions. Disabeling its use use forces \ the use of prologue scanners. ... a typo in "Disabeling" and accidental word repetition "use use". Fix by replacing with "Disabling" and "use". Reviewed-By: Tom Tromey <tom@tromey.com>
2023-05-19gdb: safety checks in skip_prologue_using_salAndrew Burgess1-3/+5
While working on the previous patch I reverted this commit: commit e86e87f77fd5d8afb3e714f1d9e09e0ff5b4e6ff Date: Tue Nov 28 16:23:32 2006 +0000 * symtab.c (find_pc_sect_line): Do not return a line before the start of a symtab. When I re-ran the testsuite I saw some GDB crashes in the tests: gdb.dwarf2/dw2-line-number-zero.exp gdb.dwarf2/dw2-lines.exp gdb.dwarf2/dw2-vendor-extended-opcode.exp GDB was reading beyond the end of an array in the function skip_prologue_using_sal. Now, without the above commit reverted I don't believe that this should ever happen. Reverting the above commit effectively breaks GDB's symtab_and_line lookup, we try to find a result for an address, and return the wrong symtab and line-table. In skip_prologue_using_sal we then walk the line table looking for an appropriate entry, except we never find one, and GDB just keeps going, wandering off the end of the array. However, I think adding extra protection to prevent walking off the end of the array is pretty cheap, and if something does go wrong in the future then this should prevent a random crash. Obviously, I have no reproducer for this, as I said, I don't think this should impact GDB at all, this is just adding a little extra caution. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-05-12Introduce symbol_block_ops::get_block_valueTom Tromey1-1/+2
This adds a new callback to symbol_block_ops. This callback lets a LOC_BLOCK symbol implement its own function to find the underlying block.
2023-05-12Bump MAX_SYMBOL_IMPLSTom Tromey1-1/+1
A subsequent patch will introduce more aclass registrations, causing the number to go over the current maximum. This bumps the number. Note that there's a separate static assert that ensures that this number doesn't get too large for the field size in the symbol.
2023-05-12Introduce lookup_minimal_symbol_linkageTom Tromey1-23/+8
This introduces a new function, lookup_minimal_symbol_linkage, and refactors a couple other existing functions to call it. This function will be used in a subsequent patch.
2023-05-07Remove ALL_OBJFILE_OSECTIONSTom Tromey1-3/+1
This replaces ALL_OBJFILE_OSECTIONS with an iterator so that for-each can be used.
2023-05-07Rename objfile::sectionsTom Tromey1-2/+2
I think objfile::sections makes sense as the name of the method to iterate over an objfile's sections, so this patch renames the existing field to objfile::sections_start in preparation for that.
2023-04-22gdb: Fix false match issue in skip_prologue_using_linetableWANG Rui1-1/+1
[ Changes in v2: - rebase on trunk Changes in v3: - add test-case ] We should exclude matches to the ending PC to prevent false matches with the next function, as prologue_end is located at the end PC. <fun1>: 0x00: ... <-- start_pc 0x04: ... 0x08: ... <-- breakpoint 0x0c: ret <fun2>: 0x10: ret <-- end_pc | prologue_end of fun2 Tested on x86_64-linux. Co-Authored-By: WANG Rui <r@hev.cc> (fix, tiny change [1]) Co-Authored-By: Tom de Vries <tdevries@suse.de> (test-case) Approved-by: Kevin Buettner <kevinb@redhat.com> [1] https://www.gnu.org/prep/maintain/html_node/Legally-Significant.html PR symtab/30369 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30369
2023-04-21gdb: remove language_autoSimon Marchi1-5/+2
I think that the language_auto enumerator and the auto_language class can be removed. There isn't really an "auto" language, it's only a construct of the "set language" command to say "pick the appropriate language automatically". But "auto" is never the current language. The `current_language` points to the current effective language, and the fact that we're in "auto language" mode is noted by the language_mode global. - Change set_language to handle the "auto" (and "local", which is a synonym) early, instead of in the for loop. I think it makes the two cases (auto vs explicit language) more clearly separated anyway. - Adjust add_set_language_command to hard-code the "auto" string, instead of using the "auto" language definition. - Remove auto_language, rename auto_or_unknown_language to unknown_language and move the bits of the existing unknown_language in there. - Remove the set_language at the end of _initialize_language. I think it's not needed, because we call set_language in gdb_init, after all _initialize functions are called. There is some chance that an _initialize function that runs after _initialize_language implicitly depends on current_language being set, but my testsuite runs haven't found anything like that. - Use language_unknown instead of language_auto when creating a minimal symbol (minimal_symbol_reader::record_full). I think that this value is used to indicate that we don't know the symbol of the minimal symbol (yet), so language_unknown makes sense to me. Update a condition accordingly in ada-lang.c. symbol_find_demangled_name also appears to "normalize" this value from "unknown" to "auto", remove that part and update the condition to just check for language_unknown. Change-Id: I47bcd6c15f607d9818f2e6e413053c2dc8ec5034 Reviewed-By: Tom Tromey <tom@tromey.com>
2023-04-21Handle erroneous DW_AT_call_return_pcTom Tromey1-0/+13
On PPC64, with the test case included in an earlier patch, we found that "finish" would still not correctly find the return value via entry values. The issue is simple. The compiler emits: 0x00000000100032b8 <+28>: bl 0x1000320c <pck__create_large> 0x00000000100032bc <+32>: nop 0x00000000100032c0 <+36>: li r9,42 ... but the DWARF says: <162a> DW_AT_call_return_pc: 0x100032c0 That is, the declared return PC is one instruction past the actual return PC. This patch adds a new arch hook to handle this scenario, and implements it for PPC64. Some care is taken so that GDB will continue to work if this compiler bug is fixed. A GCC patch is here: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613336.html No check for 'nop' is done, as subsequent discussion revealed that the linker might replace this with another instruction.
2023-03-31GDB: Add `info main' commandRichard Bunt1-0/+11
Allow consumers of GDB to extract the name of the main method. This is most useful for Fortran programs which have a variable main method. Used by both MAP and DDT e.g. it is used to detect the presence of debug information. Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
2023-03-28Rename "raw" to "unrelocated"Tom Tromey1-1/+1
Per an earlier discussion, this patch renames the existing "raw" APIs to use the word "unrelocated" instead.
2023-03-28Use unrelocated_addr in minimal symbolsTom Tromey1-1/+1
This changes minimal symbols to use unrelocated_addr. I believe this detected a latent bug in add_pe_forwarded_sym.
2023-03-17Fix line table regressionTom Tromey1-11/+16
Simon pointed out a line table regression, and after a couple of false starts, I was able to reproduce it by hand using his instructions. The bug is that most of the code in do_mixed_source_and_assembly uses unrelocated addresses, but one spot does: pc = low; ... after the text offset has been removed. This patch fixes the problem by introducing a new type to represent unrelocated addresses in the line table. This prevents this sort of bug to some degree (it's still possible to manipulate a CORE_ADDR in a bad way, this is unavoidable). However, this did let the compiler flag a few spots in that function, and now it's not possible to compare an unrelocated address from a line table with an ordinary CORE_ADDR. Regression tested on x86-64 Fedora 36, though note this setup never reproduced the bug in the first place. I also tested it by hand on the disasm-optim test program.
2023-03-11Constify linetablesTom Tromey1-20/+20
Linetables no longer change after they are created. This patch applies const to them. Note there is one hack to cast away const in mdebugread.c. This code allocates a linetable using 'malloc', then later copies it to the obstack. While this could be cleaned up, I chose not to do so because I have no way of testing it. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-11Change linetables to be objfile-independentTom Tromey1-21/+43
This changes linetables to not add the text offset to the addresses they contain. I did this in a few steps, necessarily combined together in one patch: I renamed the 'pc' member to 'm_pc', added the appropriate accessors, and then recompiled. Then I fixed all the errors. Where possible I generally chose to use the raw_pc accessor, as it is less expensive. Note that this patch discounts the possibility that the text section offset might cause wraparound in the addresses in the line table. However, this was already discounted -- in particular, objfile_relocate1 did not re-sort the table in this scenario. (There was a bug open about this, but as far as I can tell this has never happened, it's not even clear what inspired that bug.) Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-09gdb, gdbserver, gdbsupport: fix whitespace issuesSimon Marchi1-15/+15
Replace spaces with tabs in a bunch of places. Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
2023-03-08Remove OBJF_REORDEREDTom Tromey1-12/+5
OBJF_REORDERED is set for nearly every object format. And, despite the ominous warnings here and there, it does not seem very expensive. This patch removes the flag entirely. Reviewed-By: Andrew Burgess <aburgess@redhat.com>
2023-02-26Remove expand_symtab_containing_pcTom Tromey1-23/+0
The function expand_symtab_containing_pc is unused; remove it. Tested by rebuilding.
2023-02-19Remove ALL_BLOCK_SYMBOLSTom Tromey1-20/+14
This removes ALL_BLOCK_SYMBOLS in favor of foreach.
2023-02-19Remove ALL_BLOCK_SYMBOLS_WITH_NAMETom Tromey1-4/+1
This removes ALL_BLOCK_SYMBOLS_WITH_NAME in favor of foreach.
2023-02-19Convert block_static_block and block_global_block to methodsTom Tromey1-5/+5
This converts block_static_block and block_global_block to be methods. This was mostly written by script. It was simpler to convert them at the same time because they're often used near each other.
2023-02-19Convert more block functions to methodsTom Tromey1-1/+1
This converts block_scope, block_set_scope, block_using, and block_set_using to be methods. These are all done at once to make it easier to also convert block_initialize_namespace at the same time. This was mostly written by script.
2023-02-19Convert block_inlined_p to methodTom Tromey1-4/+4
This converts block_inlined_p to be a method. This was mostly written by script.
2023-02-19Convert block_gdbarch to methodTom Tromey1-1/+1
This converts block_gdbarch to be a method. This was mostly written by script.
2023-02-19Convert block_objfile to methodTom Tromey1-5/+5
This converts block_objfile to be a method. This was mostly written by script.
2023-02-19Don't allow NULL as an argument to block_global_blockTom Tromey1-2/+3
block_global_block has special behavior when the block is NULL. Remove this and patch up the callers instead.
2023-02-19Don't allow NULL as an argument to block_static_blockTom Tromey1-4/+9
block_static_block has special behavior when the block is NULL. Remove this and patch up the callers instead.
2023-02-10Use std::string in main_infoTom Tromey1-15/+7
This changes main_info to use std::string. It removes some manual memory management.
2023-02-08Merge fixup_section and fixup_symbol_sectionTom Tromey1-68/+39
fixup_symbol_section delegates all its work to fixup_section, so merge the two. Because there is only a single caller to fixup_symbol_section, we can also remove some of the introductory logic. For example, this will never be called with a NULL objfile any more. The LOC_BLOCK case can be removed, because such symbols are handled by the buildsym code now. Finally, a symbol can only appear in a SEC_ALLOC section, so the loop is modified to skip sections that do not have this flag set.
2023-02-08Remove most calls to fixup_symbol_sectionTom Tromey1-7/+1
Nearly every call to fixup_symbol_section in gdb is incorrect, and if any such call has an effect, it's purely by happenstance. fixup_section has a long comment explaining that the call should only be made before runtime section offsets are applied. And, the loop in this code (the fallback loop -- the minsym lookup code is "ok") is careful to remove these offsets before comparing addresses. However, aside from a single call in dwarf2/read.c, every call in gdb is actually done after section offsets have been applied. So, these calls are incorrect. Now, these calls could be made when the symbol is created. I considered this approach, but I reasoned that the code has been this way for many years, seemingly without ill effect. So, instead I chose to simply remove the offending calls.
2023-02-08Remove compunit_symtab::m_block_line_sectionTom Tromey1-2/+1
The previous patch hard-coded SECT_OFF_TEXT into the buildsym code. After this, it's clear that there is only one caller of compunit_symtab::set_block_line_section, and it always passes SECT_OFF_TEXT. So, remove compunit_symtab::m_block_line_section and use SECT_OFF_TEXT instead.
generated by cgit v1.1 at 2024-12-12 03:01:21 +0000