Currently, it's not possible to call a variadic C++ function:
```
(gdb) print sum_vararg_int(1, 10)
Cannot resolve function sum_vararg_int to any overloaded instance
(gdb) print sum_vararg_int(2, 20, 30)
Cannot resolve function sum_vararg_int to any overloaded instance
```
It's because all additional arguments get the TOO_FEW_PARAMS_BADNESS
rank by rank_function, which disqualifies the function.
To fix this, I've created the new VARARG_BADNESS rank, which is
used only for additional arguments of variadic functions, allowing
them to be called:
```
(gdb) print sum_vararg_int(1, 10)
$1 = 10
(gdb) print sum_vararg_int(2, 20, 30)
$2 = 50
```
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28589
Approved-By: Tom Tromey <tom@tromey.com>
A recent change to 'struct field' caused a build failure with GCC
7.5.0, as reported by Tom de Vries:
/data/vries/gdb/src/gdb/gdbtypes.h:721:51: error:
‘field::m_accessibility’ is too small to hold all values of ‘enum
class accessibility’ [-Werror]
ENUM_BITFIELD (accessibility) m_accessibility : 2;
^
Mark Wielaard pointed out that this was a GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
This patch works around the bug by changing several members not to be
bitfields. It reduces the size of the enum's underlying type,
instead.
I also changed m_bitsize to no longer be a bitfield -- that was done
for packing reasons in ancient times, but with m_accessibility not
being a bitfield, this no longer matters.
I removed fn_field::dummy. In earlier times it was somewhat normal in
gdb to have these dummy fields to keep track of any available padding.
However, since the advent of "ptype/o", there doesn't seem to be any
need for this.
This patch does not change the size of struct field, fn_field, or
decl_field on 64-bit hosts.
This changes nested types and member functions to use the new
'accessibility' enum, rather than separate private/protected flags.
This is done for consistency, but it also lets us simplify some other
code in the next patch.
Acked-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Keith Seitz <keiths@redhat.com>
This removes the char-based bitfield macros from gdbtypes.h, as they
are no longer used.
Acked-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Keith Seitz <keiths@redhat.com>
This removes TYPE_FIELD_PRIVATE, TYPE_FIELD_PROTECTED,
TYPE_FIELD_IGNORE, and TYPE_FIELD_VIRTUAL.
In c-varobj.c, match_accessibility can be removed entirely now. Note
that the comment before this function was incorrect.
Acked-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Keith Seitz <keiths@redhat.com>
This adds a field::is_public convenience method, and updates one spot
to use it.
Acked-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Keith Seitz <keiths@redhat.com>
This removes some byte vectors from cplus_struct_type, moving the
information into bitfields in holes in struct field.
A new 'enum accessibility' is added to hold some of this information.
A similar enum is removed from c-varobj.c.
Note that the stabs reader treats "ignored" as an accessibility.
However, the stabs texinfo documents this as a public field that is
optimized out -- unfortunately nobody has updated the stabs reader to
use the better value-based optimized-out machinery. I looked and
apparently gcc never emitted this visibility value, so whatever
compiler generated this stab is unknown. I left a comment in
gdbtypes.h to this effect.
Acked-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Keith Seitz <keiths@redhat.com>
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>
This changes main_type to hold a language, and updates the debug
readers to set this field. This is done by adding the language to the
type-allocator object.
Note that the non-DWARF readers are changed on a "best effort" basis.
This patch also reimplements type::is_array_like to use the type's
language, and it adds a new type::is_string_like as well. This in
turn lets us change the Python implementation of these methods to
simply defer to the type.
init_fixed_point_type currently takes an objfile and creates its own
type allocator. However, for a later patch it is more convenient if
this function accepts a type allocator. This patch makes this change.
This adds the type::is_array_like method and the value_to_array
function.
The former can be used to see whether a given type is known to be
"array-like". This is the currently the case for certain
compiler-generated structure types; in particular both the Ada and
Rust compilers do this.
This adds a new enum constant, TYPE_SPECIFIC_RUST_STUFF, and changes
the DWARF reader to set this on Rust types. This will be used as a
flag in a later patch.
Note that the size of the type_specific_field bitfield had to be
increased. I checked that this did not impact the size of main_type.
Replace with a new equivalent "is_packed" method on struct field.
Change-Id: I78647be3d408b40b63becb6b6f0fca211bede51c
Approved-By: Tom Tromey <tom@tromey.com>
Add these two methods, rename the field to m_bitsize to make it pseudo
private.
Change-Id: Ief95e5cf106e72f2c22ae47b033d0fa47202b413
Approved-By: Tom Tromey <tom@tromey.com>
Add these two methods, rename the field to m_artificial to make it
pseudo private.
Change-Id: If3a3825473d1d79bb586a8a074b87bba9b43fb1a
Approved-By: Tom Tromey <tom@tromey.com>
After finding this code in buildsym_compunit::finish_block_internal:
...
ftype->set_fields
((struct field *)
TYPE_ALLOC (ftype, nparams * sizeof (struct field)));
...
and fixing PR30810 by using TYPE_ZALLOC, I wondered if there were more
locations that needed fixing.
I decided to make things easier to spot by factoring out a new function
alloc_fields:
...
/* Allocate the fields array of this type, with NFIELDS elements. If INIT,
zero-initialize the allocated memory. */
void
type::alloc_fields (unsigned int nfields, bool init = true);
...
where:
- a regular use would be "alloc_fields (nfields)", and
- an exceptional use that needed no initialization would be
"alloc_fields (nfields, false)".
Pretty soon I discovered that most of the latter cases are due to
initialization by memcpy, so I added two variants of copy_fields as well.
After this rewrite there are 8 uses of set_fields left:
...
gdb/coffread.c: type->set_fields (nullptr);
gdb/coffread.c: type->set_fields (nullptr);
gdb/coffread.c: type->set_fields (nullptr);
gdb/eval.c: type->set_fields
gdb/gdbtypes.c: type->set_fields (args);
gdb/gdbtypes.c: t->set_fields (XRESIZEVEC (struct field, t->fields (),
gdb/dwarf2/read.c: type->set_fields (new_fields);
gdb/dwarf2/read.c: sub_type->set_fields (sub_type->fields () + 1);
...
These fall into the following categories:
- set to nullptr (coffread.c),
- type not owned by objfile or gdbarch (eval.c), and
- modifying an existing fields array, like adding an element at the end or
dropping an element at the start (the rest).
Tested on x86_64-linux.
Given this test program:
#include <wchar.h>
const wchar_t wide_str[] = L"wide string";
int
main (void)
{
return 0;
}
I observed this GDB behaviour:
$ gdb -q /tmp/printf-wchar_t
Reading symbols from /tmp/printf-wchar_t...
(gdb) start
Temporary breakpoint 1 at 0x40110a: file /tmp/printf-wchar_t.c, line 8.
Starting program: /tmp/printf-wchar_t
Temporary breakpoint 1, main () at /tmp/printf-wchar_t.c:8
25 return 0;
(gdb) printf "%ls\n", wide_str
(gdb)
Notice that the printf results in a blank line rather than the
expected 'wide string' output.
I tracked the problem down to printf_wide_c_string (in printcmd.c), in
this function we do this:
struct type *wctype = lookup_typename (current_language,
"wchar_t", NULL, 0);
int wcwidth = wctype->length ();
the problem here is that 'wchar_t' is a typedef. If we look at the
comment on type::length() we see this:
/* Note that if thistype is a TYPEDEF type, you have to call check_typedef.
But check_typedef does set the TYPE_LENGTH of the TYPEDEF type,
so you only have to call check_typedef once. Since value::allocate
calls check_typedef, X->type ()->length () is safe. */
What this means is that after calling lookup_typename we should call
check_typedef in order to ensure that the length of the typedef has
been setup correctly. We are not doing this in printf_wide_c_string,
and so wcwidth is incorrectly calculated as 0. This is what leads GDB
to print an empty string.
We can see in c_string_operation::evaluate (in c-lang.c) an example of
calling check_typedef specifically to fix this exact issue.
Initially I did fix this problem by adding a check_typedef call into
printf_wide_c_string, but then I figured why not move the
check_typedef call up into lookup_typename itself, that feels like it
should be harmless when looking up a non-typedef type, but will avoid
bugs like this when looking up a typedef. So that's what I did.
I can then remove the extra check_typedef call from c-lang.c, I don't
see any other places where we had extra check_typedef calls. This
doesn't mean we definitely had bugs -- so long as we never checked the
length, or, if we knew that check_typedef had already been called,
then we would be fine.
I don't see any test regressions after this change, and my new test
case is now passing.
Reviewed-By: Tom Tromey <tom@tromey.com>
I noticed many spots checking whether a dynamic property's kind is
PROP_CONST. Some spots, I think, are doing a slightly incorrect check
-- checking for != PROP_UNDEFINED where == PROP_CONST is actually
required, the key thing being that const_val may only be called for
PROP_CONST properties.
This patch adds dynamic::is_constant and then updates these checks to
use it.
Regression tested on x86-64 Fedora 36.
This changes field_is_static to be a method on struct field, and
updates all the callers. Most of this patch was written by script.
Regression tested on x86-64 Fedora 36.
This adds a frame parameter to resolve_dynamic_type and arranges for
it to be passed through the call tree and, in particular, to all calls
to dwarf2_evaluate_property.
Nothing passes this parameter yet, so this patch should have no
visible effect.
A 'const frame_info_ptr *' is used here to avoid including frame.h
from gdbtypes.h.
This adds some types to struct builtin_type, ensuring it contains all
the types currently used by objfile_type.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
This renames objfile_type to be an overload of builtin_type, in
preparation for their unification.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
This changes the set type creation function to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
underlying type of the set, which is what this patch implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
This changes the array type creation functions to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
placement of the index type of the array, which is what this patch
implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
This changes the range type creation functions to accept a type
allocator, and updates all the callers. Note that symbol readers
should generally allocate on the relevant objfile, regardless of the
underlying type of the range, which is what this patch implements.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
This introduces a new type_allocator class. This class will be used
to abstract out the placement of new types, so that type-creation code
can be simplified and shared.
Reviewed-By: Simon Marchi <simon.marchi@efficios.com>
allocate_stub_method is only called from stabsread.c, and I don't
think it will be needed anywhere else. So, move it and make it
static. Tested by rebuilding.
Once a baton is stored in a struct type, it doesn't make sense to
modify it. This patch constifies the API.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdbtypes treats dynamic property batons as 'void *', but in actuality
the only users all use dwarf2_property_baton. This patch changes this
code to be type-safe. If a new type is needed here, it seems like
that too could be done in a type-safe way.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
main_type::nfields is a 'short', and has been for many years. PR
c++/29985 points out that 'short' is too narrow for an enum that
contains more than 2^15 constants.
This patch bumps the size of 'nfields'. To verify that the field
isn't directly used, it is also renamed. Note that this does not
affect the size of main_type on x86-64 Fedora 36. And, if it does
have a negative effect somewhere, it's worth considering that types
could be shrunk more drastically by using subclasses for the different
codes.
This is v2 of this patch, which has these changes:
* I changed nfields to 'unsigned', per Simon's request. I looked at
changing all the uses, but this quickly fans out into a very large
patch. (One additional tweak was needed, though.)
* I wrote a test case. I discovered that GCC cannot compile a large
enough C test case, so I resorted to using the DWARF assembler.
This test doesn't reproduce the crash, but it does fail without the
patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29985
A patch later in this series will make frame_info_ptr access some
fields internal to frame_info, which we don't want to expose outside of
frame.c. Move the frame_info_ptr class to frame.h, and the definitions
to frame.c. Remove frame-info.c and frame-info.h.
Change-Id: Ic5949759e6262ea0da6123858702d48fe5673fea
Reviewed-By: Bruno Larsen <blarsen@redhat.com>
