aboutsummaryrefslogtreecommitdiff
path: root/gdb/compile
AgeCommit message (Collapse)AuthorFilesLines
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves5-6/+5
Currently, every internal_error call must be passed __FILE__/__LINE__ explicitly, like: internal_error (__FILE__, __LINE__, "foo %d", var); The need to pass in explicit __FILE__/__LINE__ is there probably because the function predates widespread and portable variadic macros availability. We can use variadic macros nowadays, and in fact, we already use them in several places, including the related gdb_assert_not_reached. So this patch renames the internal_error function to something else, and then reimplements internal_error as a variadic macro that expands __FILE__/__LINE__ itself. The result is that we now should call internal_error like so: internal_error ("foo %d", var); Likewise for internal_warning. The patch adjusts all calls sites. 99% of the adjustments were done with a perl/sed script. The non-mechanical changes are in gdbsupport/errors.h, gdbsupport/gdb_assert.h, and gdb/gdbarch.py. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
2022-10-18gdb, compile: unlink objfile stored in moduleMarkus Metzger1-12/+9
When cleaning up after a compile command, we iterate over all objfiles and unlink the first objfile with the same name as the one we compiled. Since we already store a pointer to that objfile in the module and use it to get the name we're comparing against, there's no reason to iterate, at all. We can simply use that objfile. This further avoids potential issues when an objfile with the same name is loaded into a different linker namespace.
2022-10-10Change GDB to use frame_info_ptrTom Tromey3-3/+3
This changes GDB to use frame_info_ptr instead of frame_info * The substitution was done with multiple sequential `sed` commands: sed 's/^struct frame_info;/class frame_info_ptr;/' sed 's/struct frame_info \*/frame_info_ptr /g' - which left some issues in a few files, that were manually fixed. sed 's/\<frame_info \*/frame_info_ptr /g' sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace problems. The changed files were then manually checked and some 'sed' changes undone, some constructors and some gets were added, according to what made sense, and what Tromey originally did Co-Authored-By: Bruno Larsen <blarsen@redhat.com> Approved-by: Tom Tomey <tom@tromey.com>
2022-09-21gdb: remove TYPE_LENGTHSimon Marchi4-23/+23
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-09-21gdb: remove TYPE_TARGET_TYPESimon Marchi4-17/+17
Remove the macro, replace all uses by calls to type::target_type. Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
2022-08-03Use gdb_bfd_ref_ptr in objfileTom Tromey1-1/+1
This changes struct objfile to use a gdb_bfd_ref_ptr. In addition to removing some manual memory management, this fixes a use-after-free that was introduced by the registry rewrite series. The issue there was that, in some cases, registry shutdown could refer to memory that had already been freed. This help fix the bug by delaying the destruction of the BFD reference (and thus the per-bfd object) until after the registry has been shut down.
2022-07-28Change allocation of type-copying hash tableTom Tromey1-2/+2
When an objfile is destroyed, types that are still in use and allocated on that objfile are copied. A temporary hash map is created during this process, and it is allocated on the destroyed objfile's obstack -- which normally is fine, as that is going to be destroyed shortly anyway. However, this approach requires that the objfile be passed to registry destruction, and this won't be possible in the rewritten registry. This patch changes the copied type hash table to simply use the heap instead. It also removes the 'objfile' parameter from copy_type_recursive, to make this all more clear. This patch also fixes an apparent bug in copy_type_recursive. Previously it was copying the dynamic property list to the dying objfile's obstack: - = copy_dynamic_prop_list (&objfile->objfile_obstack, However I think this is incorrect -- that obstack is about to be destroyed.
2022-04-27gdb: remove BLOCKVECTOR_BLOCK and BLOCKVECTOR_NBLOCKS macrosSimon Marchi2-8/+7
Replace with calls to blockvector::blocks, and the appropriate method call on the returned array_view. Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
2022-04-27gdb: remove BLOCK_ENTRY_PC macroSimon Marchi3-5/+5
Replace with equivalent method. Change-Id: I0e033095e7358799930775e61028b48246971a7d
2022-04-27gdb: remove BLOCK_SUPERBLOCK macroSimon Marchi2-3/+3
Replace with equivalent methods. Change-Id: I334a319909a50b5cc5570a45c38c70e10dc00630
2022-04-27gdb: remove BLOCK_FUNCTION macroSimon Marchi2-3/+3
Replace with equivalent methods. Change-Id: I31ec00f5bf85335c8b23d306ca0fe0b84d489101
2022-04-27gdb: remove BLOCK_{START,END} macrosSimon Marchi2-3/+3
Replace with equivalent methods. Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
2022-04-20Replace symbol_symtab with symbol::symtabTom Tromey4-5/+5
This turns symbol_symtab into a method on symbol. It also replaces symbol_set_symtab with a method.
2022-04-20Use symbol_symtab accessor in compile-object-load.cTom Tromey1-1/+1
I noticed that compile-object-load.c directly references owner.symtab of a symbol. However, I think it's better for all users to call symbol_symtab. This patch makes this change.
2022-04-18gdbsupport: make gdb_abspath return an std::stringSimon Marchi1-2/+2
I'm trying to switch these functions to use std::string instead of char arrays, as much as possible. Some callers benefit from it (can avoid doing a copy of the result), while others suffer (have to make one more copy). Change-Id: Iced49b8ee2f189744c5072a3b217aab5af17a993
2022-04-11gdb: remove MSYMBOL_TYPE macroSimon Marchi3-5/+5
Add a getter and a setter for a minimal symbol's type. Remove the corresponding macro and adjust all callers. Change-Id: I89900df5ffa5687133fe1a16b2e0d4684e67a77d
2022-04-11gdb: remove symbol value macrosSimon Marchi5-19/+19
Remove all macros related to getting and setting some symbol value: #define SYMBOL_VALUE(symbol) (symbol)->value.ivalue #define SYMBOL_VALUE_ADDRESS(symbol) \ #define SET_SYMBOL_VALUE_ADDRESS(symbol, new_value) \ #define SYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes #define SYMBOL_VALUE_COMMON_BLOCK(symbol) (symbol)->value.common_block #define SYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block #define SYMBOL_VALUE_CHAIN(symbol) (symbol)->value.chain #define MSYMBOL_VALUE(symbol) (symbol)->value.ivalue #define MSYMBOL_VALUE_RAW_ADDRESS(symbol) ((symbol)->value.address + 0) #define MSYMBOL_VALUE_ADDRESS(objfile, symbol) \ #define BMSYMBOL_VALUE_ADDRESS(symbol) \ #define SET_MSYMBOL_VALUE_ADDRESS(symbol, new_value) \ #define MSYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes #define MSYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block Replace them with equivalent methods on the appropriate objects. Change-Id: Iafdab3b8eefc6dc2fd895aa955bf64fafc59ed50
2022-04-07gdb: remove symtab::blockvectorSimon Marchi2-2/+2
symtab::blockvector is a wrapper around compunit_symtab::blockvector. It is a bit misleadnig, as it gives the impression that a symtab has a blockvector. Remove it, change all users to fetch the blockvector through the compunit instead. Change-Id: Ibd062cd7926112a60d52899dff9224591cbdeebf
2022-03-29Unify gdb printf functionsTom Tromey7-197/+197
Now that filtered and unfiltered output can be treated identically, we can unify the printf family of functions. This is done under the name "gdb_printf". Most of this patch was written by script.
2022-03-29Unify gdb putc functionsTom Tromey1-2/+2
Now that filtered and unfiltered output can be treated identically, we can unify the putc family of functions. This is done under the name "gdb_putc". Most of this patch was written by script.
2022-03-29Unify gdb puts functionsTom Tromey3-68/+68
Now that filtered and unfiltered output can be treated identically, we can unify the puts family of functions. This is done under the name "gdb_puts". Most of this patch was written by script.
2022-02-06gdb: remove SYMBOL_LINE macroSimon Marchi3-4/+4
Add a getter and a setter for a symbol's line. Remove the corresponding macro and adjust all callers. Change-Id: I229f2b8fcf938c07975f641361313a8761fad9a5
2022-02-06gdb: remove SYMBOL_TYPE macroSimon Marchi5-23/+23
Add a getter and a setter for a symbol's type. Remove the corresponding macro and adjust all callers. Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
2022-02-06gdb: remove SYMBOL_DOMAIN macroSimon Marchi2-3/+3
Add a getter and a setter for a symbol's domain. Remove the corresponding macro and adjust all callers. Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
2022-02-06gdb: remove SYMBOL_CLASS macro, add getterSimon Marchi2-7/+7
Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
2022-02-06gdb: remove SYMTAB_BLOCKVECTOR macroSimon Marchi2-2/+2
Remove the macro, replace with an equivalent method. Change-Id: Id6fe2a79c04bcd6c69ccaefb7a69bc06a476288c
2022-02-06gdb: remove COMPUNIT_PRODUCER macro, add getter/setterSimon Marchi1-3/+3
Add a getter and a setter for a compunit_symtab's producer. Remove the corresponding macro and adjust all callers. Change-Id: Ia1d6d8a0e247a08a21af23819d71e49b37d8931b
2022-01-26gdb: add string_file::release methodSimon Marchi1-1/+1
A common pattern for string_file is to want to move out the internal string buffer, because it is the result of the computation that we want to return. It is the reason why string_file::string returns a non-const reference, as explained in the comment. I think it would make sense to have a dedicated method for that instead and make string_file::string return a const reference. This allows removing the explicit std::move in the typical case. Note that compile_program::compute was missing a move, meaning that the resulting string was copied. With the new version, it's not possible to forget to move. Change-Id: Ieaefa35b73daa7930b2f3a26988b6e3b4121bb79
2022-01-18Introduce gdb-hashtab module in gdbsupportTom Tromey1-0/+1
gdb has some extensions and helpers for working with the libiberty hash table. This patch consolidates these and moves them to gdbsupport.
2022-01-18Move gdb_argv to gdbsupportTom Tromey1-0/+1
This moves the gdb_argv class to a new header in gdbsupport.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker17-17/+17
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-12-20Remove print_spacesTom Tromey1-1/+1
This removes the print_spaces helper function, in favor of using the "*%s" idiom that's already used in many places in gdb. One spot (in symmisc.c) is changed to use print_spaces_filtered, because the rest of that function is using filtered output. (This highlights one way that the printf idiom is better -- this error is harder to make when using that.) Regression tested on x86-64 Fedora 34.
2021-11-18gdbsupport: make gdb_assert_not_reached accept a format stringSimon Marchi2-5/+5
Change gdb_assert_not_reached to accept a format string plus corresponding arguments. This allows giving more precise messages. Because the format string passed by the caller is prepended with a "%s:" to add the function name, the callers can no longer pass a translated string (`_(...)`). Make the gdb_assert_not_reached include the _(), just like the gdb_assert_fail macro just above. Change-Id: Id0cfda5a57979df6cdaacaba0d55dd91ae9efee7
2021-10-29gdb: remove TYPE_FIELD_STATIC_PHYSADDRSimon Marchi1-1/+1
Remove TYPE_FIELD_STATIC_PHYSADDR replace with type::field + field::loc_physaddr. Change-Id: Ica9bc4a48f34750ec82ec86c298d3ecece81bcbd
2021-10-29gdb: remove TYPE_FIELD_STATIC_PHYSNAMESimon Marchi1-1/+1
Remove TYPE_FIELD_STATIC_PHYSNAME, replace with type::field + field::loc_physname. Change-Id: Ie35d446b67dd1d02f39998b406001bdb7e6d5abb
2021-10-29gdb: remove TYPE_FIELD_ENUMVALSimon Marchi2-2/+2
Remove TYPE_FIELD_ENUMVAL, replace with type::field + field::loc_enumval. Change-Id: I2ada73e4635aad3363ce2eb22c1dc52698ee2072
2021-10-29gdb: remove TYPE_FIELD_BITPOSSimon Marchi3-3/+3
Remove TYPE_FIELD_BITPOS, replace its uses with type::field + field::loc_bitpos. Change-Id: Iccd8d5a77e5352843a837babaa6bd284162e0320
2021-10-29gdb: remove TYPE_FIELD_LOC_KINDSimon Marchi1-2/+2
Remove TYPE_FIELD_LOC_KIND, replace its uses with type::field + field::loc_kind. Change-Id: Ib124a26365df82ac1d23df7962d954192913bd90
2021-10-25gdb: change functions returning value contents to use gdb::array_viewSimon Marchi1-1/+2
The bug fixed by this [1] patch was caused by an out-of-bounds access to a value's content. The code gets the value's content (just a pointer) and then indexes it with a non-sensical index. This made me think of changing functions that return value contents to return array_views instead of a plain pointer. This has the advantage that when GDB is built with _GLIBCXX_DEBUG, accesses to the array_view are checked, making bugs more apparent / easier to find. This patch changes the return types of these functions, and updates callers to call .data() on the result, meaning it's not changing anything in practice. Additional work will be needed (which can be done little by little) to make callers propagate the use of array_view and reap the benefits. [1] https://sourceware.org/pipermail/gdb-patches/2021-September/182306.html Change-Id: I5151f888f169e1c36abe2cbc57620110673816f3
2021-10-03gdb: make string-like set show commands use std::string variableSimon Marchi1-23/+23
String-like settings (var_string, var_filename, var_optional_filename, var_string_noescape) currently take a pointer to a `char *` storage variable (typically global) that holds the setting's value. I'd like to "mordernize" this by changing them to use an std::string for storage. An obvious reason is that string operations on std::string are often easier to write than with C strings. And they avoid having to do any manual memory management. Another interesting reason is that, with `char *`, nullptr and an empty string often both have the same meaning of "no value". String settings are initially nullptr (unless initialized otherwise). But when doing "set foo" (where `foo` is a string setting), the setting now points to an empty string. For example, solib_search_path is nullptr at startup, but points to an empty string after doing "set solib-search-path". This leads to some code that needs to check for both to check for "no value". Or some code that converts back and forth between NULL and "" when getting or setting the value. I find this very error-prone, because it is very easy to forget one or the other. With std::string, we at least know that the variable is not "NULL". There is only one way of representing an empty string setting, that is with an empty string. I was wondering whether the distinction between NULL and "" would be important for some setting, but it doesn't seem so. If that ever happens, it would be more C++-y and self-descriptive to use optional<string> anyway. Actually, there's one spot where this distinction mattered, it's in init_history, for the test gdb.base/gdbinit-history.exp. init_history sets the history filename to the default ".gdb_history" if it sees that the setting was never set - if history_filename is nullptr. If history_filename is an empty string, it means the setting was explicitly cleared, so it leaves it as-is. With the change to std::string, this distinction doesn't exist anymore. This can be fixed by moving the code that chooses a good default value for history_filename to _initialize_top. This is ran before -ex commands are processed, so an -ex command can then clear that value if needed (what gdb.base/gdbinit-history.exp tests). Another small improvement, in my opinion is that we can now easily give string parameters initial values, by simply initializing the global variables, instead of xstrdup-ing it in the _initialize function. In Python and Guile, when registering a string-like parameter, we allocate (with new) an std::string that is owned by the param_smob (in Guile) and the parmpy_object (in Python) objects. This patch started by changing all relevant add_setshow_* commands to take an `std::string *` instead of a `char **` and fixing everything that failed to build. That includes of course all string setting variable and their uses. string_option_def now uses an std::string also, because there's a connection between options and settings (see add_setshow_cmds_for_options). The add_path function in source.c is really complex and twisted, I'd rather not try to change it to work on an std::string right now. Instead, I added an overload that copies the std:string to a `char *` and back. This means more copying, but this is not used in a hot path at all, so I think it is acceptable. Change-Id: I92c50a1bdd8307141cdbacb388248e4e4fc08c93 Co-authored-by: Lancelot SIX <lsix@lancelotsix.com>
2021-09-30gdb: remove TYPE_FIELD_NAME and FIELD_NAME macrosSimon Marchi3-5/+5
Remove the `TYPE_FIELD_NAME` and `FIELD_NAME` macros, changing all the call sites to use field::name directly. Change-Id: I6900ae4e1ffab1396e24fb3298e94bf123826ca6
2021-08-08Include objfiles.h in a few .c filesTom Tromey1-0/+1
I found a few .c files that rely on objfiles.h, but that only include it indirectly, via dwarf2/read.h -> psympriv.h. If that include is removed (something my new DWARF indexer series does), then the build will break. It seemed harmless and correct to add these includes now, making the eventual series a little smaller.
2021-08-05[gdb] Handle .TOC. sections during gdb-compile for rs6000 target.Will Schmidt1-0/+41
[gdb] Handle .TOC. sections during gdb-compile for rs6000 target. When we encounter a .TOC. symbol in the object we are loading, we need to associate this with the .toc section in order to properly resolve other symbols in the object. IF a .toc section is not found, iterate the sections until we find one with the SEC_ALLOC flag. If that also fails, fall back to using the *ABS* section, pointed to by bfd_abs_section_ptr.
2021-06-17Introduce scoped_restore_signalPedro Alves1-28/+1
We currently have scoped_restore_sigttou and scoped_restore_sigpipe doing basically the same thing -- temporarily ignoring a specific signal. This patch introduce a scoped_restore_signal type that can be used for both. This will become more important for the next patch which changes how the signal-ignoring is implemented. scoped_restore_sigpipe is a straight alias to scoped_restore_signal<SIGPIPE> on systems that define SIGPIPE, and an alias to scoped_restore_signal_nop (a no-op version of scoped_restore_signal) otherwise. scoped_restore_sigttou is not a straight alias because it wants to check the job_control global. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <pedro@palves.net> * gdbsupport/scoped_ignore_signal.h: New. * compile/compile.c: Include gdbsupport/scoped_ignore_signal.h instead of <signal.h>. Don't include <unistd.h>. (scoped_ignore_sigpipe): Remove. * gdbsupport/scoped_ignore_sigttou.h: Include gdbsupport/scoped_ignore_signal.h instead of <signal.h>. Don't include <unistd.h>. (lazy_init): New. (scoped_ignore_sigttou): Reimplement using scoped_ignore_signal and lazy_init. Change-Id: Ibb44d0bd705e96df03ef0787c77358a4a7b7086c
2021-06-14Include missing header signal.hBernd Edlinger1-0/+1
2021-06-14 Bernd Edlinger <bernd.edlinger@hotmail.de> * compile/compile.c: Include missing header signal.h.
2021-06-05Fix gdb crash due to SIGPIPE when the compile command failsBernd Edlinger1-0/+31
Due to the SIGPIPE the gdb process is killed here, which is not helpful. 2021-06-05 Bernd Edlinger <bernd.edlinger@hotmail.de> * compile/compile.c (scoped_ignore_sigpipe): New helper class. (compile_to_object): Ignore SIGPIPE before calling the plugin.
2021-05-27gdb: make add_com_alias accept target as a cmd_list_elementSimon Marchi1-1/+1
The alias creation functions currently accept a name to specify the target command. They pass this to add_alias_cmd, which needs to lookup the target command by name. Given that: - We don't support creating an alias for a command before that command exists. - We always use add_info_alias just after creating that target command, and therefore have access to the target command's cmd_list_element. ... change add_com_alias to accept the target command as a cmd_list_element (other functions are done in subsequent patches). This ensures we don't create the alias before the target command, because you need to get the cmd_list_element from somewhere when you call the alias creation function. And it avoids an unecessary command lookup. So it seems better to me in every aspect. gdb/ChangeLog: * command.h (add_com_alias): Accept target as cmd_list_element. Update callers. Change-Id: I24bed7da57221cc77606034de3023fedac015150
2021-05-12gdb: generate the prefix name for prefix commands on demandMarco Barisione1-1/+1
Previously, the prefixname field of struct cmd_list_element was manually set for prefix commands. This seems verbose and error prone as it required every single call to functions adding prefix commands to specify the prefix name while the same information can be easily generated. Historically, this was not possible as the prefix field was null for many commands, but this was fixed in commit 3f4d92ebdf7f848b5ccc9e8d8e8514c64fde1183 by Philippe Waroquiers, so we can rely on the prefix field being set when generating the prefix name. This commit also fixes a use after free in this scenario: * A command gets created via Python (using the gdb.Command class). The prefix name member is dynamically allocated. * An alias to the new command is created. The alias's prefixname is set to point to the prefixname for the original command with a direct assignment. * A new command with the same name as the Python command is created. * The object for the original Python command gets freed and its prefixname gets freed as well. * The alias is updated to point to the new command, but its prefixname is not updated so it keeps pointing to the freed one. gdb/ChangeLog: * command.h (add_prefix_cmd): Remove the prefixname argument as it can now be generated automatically. Update all callers. (add_basic_prefix_cmd): Ditto. (add_show_prefix_cmd): Ditto. (add_prefix_cmd_suppress_notification): Ditto. (add_abbrev_prefix_cmd): Ditto. * cli/cli-decode.c (add_prefix_cmd): Ditto. (add_basic_prefix_cmd): Ditto. (add_show_prefix_cmd): Ditto. (add_prefix_cmd_suppress_notification): Ditto. (add_prefix_cmd_suppress_notification): Ditto. (add_abbrev_prefix_cmd): Ditto. * cli/cli-decode.h (struct cmd_list_element): Replace the prefixname member variable with a method which generates the prefix name at runtime. Update all code reading the prefix name to use the method, and remove all code setting it. * python/py-cmd.c (cmdpy_destroyer): Remove code to free the prefixname member as it's now a method. (cmdpy_function): Determine if the command is a prefix by looking at prefixlist, not prefixname.
2021-04-01gdb: remove TYPE_DECLARED_CLASSSimon Marchi1-3/+3
gdb/ChangeLog: * gdbtypes.h (TYPE_DECLARED_CLASS): Remove, replace all uses with type::is_declared_class. Change-Id: Ifecb2342417ecd7bf570c3205344b09d706daab2
2021-03-29Don't pass empty options to GCCLuis Machado1-1/+7
On aarch64-linux, I noticed the compile command didn't work at all. It always gave the following error: aarch64-linux-gnu-g++: error: : No such file or directory Turns out we're passing an empty argv entry to GCC (because aarch64 doesn't have a -m64 option), and GCC's behavior is to think that is a file it needs to open. One can reproduce it like so: gcc "" "" "" "" gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: error: : No such file or directory gcc: fatal error: no input files compilation terminated. The solution is to check for an empty string and skip adding that to argv. Regression tested on aarch64-linux/Ubuntu 18.04/20.04. gdb/ChangeLog: 2021-03-29 Luis Machado <luis.machado@linaro.org> * compile/compile.c (get_args): Don't add empty argv entries.
generated by cgit v1.1 at 2025-01-31 01:37:39 +0000