Replace with calls to blockvector::blocks, and the appropriate method
call on the returned array_view.
Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
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.
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
Add a getter and a setter for a minimal symbol's type. Remove the
corresponding macro and adjust all callers.
Change-Id: I89900df5ffa5687133fe1a16b2e0d4684e67a77d
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
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.
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.
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.
Add a getter and a setter for a symbol's line. Remove the corresponding macro
and adjust all callers.
Change-Id: I229f2b8fcf938c07975f641361313a8761fad9a5
Add a getter and a setter for a symbol's type. Remove the corresponding
macro and adjust all callers.
Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
Add a getter and a setter for a symbol's domain. Remove the
corresponding macro and adjust all callers.
Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
Add a getter and a setter for a compunit_symtab's producer. Remove the
corresponding macro and adjust all callers.
Change-Id: Ia1d6d8a0e247a08a21af23819d71e49b37d8931b
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
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.
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.
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
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
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>
Remove the `TYPE_FIELD_NAME` and `FIELD_NAME` macros, changing all the
call sites to use field::name directly.
Change-Id: I6900ae4e1ffab1396e24fb3298e94bf123826ca6
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.
[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.
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
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.
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
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
3f4d92ebdf 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.
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.
Simon pointed out an error that I made in
compile_cplus_conver_struct_or_union in my original C++ compile submission:
if (type->code () == TYPE_CODE_STRUCT)
{
const char *what = TYPE_DECLARED_CLASS (type) ? "struct" : "class";
resuld = instance->plugin ().build_decl
(what, name.get (), (GCC_CP_SYMBOL_CLASS | nested_access
| (TYPE_DECLARED_CLASS (type)
? GCC_CP_FLAG_CLASS_NOFLAG
: GCC_CP_FLAG_CLASS_IS_STRUCT)),
0, nullptr, 0, filename, line);
}
Notice that WHAT will contain "struct" for TYPE_DECLARED_CLASS. Whoops.
Fortunately this first parameter of build_decl is only used for
debugging.
gdb/ChangeLog
2021-03-24 Keith Seitz <keiths@redhat.com>
* compile/compile-cplus-types.c
(compile_cplus_convert_struct_or_union): Fix TYPE_DECLARED_CLASS
thinko.
I think this makes the names of the methods clearer, especially for the
arch. The type::arch method (which gets the arch owner, or NULL if the
type is not arch owned) is easily confused with the get_type_arch method
(which returns an arch no matter what). The name "arch_owner" will make
it intuitive that the method returns NULL if the type is not arch-owned.
Also, this frees the type::arch name, so we will be able to morph the
get_type_arch function into the type::arch method.
gdb/ChangeLog:
* gdbtypes.h (struct type) <arch>: Rename to...
<arch_owner>: ... this, update all users.
<objfile>: Rename to...
<objfile_owner>: ... this, update all users.
Change-Id: Ie7c28684c7b565adec05a7619c418c69429bd8c0
If the "compile" command is used with an expression that happens to
require a cooked register, then GDB can crash. This patch does not
fix the bug, but at least turns the crash into an error instead.
2021-01-23 Tom Tromey <tom@tromey.com>
PR compile/25575
* compile/compile-loc2c.c (note_register): New function.
(pushf_register_address, pushf_register): Use it.
This changes the GDB compile code to use std::vector<bool> when
computing which registers are used. This is a bit more idiomatic, but
the main benefit is that it also adds some checking when the libstd++
debug mode is enabled.
2021-01-23 Tom Tromey <tom@tromey.com>
* symtab.h (struct symbol_computed_ops) <generate_c_location>:
Change type of "registers_used".
* dwarf2/loc.h (dwarf2_compile_property_to_c): Update.
* dwarf2/loc.c (dwarf2_compile_property_to_c)
(locexpr_generate_c_location, loclist_generate_c_location): Change
type of "registers_used".
* compile/compile.h (compile_dwarf_expr_to_c)
(compile_dwarf_bounds_to_c): Update.
* compile/compile-loc2c.c (pushf_register_address)
(pushf_register, do_compile_dwarf_expr_to_c)
(compile_dwarf_expr_to_c, compile_dwarf_bounds_to_c): Change type
of "registers_used".
* compile/compile-c.h (generate_c_for_variable_locations):
Update.
* compile/compile-c-symbols.c (generate_vla_size)
(generate_c_for_for_one_variable): Change type of
"registers_used".
(generate_c_for_variable_locations): Return std::vector.
* compile/compile-c-support.c (generate_register_struct): Change
type of "registers_used".
(compute): Update.
compile_to_object declares 'error_message' and then immediately calls
reset on it. It seemed better to change it to use initialization
instead; and then I noticed that set_arguments could return a
unique_xmalloc_ptr<char> itself.
2021-01-23 Tom Tromey <tom@tromey.com>
* compile/compile-internal.h (class compile_instance)
<set_arguments>: Change return type.
* compile/compile.c (compile_to_object): Remove call to reset.
(compile_instance::set_arguments): Change return type.
Update all users to use the type::is_objfile_owned method.
gdb/ChangeLog:
* gdbtypes.h (TYPE_OBJFILE_OWNED): Remove, update all users to
use the type::is_objfile_owned method.
Change-Id: Icae84d136393ab9f756f50a33ac3cedda13c5ba2
