96 Commits

Author SHA1 Message Date
888438e2b4 Use clean_restart in gdb.guile
Change gdb.guile to use clean_restart more consistently.
2023-01-26 18:28:31 -07:00
77519ab324 GDB/testsuite: Expand for character string limiting options
Modify test cases that verify the operation of the array element limit
with character strings such that they are executed twice, once with the
`set print characters' option set to `elements' and the limit controlled
with the `set print elements' option, and then again with the limit
controlled with the `set print characters' option instead.  Similarly
with the `-elements' and `-characters' options for the `print' command.
Additionally verify that said `print' command options combined yield the
expected result.

Verify correct $_gdb_setting and $_gdb_setting_str values for the `print
characters' setting, in particular the `void' value for the `elements'
default, which has no corresponding integer value exposed.

Add Guile and Python coverage for the `print characters' GDB setting.

There are new tests for Ada and Pascal, as the string printing code for
these languages is different than the generic string printing code used
by other languages.  Modula2 also has different string printing code,
but (a) this is similar to Pascal, and (b) there are no existing modula2
tests written in Modula2, so I'm not sure how I'd even test the Modula2
string printing.

Co-Authored-By: Maciej W. Rozycki <macro@embecosm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
7aeb03e2d4 GDB: Allow arbitrary keywords in integer set commands
Rather than just `unlimited' allow the integer set commands (or command
options) to define arbitrary keywords for the user to use, removing
hardcoded arrangements for the `unlimited' keyword.

Remove the confusingly named `var_zinteger', `var_zuinteger' and
`var_zuinteger_unlimited' `set'/`show' command variable types redefining
them in terms of `var_uinteger', `var_integer' and `var_pinteger', which
have the range of [0;UINT_MAX], [INT_MIN;INT_MAX], and [0;INT_MAX] each.

Following existing practice `var_pinteger' allows extra negative values
to be used, however unlike `var_zuinteger_unlimited' any number of such
values can be defined rather than just `-1'.

The "p" in `var_pinteger' stands for "positive", for the lack of a more
appropriate unambiguous letter, even though 0 obviously is not positive;
"n" would be confusing as to whether it stands for "non-negative" or
"negative".

Add a new structure, `literal_def', the entries of which define extra
keywords allowed for a command and numerical values they correspond to.
Those values are not verified against the basic range supported by the
underlying variable type, allowing extra values to be allowed outside
that range, which may or may not be individually made visible to the
user.  An optional value translation is possible with the structure to
follow the existing practice for some commands where user-entered 0 is
internally translated to UINT_MAX or INT_MAX.  Such translation can now
be arbitrary.  Literals defined by this structure are automatically used
for completion as necessary.

So for example:

const literal_def integer_unlimited_literals[] =
  {
    { "unlimited", INT_MAX, 0 },
    { nullptr }
  };

defines an extra `unlimited' keyword and a user-visible 0 value, both of
which get translated to INT_MAX for the setting to be used with.

Similarly:

const literal_def zuinteger_unlimited_literals[] =
  {
    { "unlimited", -1, -1 },
    { nullptr }
  };

defines the same keyword and a corresponding user-visible -1 value that
is used for the requested setting.  If the last member were omitted (or
set to `{}') here, then only the keyword would be allowed for the user
to enter and while -1 would still be used internally trying to enter it
as a part of a command would result in an "integer -1 out of range"
error.

Use said error message in all cases (citing the invalid value requested)
replacing "only -1 is allowed to set as unlimited" previously used for
`var_zuinteger_unlimited' settings only rather than propagating it to
`var_pinteger' type.  It could only be used for the specific case where
a single extra `unlimited' keyword was defined standing for -1 and the
use of numeric equivalents is discouraged anyway as it is for historical
reasons only that they expose GDB internals, confusingly different
across variable types.  Similarly update the "must be >= -1" Guile error
message.

Redefine Guile and Python parameter types in terms of the new variable
types and interpret extra keywords as Scheme keywords and Python strings
used to communicate corresponding parameter values.  Do not add a new
PARAM_INTEGER Guile parameter type, however do handle the `var_integer'
variable type now, permitting existing parameters defined by GDB proper,
such as `listsize', to be accessed from Scheme code.

With these changes in place it should be trivial for a Scheme or Python
programmer to expand the syntax of the `make-parameter' command and the
`gdb.Parameter' class initializer to have arbitrary extra literals along
with their internal representation supplied.

Update the testsuite accordingly.

Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-01-19 21:15:56 +00:00
e71b6502bf Rename to allow_guile_tests
This changes skip_guile_tests to invert the sense, and renames it to
allow_guile_tests.  It also rewrites this proc to check the output of
"gdb --configuration", as was done for Python.  Then it changes the
code to use "require" where possible.
2023-01-13 13:18:58 -07:00
0b94d2b9aa Rename to allow_cplus_tests and allow_stl_tests
This changes skip_cplus_tests to invert the sense, and renames it to
allow_cplus_tests.  This one also converts skip_stl_tests to
allow_stl_tests, as that was convenient to do at the same time.
2023-01-13 13:18:57 -07:00
7978d474f2 Use require !skip_cplus_tests
This changes some tests to use "require !skip_cplus_tests".
2023-01-13 13:18:55 -07:00
213516ef31 Update copyright year range in header of all files managed by GDB
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
2023-01-01 17:01:16 +04:00
8b272d7671 [gdb/testsuite] Fix gdb.guile/scm-symtab.exp for ppc64le
On powerpc64le-linux, I run into:
...
(gdb) PASS: gdb.guile/scm-symtab.exp: step out of func2
guile (print (> (sal-line (find-pc-line (frame-pc (selected-frame)))) line))^M
= #f^M
(gdb) FAIL: gdb.guile/scm-symtab.exp: test find-pc-line with resume address
...

The problem is as follows: the instructions for the call to func2 are:
...
    1000070c:   39 00 00 48     bl      10000744 <func1>
    10000710:   00 00 00 60     nop
    10000714:   59 00 00 48     bl      1000076c <func2>
    10000718:   00 00 00 60     nop
    1000071c:   00 00 20 39     li      r9,0
...
and the corresponding line number info is:
...
scm-symtab.c:
File name     Line number    Starting address    View    Stmt
scm-symtab.c           42          0x1000070c               x
scm-symtab.c           43          0x10000714               x
scm-symtab.c           44          0x1000071c               x
...

The test-case looks at the line numbers for two insns:
- the insn of the call to func2 (0x10000714), and
- the insn after that (0x10000718),
and expects the line number of the latter to be greater than the line number
of the former.

However, both insns have the same line number: 43.

Fix this by replacing ">" with ">=".

Tested on x86_64-linux and powerpc64le-linux.
2022-12-09 10:41:13 +01:00
f50c72da4d gdb/testsuite: remove use of then keyword from gdb.*/*.exp scripts
The canonical form of 'if' in modern TCL is 'if {} {}'.  But there's
still a bunch of places in the testsuite where we make use of the
'then' keyword, and sometimes these get copies into new tests, which
just spreads poor practice.

This commit removes all use of the 'then' keyword from the remaining
gdb.*/*.exp scripts.  Previous commits have done the bulk of this
removal, this commit just handles the remaining directories that each
contain a low number of instances.

There should be no changes in what is tested after this commit.
2022-11-28 21:04:10 +00:00
4404bce9a7 gdb/testsuite: Wrap `param_integer_error' in gdb.guile/scm-parameter.exp
Wrap an overlong line in the definition of `param_integer_error' in
gdb.guile/scm-parameter.exp.  No functional change.
2022-10-29 14:54:13 +01:00
ee7f721ea2 gdb/testsuite: fix gdb.guile/scm-parameter.exp "wrong type argument" test pattern for Guile >= 2.2
Since commit 90319cefe3 ("GDB/Guile: Don't assert that an integer value
is boolean"), I see:

    FAIL: gdb.guile/scm-parameter.exp: kind=PARAM_ZINTEGER: test-PARAM_ZINTEGER-param: guile (set-parameter-value! test-PARAM_ZINTEGER-param #:unlimited)
    FAIL: gdb.guile/scm-parameter.exp: kind=PARAM_ZUINTEGER: test-PARAM_ZUINTEGER-param: guile (set-parameter-value! test-PARAM_ZUINTEGER-param #:unlimited)

This comes from the fact that GDB outputs this:

    ERROR: In procedure set-parameter-value!:
    In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 (expecting integer): #:unlimited
    Error while executing Scheme code.

while the test expects an additional "ERROR:" on the second line,
something like this:

    ERROR: In procedure set-parameter-value!:
    ERROR: In procedure gdbscm_set_parameter_value_x: Wrong type argument in position 2 (expecting integer): #:unlimited
    Error while executing Scheme code.

Guile 2.0 outputs the `ERROR:` on the second line, while later versions
do not.  Change the pattern to accept both outputs.  This is similar to
commit 6bbe1a929c6 ("[gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp
with guile 3.0").

Change-Id: I9dc45e7492a4f08340cad974610242ed689de959
2022-10-26 11:23:40 -04:00
90319cefe3 GDB/Guile: Don't assert that an integer value is boolean
Do not assert that a value intended for an integer parameter, of either
the PARAM_UINTEGER or the PARAM_ZUINTEGER_UNLIMITED type, is boolean,
causing error messages such as:

ERROR: In procedure make-parameter:
ERROR: In procedure gdbscm_make_parameter: Wrong type argument in position 15 (expecting integer or #:unlimited): 3
Error while executing Scheme code.

when initialization with a number is attempted.  Instead assert that it
is integer.  Keep matching `#:unlimited' keyword as an alternative.  Add
suitable test cases.

Approved-By: Simon Marchi <simon.marchi@polymtl.ca>
2022-10-21 08:54:18 +01:00
9704b8b4bc gdb/testsuite: remove unneeded calls to get_compiler_info
It is not necessary to call get_compiler_info before calling
test_compiler_info, and, after recent commits that removed setting up
the gcc_compiled, true, and false globals from get_compiler_info,
there is now no longer any need for any test script to call
get_compiler_info directly.

As a result every call to get_compiler_info outside of lib/gdb.exp is
redundant, and this commit removes them all.

There should be no change in what is tested after this commit.
2022-06-24 15:07:29 +01:00
4a94e36819 Automatic Copyright Year update after running gdb/copyright.py
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.
2022-01-01 19:13:23 +04:00
22589c4996 [gdb/testsuite] Fix gdb.guile/scm-type.exp with gcc 4.8
With gcc 7.5.0, I get:
...
(gdb) guile (print (type-range (field-type (type-field (value-type \
  (value-dereference f)) "items"))))^M
= (0 0)^M
(gdb) PASS: gdb.guile/scm-type.exp: lang_cpp: test_range: \
  on flexible array member: $cmd
...
but with gcc 4.8.5, I get instead:
...
(gdb) guile (print (type-range (field-type (type-field (value-type \
  (value-dereference f)) "items"))))^M
= (0 -1)^M
(gdb) FAIL: gdb.guile/scm-type.exp: lang_cpp: test_range: \
  on flexible array member: $cmd
...

There's a difference in debug info.  With gcc 4.8.5, we have:
...
 <2><224>: Abbrev Number: 15 (DW_TAG_member)
    <225>   DW_AT_name        : items
    <22b>   DW_AT_type        : <0x231>
 <1><231>: Abbrev Number: 4 (DW_TAG_array_type)
    <232>   DW_AT_type        : <0x105>
 <2><23a>: Abbrev Number: 16 (DW_TAG_subrange_type)
    <23b>   DW_AT_type        : <0x11a>
    <23f>   DW_AT_upper_bound : 0xffffffffffffffff
...
and with gcc 7.5.0, we have instead:
...
 <2><89f>: Abbrev Number: 12 (DW_TAG_member)
    <8a0>   DW_AT_name        : items
    <8a6>   DW_AT_type        : <0x8ac>
 <1><8ac>: Abbrev Number: 17 (DW_TAG_array_type)
    <8ad>   DW_AT_type        : <0x29d>
 <2><8b5>: Abbrev Number: 41 (DW_TAG_subrange_type)
 <2><8b6>: Abbrev Number: 0
...

As mentioned in commit 858c8f2c1b9 "gdb/testsuite: adjust
gdb.python/flexible-array-member.exp expected pattern":
...
Ideally, GDB would present a consistent and documented value for an
array member declared with size 0, regardless of how the debug info
looks like.
...

As in gdb.python/flexible-array-member.exp, change the test to accept the two
values.

Tested on x86_64-linux.
2021-10-07 18:00:08 +02:00
4dfef5be68 gdb/testsuite: make runto_main not pass no-message to runto
As follow-up to this discussion:

  https://sourceware.org/pipermail/gdb-patches/2020-August/171385.html

... make runto_main not pass no-message to runto.  This means that if we
fail to run to main, for some reason, we'll emit a FAIL.  This is the
behavior we want the majority of (if not all) the time.

Without this, we rely on tests logging a failure if runto_main fails,
otherwise.  They do so in a very inconsisteny mannet, sometimes using
"fail", "unsupported" or "untested".  The messages also vary widly.
This patch removes all these messages as well.

Also, remove a few "fail" where we call runto (and not runto_main).  by
default (without an explicit no-message argument), runto prints a
failure already.  In two places, gdb.multi/multi-re-run.exp and
gdb.python/py-pp-registration.exp, remove "message" passed to runto.
This removes a few PASSes that we don't care about (but FAILs will still
be printed if we fail to run to where we want to).  This aligns their
behavior with the rest of the testsuite.

Change-Id: Ib763c98c5f4fb6898886b635210d7c34bd4b9023
2021-09-30 15:27:39 -04:00
c173cc8a66 guile: fix smob exports
Before Guile v2.1 [1], calls to `scm_make_smob_type' implicitly added
the created class to the exports list of (oop goops); v2.1+ does not
implicitly create bindings in any modules. This means that the GDB
manual subsection documenting exported types is not quite right when GDB
is linked against Guile <v2.1 (types are exported from (oop goops))
instead of (gdb)) and incorrect when linked against Guile v2.1+ (types
are not bound to any variables at all!).

There is a range of cases in which it's necessary or convenient to be
able to refer to a GDB smob type, for instance:

 - Pattern matching based on the type of a value.
 - Defining GOOPS methods handling values from GDB (GOOPS methods
   typically use dynamic dispatch based on the types of the arguments).
 - Type-checking assertions when applying some defensive programming on
   an interface.
 - Generally any other situation one might encounter in a dynamically
   typed language that might need some introspection.

If you're more familiar with Python, it would be quite similar to being
unable to refer to the classes exported from the GDB module (which is to
say: not crippling for the most part, but makes certain tasks more
difficult than necessary).

This commit makes a small change to GDB's smob registration machinery
to make sure registered smobs get exported from the current
module. This will likely cause warnings to the user about conflicting
exports if they load both (gdb) and (oop goops) from a GDB linked
against Guile v2.0, but it shouldn't impact functionality (and seemed
preferable to trying to un-export bindings from (oop goops) if v2.0
was detected).

[1]: This changed with Guile commit
     28d0871b553a3959a6c59e2e4caec1c1509f8595

gdb/ChangeLog:

2021-06-07  George Barrett  <bob@bob131.so>

	* guile/scm-gsmob.c (gdbscm_make_smob_type): Export registered
	smob type from the current module.

gdb/testsuite/ChangeLog:

2021-06-07  George Barrett  <bob@bob131.so>

	* gdb.guile/scm-gsmob.exp (test exports): Add tests to make
	sure the smob types currently listed in the GDB manual get
	exported from the (gdb) module.

Change-Id: I7dcd791276b48dfc9edb64fc71170bbb42a6f6e7
2021-08-09 23:20:41 -04:00
b5b591a865 guile: fix make-value with pointer type
Calling the `make-value' procedure with an integer value and a pointer
type for the #:type argument triggers a failed assertion in
`get_unsigned_type_max', as that function doesn't consider pointers to
be an unsigned type. This commit fixes the issue by adding a separate
code path for pointers.

As previously suggested, range checking is done using a new helper
function in gdbtypes.

gdb/ChangeLog:

2021-07-30  George Barrett  <bob@bob131.so>

	* gdbtypes.h (get_pointer_type_max): Add declaration.
	* gdbtypes.c (get_pointer_type_max): Add definition for new
	helper function.
	* guile/scm-math.c (vlscm_convert_typed_number): Add code path
	for handling conversions to pointer types without failing an
	assert.

gdb/testsuite/ChangeLog:

2021-07-30  George Barrett  <bob@bob131.so>

	* gdb.guile/scm-math.exp (test_value_numeric_ops): Add test
	for creating pointers with make-value.
	(test_make_pointer_value, test_pointer_numeric_range): Add
	test procedures containing checks for integer-to-pointer
	validation.

Change-Id: I9994dd1c848840a3d995f745e6d72867732049f0
2021-07-29 12:55:16 -04:00
ad42014be2 Guile: temporary breakpoints
Adds API to the Guile bindings for creating temporary breakpoints and
querying whether an existing breakpoint object is temporary. This is
effectively a transliteration of the Python implementation.

It's worth noting that the added `is_temporary' flag is ignored in the
watchpoint registration path. This replicates the behaviour of the
Python implementation, but might be a bit surprising for users.

gdb/ChangeLog:

2021-06-09  George Barrett  <bob@bob131.so>

	* guile/scm-breakpoint.c (gdbscm_breakpoint_object::spec): Add
	is_temporary field.
	(temporary_keyword): Add keyword object for make-breakpoint
	argument parsing.
	(gdbscm_make_breakpoint): Accept #:temporary keyword argument
	and store the value in the allocated object's
	spec.is_temporary.
	(gdbscm_register_breakpoint_x): Pass the breakpoint's
	spec.is_temporary value to create_breakpoint.
	(gdbscm_breakpoint_temporary): Add breakpoint-temporary?
	procedure implementation.
	(breakpoint_functions::make-breakpoint): Update documentation
	string and fix a typo.
	(breakpoint_functions::breakpoint-temporary?): Add
	breakpoint-temporary? procedure.
	(gdbscm_initialize_breakpoints): Initialise temporary_keyword
	variable.
	NEWS (Guile API): Mention new temporary breakpoints API.

gdb/doc/ChangeLog:

2021-06-09  George Barrett  <bob@bob131.so>

	* guile.texi (Breakpoints In Guile): Update make-breakpoint
	documentation to reflect new #:temporary argument.
	Add documentation for new breakpoint-temporary? procedure.

gdb/testsuite/ChangeLog:

2021-06-09  George Barrett  <bob@bob131.so>

	* gdb.guile/scm-breakpoint.exp: Add additional tests for
	temporary breakpoints.

Change-Id: I2de332ee7c256f5591d7141ab3ad50d31b871d17
2021-07-28 20:30:24 -04:00
3e1e8561c3 gdb/testsuite: test get/set value of unregistered Guile parameter
When creating a parameter in Guile, you have to create it using
make-parameter and then register it with GDB with register-parameter!.
In between, it's still possible (though not documented) to set the
parameter's value.  I broke this use case by mistake while writing this
series, so thought it would be good to have a test for it.

I suppose that people could use this "feature" to give their parameter
an initial value, even though make-parameter has an initial-value
parameter for this.  Nevertheless, changing this behavior could break
some scripts, which is why I think it's important for it to be tested.

Change-Id: I5b2103e3cec0cfdcccf7ffb00eb05fed8626e66d
2021-07-23 15:38:54 -04:00
6bbe1a929c [gdb/testsuite] Fix gdb.guile/scm-breakpoint.exp with guile 3.0
When running test-case gdb.guile/scm-breakpoint.exp on openSUSE Tumbleweed
with guile 3.0, I run into:
...
(gdb) guile (define cp (make-breakpoint "syscall" #:type BP_CATCHPOINT))^M
ERROR: In procedure make-breakpoint:^M
In procedure gdbscm_make_breakpoint: unsupported breakpoint type in \
  position 3: "BP_CATCHPOINT"^M
Error while executing Scheme code.^M
(gdb) FAIL: gdb.guile/scm-breakpoint.exp: test_catchpoints: \
  create a catchpoint via the api
...

The same test passes on openSUSE Leap 15.2 with guile 2.0, where the second
line of the error message starts with the same prefix as the first:
...
ERROR: In procedure gdbscm_make_breakpoint: unsupported breakpoint type in \
  position 3: "BP_CATCHPOINT"^M
...

I observe the same difference in many other tests, f.i.:
...
(gdb) gu (print (value-add i '()))^M
ERROR: In procedure value-add:^M
In procedure gdbscm_value_add: Wrong type argument in position 2: ()^M
Error while executing Scheme code.^M
(gdb) PASS: gdb.guile/scm-math.exp: catch error in guile type conversion
...
but it doesn't cause FAILs anywhere else.

Fix this by updating the regexp to make the "ERROR: " prefix optional.

Tested on x86_64-linux, with both guile 2.0 and 3.0.

gdb/testsuite/ChangeLog:

2021-07-07  Tom de Vries  <tdevries@suse.de>

	* gdb.guile/scm-breakpoint.exp: Make additional "ERROR: " prefix in
	exception printing optional.
2021-07-08 09:57:34 +02:00
08080f9744 gdb/guile: allow for catchpoint type breakpoints in guile
This commit adds initial support for catchpoints to the guile
breakpoint API.

This commit adds a BP_CATCHPOINT constant which corresponds to
GDB's internal bp_catchpoint.  The new constant is documented in the
manual.

The user can't create breakpoints with type BP_CATCHPOINT after this
commit, but breakpoints that already exist, obtained with
the (breakpoints) function, can now have this type.

gdb/ChangeLog:

	* guile/scm-breakpoint.c (bpscm_type_to_string): Handle
	bp_catchpoint.
	(bpscm_want_scm_wrapper_p): Likewise.
	(gdbscm_make_breakpoint): Likewise.
	(breakpoint_integer_constants): Likewise.

gdb/doc/ChangeLog:

	* guile.texinfo (Breakpoints In Guile): Add BP_CATCHPOINT
	description.

gdb/testsuite/ChangeLog:

	* gdb.guile/scm-breakpoint.exp (test_catchpoints): New proc.
2021-06-25 18:22:05 +01:00
81b327aadd gdb/guile: improve the errors when creating breakpoints
When creating a breakpoint using the guile API, if an invalid
breakpoint type number was used then the error would report the wrong
argument position, like this:

  (gdb) guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type 999))
  ERROR: In procedure make-breakpoint:
  ERROR: In procedure gdbscm_make_breakpoint: Out of range: invalid breakpoint type in position 3: 999
  Error while executing Scheme code.
  (gdb)

The 'position 3' here is actually pointing at WP_WRITE, when it should
say 'position 5' and point to the 999.  This commit fixes this.

However, you also get errors like this:

  (gdb) guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type BP_NONE))
  ERROR: In procedure make-breakpoint:
  ERROR: In procedure gdbscm_make_breakpoint: Out of range: invalid breakpoint type in position 3: 0
  Error while executing Scheme code.

The BP_NONE is a valid breakpoint type, it's just not valid for
creating breakpoints through the 'make-breakpoint' API.  The use of
'0' in the error message (which is the value of BP_NONE) is not
great.  This commit changes the error in this case to:

  (gdb) guile (define wp2 (make-breakpoint "result" #:wp-class WP_WRITE #:type BP_NONE))
  ERROR: In procedure make-breakpoint:
  ERROR: In procedure gdbscm_make_breakpoint: unsupported breakpoint type in position 5: "BP_NONE"
  Error while executing Scheme code.

Which seems better; we now use the name of the type, and report that
this type is unsupported.

gdb/ChangeLog:

	* guile/scm-breakpoint.c (gdbscm_make_breakpoint): Split the error
	for invalid breakpoint numbers, and unsupported breakpoint
	numbers.

gdb/testsuite/ChangeLog:

	* gdb.guile/scm-breakpoint.exp (test_watchpoints): Add new tests.
2021-06-25 18:22:03 +01:00
d9211df246 gdb/testsuite: resolve duplicate test names in gdb.guile/*.exp
This commit:

  commit ecf25064e87a3d2d59871b3ea7126fa0dee0001d
  Date:   Thu May 13 15:42:20 2021 +0100

      gdb: fix pretty printing max depth behaviour

Introduced a couple of duplicate tests, this commit resolves them by
providing unique test names.

gdb/testsuite/ChangeLog:

	* gdb.guile/scm-pretty-print.exp: Add test names to resolve
	duplicate test names.
2021-05-19 13:41:00 +01:00
ecf25064e8 gdb: fix pretty printing max depth behaviour
The 'print max-depth' feature incorrectly causes GDB to skip printing
the string representation of pretty printed variables if the variable
is stored at a nested depth corresponding to the set max-depth value.
This change ensures that it is always printed before checking whether
the maximum print depth has been reached.

Regression tested with GCC 7.3.0 on x86_64, ppc64le, aarch64.

gdb/ChangeLog:

	* cp-valprint.c (cp_print_value): Replaced duplicate code.
	* guile/scm-pretty-print.c (ppscm_print_children): Check max_depth
	just before printing child values.
	(gdbscm_apply_val_pretty_printer): Don't check max_depth before
	printing string representation.
	* python/py-prettyprint.c (print_children): Check max_depth just
	before printing child values.
	(gdbpy_apply_val_pretty_printer): Don't check max_depth before
	printing string representation.

gdb/testsuite/ChangeLog:

	* gdb.python/py-format-string.c: Added a variable to test.
	* gdb.python/py-format-string.exp: Check string representation is
	printed at appropriate max_depth settings.
	* gdb.python/py-nested-maps.exp: Likewise.
	* gdb.guile/scm-pretty-print.exp: Add additional tests.
2021-05-14 06:51:21 +01:00
4a0a0bd20a gdb/testsuite: resolve remaining duplicate tests in gdb.guile/
The remaining duplicates are resolved by adding a with_test_prefix and
reindenting a proc.  I also added a couple of additional test names to
some of the tests.

gdb/testsuite/ChangeLog:

	* gdb.guile/scm-pretty-print.exp (run_lang_tests): Give some tests
	unique names, also wrap proc body in with_test_prefix.
2021-05-13 17:54:08 +01:00
62f2f198cd gdb/testsuite: resolve duplicate test names in gdb.guile/*.exp
This commit resolves almost all of the remaining duplicate test names
in gdb.guile/*.exp.  This is done by either:

 - Making use of with_test_prefix,
 - Giving tests a unique name,
 - Extending the existing name to make it unique,
 - Not printing PASS lines for simple setup commands (e.g. loading
   support modules, or adjusting GDB internal settings not relating to
   guile).

gdb/testsuite/ChangeLog:

	* gdb.guile/scm-frame-args.exp: Add with_test_prefix to resolve
	duplicate test names.
	* gdb.guile/scm-parameter.exp: Provide test names to avoid
	duplicate names based on the command being run.
	* gdb.guile/scm-symbol.exp: Extend test name to make it unique.
	* gdb.guile/scm-type.exp (restart_gdb): Don't print PASS line when
	loading a support module.
	(test_equality): Update test name to match the actual test, making
	the name unique in the process.
	* gdb.guile/scm-value.exp (test_value_in_inferior): Add test names
	to resolve duplicate tests.
	(test_inferior_function_call): Likewise.
	(test_subscript_regression): Likewise.
2021-05-13 17:53:39 +01:00
ee35ce8200 Guile: add value-const-value
The Guile API doesn't currently have an equivalent to the Python API's
gdb.Value.const_value(). This commit adds a procedure with equivalent
semantics to the Guile API.

gdb/ChangeLog:

	* NEWS (Guile API): Note the addition of the new procedure.
	* guile/scm-value.c (gdbscm_value_const_value): Add
	implementation of value-const-value procedure.
	(value_functions): Add value-const-value procedure.

gdb/doc/ChangeLog:

	* guile.texi (Values From Inferior In Guile): Add documentation
	for value-const-value.

gdb/testsuite/ChangeLog:

	* gdb.guile/scm-value.exp (test_value_in_inferior): Add test for
	value-const-value.
2021-05-12 12:35:36 +01:00
9d4fc61d41 Guile: add value-{rvalue-,}reference-value
The Guile API doesn't currently have an equivalent to the Python API's
Value.reference_value() or Value.rvalue_reference_value(). This commit
adds a procedure with equivalent semantics to the Guile API.

gdb/ChangeLog:

	* NEWS (Guile API): Note the addition of new procedures.
	* guile/scm-value.c (gdbscm_reference_value): Add helper function
	for reference value creation.
	(gdbscm_value_reference_value): Add implementation of
	value-reference-value procedure.
	(gdbscm_value_rvalue_reference_value): Add implementation of
	value-rvalue-reference-value procedure.
	(value_functions): Add value-reference-value procedure.  Add
	value-rvalue-reference-value procedure.

gdb/doc/ChangeLog:

	* guile.texi (Values From Inferior In Guile): Add documentation
	for value-reference-value.  Add documentation for
	value-rvalue-reference-value.

gdb/testsuite/ChangeLog:

	* gdb.guile/scm-value.exp (test_value_in_inferior): Add test for
	value-reference-value.  Add test for value-rvalue-reference-value.
2021-05-12 12:35:36 +01:00
9344937b04 gdb/testsuite: don't use source tree as temporary HOME directory
In this commit:

  commit 1845e254645efbc02248345ccdb557d265dd8ae1
  Date:   Wed May 5 16:50:17 2021 +0100

      gdb/guile: perform tilde expansion when sourcing guile scripts

A test was added that tries to source a guile script from the users
HOME directory.  In order to achieve this the test (temporarily)
modifies $HOME to point into the binutils-gdb source tree.

The problem with this is that sourcing a guile script can cause the
guile script to be byte compiled and written into a .cache/ directory,
which is stored .... in the $HOME directory.

The result was that the test added in the above commit would cause a
.cache/ directory to be added into the binutils-gdb source tree.

In this commit the test is updated to create a new directory in the
build tree, the file we want to source is copied over, and $HOME is
set to point at the location in the build tree.  Now when the test is
run the .cache/ directory is created in the build tree, leaving the
source tree untouched.

gdb/testsuite/ChangeLog:

	* gdb.guile/guile.exp: Don't use the source directory as a
	temporary HOME directory.
2021-05-10 17:56:16 +01:00
1845e25464 gdb/guile: perform tilde expansion when sourcing guile scripts
Before this patch:

  (gdb) source ~/script.scm
  ERROR: In procedure apply-smob/1:
  ERROR: In procedure primitive-load-path: Unable to find file "~/script.scm" in load path
  Error while executing Scheme code.
  (gdb)

This is because the path is not tilde expanded.  In contrast, when
sourcing a .py or .gdb script the path is tilde expanded.

This commit fixes this oversight, and allows the above source command
to work as expected.

The tilde expansion is done in the generic GDB code before we call the
sourcer function for any particular extension language.

gdb/ChangeLog:

	* cli/cli-cmds.c: Add 'gdbsupport/gdb_tilde_expand.h'
	include.
	(source_script_with_search): Perform tilde expansion.

gdb/testsuite/ChangeLog:

	* gdb.guile/guile.exp: Add an extra test.
2021-05-07 22:20:47 +01:00
0618ecf6eb gdb/guile: don't try to print location for watchpoints
Currently, using the guile API, if a user tries to print a breakpoint
object that represents a watchpoint, then GDB will crash.  For
example:

  (gdb) guile (use-modules (gdb))
  (gdb) guile (define wp1 (make-breakpoint "some_variable" #:type BP_WATCHPOINT #:wp-class WP_WRITE))
  (gdb) guile (register-breakpoint! wp1)
  (gdb) guile (display wp1) (newline)
  Aborted (core dumped)

This turns out to be because GDB calls event_location_to_string on the
breakpoints location, and watchpoint breakpoints don't have a
location.

This commit resolves the crash by just skipping the printing of the
location if the breakpoint doesn't have one.

Potentially, we could improve on this by printing details about what
the watchpoint is watching, however, I'm considering this a possible
future enhancement, this commit focuses just on having GDB not crash.

gdb/ChangeLog:

	* guile/scm-breakpoint.c (bpscm_print_breakpoint_smob): Only print
	breakpoint locations when the breakpoint actually has a location.

gdb/testsuite/ChangeLog:

	* gdb.guile/scm-breakpoint.exp (test_watchpoints): Print the
	watchpoint object before and after registering it with GDB.
2021-05-06 10:44:29 +01:00
a7ed4ea6af gdb/testsuite: use proc_with_prefix in gdb.guile/scm-breakpoint.exp
Convert gdb.guile/scm-breakpoint.exp to use proc_with_prefix instead
of using nested with_test_prefix calls.  Allows a level of indentation
to be removed from most of the test procs.

There were two procs that didn't use with_test_prefix, but I converted
them to be proc_with_prefix anyway, for consistency.

gdb/testsuite/ChangeLog:

	* gdb.guile/scm-breakpoint.exp (test_bkpt_basic): Convert to
	'proc_with_prefix', remove use of 'with_test_prefix', and
	reindent.
	(test_bkpt_deletion): Likewise.
	(test_bkpt_cond_and_cmds): Likewise.
	(test_bkpt_invisible): Likewise.
	(test_watchpoints): Likewise.
	(test_bkpt_internal): Likewise.
	(test_bkpt_eval_funcs): Likewise.
	(test_bkpt_registration): Likewise.
	(test_bkpt_address): Convert to 'proc_with_prefix'.
	(test_bkpt_probe): Likewise.
2021-05-06 10:44:28 +01:00
7ebbaa1c0a gdb/testsuite: resolve duplicate test names in gdb.guile/scm-breakpoint.exp
Extend some test names to avoid duplicates.

gdb/testsuite/ChangeLog:

	* gdb.guile/scm-breakpoint.exp (test_bkpt_basic): Extend test
	names to avoid duplicates.
	(test_bkpt_cond_and_cmds): Likewise.
	(test_bkpt_eval_funcs): Likewise.
2021-05-06 10:44:28 +01:00
e25d6d93c4 gdb: fix getting range of flexible array member in Python
As reported in bug 27757, we get an internal error when doing:

    $ cat test.c
    struct foo {
        int len;
        int items[];
    };

    struct foo *p;

    int main() {
        return 0;
    }
    $ gcc test.c -g -O0 -o test
    $ ./gdb -q -nx --data-directory=data-directory ./test -ex 'python gdb.parse_and_eval("p").type.target()["items"].type.range()'
    Reading symbols from ./test...
    /home/simark/src/binutils-gdb/gdb/gdbtypes.h:435: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    Quit this debugging session? (y or n)

This is because the Python code (typy_range) blindly reads the high
bound of the type of `items` as a constant value.  Since it is a
flexible array member, it has no high bound, the property is undefined.
Since commit 8c2e4e0689 ("gdb: add accessors to struct dynamic_prop"),
the getters check that you are not getting a property value of the wrong
kind, so this causes a failed assertion.

Fix it by checking if the property is indeed a constant value before
accessing it as such.  Otherwise, use 0.  This restores the previous GDB
behavior: because the structure was zero-initialized, this is what was
returned before.  But now this behavior is explicit and not accidental.

Add a test, gdb.python/flexible-array-member.exp, that is derived from
gdb.base/flexible-array-member.exp.  It tests the same things, but
through the Python API.  It also specifically tests getting the range
from the various kinds of flexible array member types (AFAIK it wasn't
possible to do the equivalent through the CLI).

gdb/ChangeLog:

	PR gdb/27757
	* python/py-type.c (typy_range): Check that bounds are constant
	before accessing them as such.
	* guile/scm-type.c (gdbscm_type_range): Likewise.

gdb/testsuite/ChangeLog:

	PR gdb/27757
	* gdb.python/flexible-array-member.c: New test.
	* gdb.python/flexible-array-member.exp: New test.
	* gdb.guile/scm-type.exp (test_range): Add test for flexible
	array member.
	* gdb.guile/scm-type.c (struct flex_member): New.
	(main): Use it.

Change-Id: Ibef92ee5fd871ecb7c791db2a788f203dff2b841
2021-04-22 15:01:28 -04:00
18b8df43bd gdb: Remove arm-symbianelf support
Since it has gone from bfd/.

	* arm-symbian-tdep.c: Delete.
	* NEWS: Mention arm-symbian removal.
	* Makefile.in: Remove arm-symbian-tdep entries.
	* configure.tgt: Remove arm*-*-symbianelf*.
	* doc/gdb.texinfo: Remove mention of SymbianOS.
	* osabi.c (gdb_osabi_names): Remove "Symbian".
	* osabi.h (enum gdb_osabi): Remove GDB_OSABI_SYMBIAN.
	* testsuite/gdb.base/ending-run.exp: Remove E32Main handling.
	* testsuite/gdb.ada/catch_ex_std.exp: Remove arm*-*-symbianelf*
	handling.
	* testsuite/gdb.base/dup-sect.exp: Likewise.
	* testsuite/gdb.base/long_long.exp: Likewise.
	* testsuite/gdb.base/solib-weak.exp: Likewise.
	* testsuite/gdb.guile/scm-section-script.exp: Likewise.
	* testsuite/gdb.python/py-section-script.exp: Likewise.
	* testsuite/lib/dwarf.exp: Likewise.
	* testsuite/lib/gdb.exp: Likewise.
2021-02-11 07:23:42 +10:30
3666a04883 Update copyright year range in all GDB files
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...

gdb/ChangeLog

        Update copyright year range in copyright header of all GDB files.
2021-01-01 12:12:21 +04:00
8abd8ee8c8 gdb/testsuite/: Use -qualified in runto_main / mi_runto_main
In some runtimes, there may be a "main" function in some class or
namespace.  The breakpoint created by runto_main may therefore have
unexpected locations on some other functions than the actual main.
These breakpoint locations can unexpectedly get hit during tests and
lead to failures.

I saw this while playing with AMD's ROCm toolchain -- I wrote a board
file to run the testsuite against device kernels.  There, the runtime
calls a "main" function before the device kernel code is reached:

 Thread 4 "bit_extract" hit Breakpoint 1, 0x00007ffeea140960 in lld:🧝:LinkerDriver::main(llvm::ArrayRef<char const*>) () from /opt/rocm/lib/libamd_comgr.so.1
 (gdb) bt
 #0  0x00007ffeea140960 in lld:🧝:LinkerDriver::main(llvm::ArrayRef<char const*>) () from /opt/rocm/lib/libamd_comgr.so.1
 #1  0x00007ffeea2257a5 in lld:🧝:link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&, llvm::raw_ostream&) () from /opt/rocm/lib/libamd_comgr.so.1
 #2  0x00007ffeea1bc374 in COMGR::linkWithLLD(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&) () from /opt/rocm/lib/libamd_comgr.so.1
 #3  0x00007ffeea1bfb09 in COMGR::InProcessDriver::execute(llvm::ArrayRef<char const*>) () from /opt/rocm/lib/libamd_comgr.so.1
 #4  0x00007ffeea1c4da9 in COMGR::AMDGPUCompiler::linkToExecutable() () from /opt/rocm/lib/libamd_comgr.so.1
 #5  0x00007ffeea1fde20 in dispatchCompilerAction(amd_comgr_action_kind_s, COMGR::DataAction*, COMGR::DataSet*, COMGR::DataSet*, llvm::raw_ostream&) () from /opt/rocm/lib/libamd_comgr.so.1
 #6  0x00007ffeea203a87 in amd_comgr_do_action () from /opt/rocm/lib/libamd_comgr.so.1
 ...

To avoid that, pass "qualified" to runto, in runto_main, so that
gdb_breakpoint ends up creating a breakpoint with -qualified.  This
avoids creating breakpoints locations for other unrelated "main"
functions.

Note: I first tried making runto itself use "-qualified", but that
caused regressions in the gdb.ada/ tests, which use runto without
specifying the whole fully-qualified function name (i.e., without the
package).  So I end up restricting the -qualified to
runto_main/mi_runto_main.

The gdb.base/ui-redirect.exp change is necessary because that testcase
is looking at what "save breakpoint" generates.

gdb/testsuite/ChangeLog:

	* gdb.base/ui-redirect.exp: Expect "break -qualified main" in
	saved breakpoints file.
	* gdb.guile/scm-breakpoint.exp: Expect "-qualified main" when
	inspecting breakpoint list.
	* lib/gdb.exp (runto_main): Add "qualified" to options.
	* lib/mi-support.exp (mi_runto_helper): Add 'qualified' parameter,
	and handle it.
	(mi_runto_main): Pass 1 as qualified argument.

Change-Id: I51468359ab0a518f05f7c0394c97f7e33b45fe69
2020-10-13 22:28:48 +01:00
50441f0f8c 'runto main' -> 'runto_main' throughout
This commit does 's/runto main/runto_main/g' throughout.

gdb/testsuite/ChangeLog:

	* gdb.ada/fun_in_declare.exp: Use "runto_main" instead of
	"runto main".
	* gdb.ada/small_reg_param.exp: Likewise.
	* gdb.arch/powerpc-d128-regs.exp: Likewise.
	* gdb.base/annota1.exp: Likewise.
	* gdb.base/anon.exp: Likewise.
	* gdb.base/breakpoint-in-ro-region.exp: Likewise.
	* gdb.base/dprintf-non-stop.exp: Likewise.
	* gdb.base/dprintf.exp: Likewise.
	* gdb.base/gdb11530.exp: Likewise.
	* gdb.base/gdb11531.exp: Likewise.
	* gdb.base/gnu_vector.exp: Likewise.
	* gdb.base/interrupt-noterm.exp: Likewise.
	* gdb.base/memattr.exp: Likewise.
	* gdb.base/step-over-syscall.exp: Likewise.
	* gdb.base/watch-cond-infcall.exp: Likewise.
	* gdb.base/watch-read.exp: Likewise.
	* gdb.base/watch-vfork.exp: Likewise.
	* gdb.base/watch_thread_num.exp: Likewise.
	* gdb.base/watchpoint-stops-at-right-insn.exp: Likewise.
	* gdb.guile/scm-frame-inline.exp: Likewise.
	* gdb.linespec/explicit.exp: Likewise.
	* gdb.opt/inline-break.exp: Likewise.
	* gdb.python/py-frame-inline.exp: Likewise.
	* gdb.reverse/break-precsave.exp: Likewise.
	* gdb.reverse/break-reverse.exp: Likewise.
	* gdb.reverse/consecutive-precsave.exp: Likewise.
	* gdb.reverse/consecutive-reverse.exp: Likewise.
	* gdb.reverse/finish-precsave.exp: Likewise.
	* gdb.reverse/finish-reverse.exp: Likewise.
	* gdb.reverse/fstatat-reverse.exp: Likewise.
	* gdb.reverse/getresuid-reverse.exp: Likewise.
	* gdb.reverse/i386-precsave.exp: Likewise.
	* gdb.reverse/i386-reverse.exp: Likewise.
	* gdb.reverse/i386-sse-reverse.exp: Likewise.
	* gdb.reverse/i387-env-reverse.exp: Likewise.
	* gdb.reverse/i387-stack-reverse.exp: Likewise.
	* gdb.reverse/insn-reverse.exp: Likewise.
	* gdb.reverse/machinestate-precsave.exp: Likewise.
	* gdb.reverse/machinestate.exp: Likewise.
	* gdb.reverse/pipe-reverse.exp: Likewise.
	* gdb.reverse/readv-reverse.exp: Likewise.
	* gdb.reverse/recvmsg-reverse.exp: Likewise.
	* gdb.reverse/rerun-prec.exp: Likewise.
	* gdb.reverse/s390-mvcle.exp: Likewise.
	* gdb.reverse/solib-precsave.exp: Likewise.
	* gdb.reverse/solib-reverse.exp: Likewise.
	* gdb.reverse/step-precsave.exp: Likewise.
	* gdb.reverse/step-reverse.exp: Likewise.
	* gdb.reverse/time-reverse.exp: Likewise.
	* gdb.reverse/until-precsave.exp: Likewise.
	* gdb.reverse/until-reverse.exp: Likewise.
	* gdb.reverse/waitpid-reverse.exp: Likewise.
	* gdb.reverse/watch-precsave.exp: Likewise.
	* gdb.reverse/watch-reverse.exp: Likewise.
	* gdb.threads/kill.exp: Likewise.
	* gdb.threads/tid-reuse.exp: Likewise.

Change-Id: I70f457253836019880b4d7fb981936afa56724c2
2020-10-13 22:27:43 +01:00
71e1b6b0ac Fix testcases with required but unreferenced functions and variables
A number of testcases define variables and/or functions which are
referenced by GDB during the test, but which are not referenced from
within the test executable.  Clang correctly recognizes that these
variables and functions are unused, and optimizes them out, causing
the testcases in question to fail.  This commit adds __attribute__
((used)) in various places to prevent this.

gdb/testsuite/ChangeLog:

	* gdb.base/msym-bp.c (foo): Add __attribute__ ((used)).
	* gdb.base/msym-bp-2.c (foo): Likewise.
	* gdb.base/msym-lang.c (foo): Likewise.
	* gdb.base/msym-lang-main.c (foo): Likewise.
	* gdb.base/symtab-search-order-1.c (static_global): Likewise.
	* gdb.guile/scm-pretty-print.c (eval_func): Likewise.
	* gdb.mi/mi-sym-info-1.c (global_f1): Likewise.
	* gdb.mi/mi-sym-info-2.c (global_f1, var1, var2): Likewise.
	* gdb.multi/watchpoint-multi-exit.c (globalvar): Likewise.
	* gdb.python/py-as-string.c (enum_valid, enum_invalid): Likewise.
	* gdb.python/py-objfile.c (static_var): Likewise.
	* gdb.python/py-symbol.c (rr): Likewise.
	* gdb.python/py-symbol-2.c (anon, rr): Likewise.
	* gdb.mi/mi-sym-info.exp (lineno1, lineno2): Updated.
2020-10-12 10:35:23 +01:00
ae5369e773 guile: Add support for Guile 3.0.
gdb/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

	* guile/scm-math.c (vlscm_integer_fits_p): Use 'uintmax_t'
	and 'intmax_t' instead of 'scm_t_uintmax' and 'scm_t_intmax',
	which are deprecated in Guile 3.0.
	* configure.ac (try_guile_versions): Add "guile-3.0".
	* configure (try_guile_versions): Regenerate.
	* NEWS: Update entry.

gdb/testsuite/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

	* gdb.guile/source2.scm: Add #f first argument to 'format'.
	* gdb.guile/types-module.exp: Remove "ERROR:" from
	regexps since Guile 3.0 no longer prints that.

gdb/doc/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

	* doc/guile.texi (Guile Introduction): Mention Guile 3.0.

Change-Id: Iff116c2e40f334e4e0ca4e759a097bfd23634679
2020-07-20 11:00:55 -04:00
68cf161c24 guile: Add support for Guile 2.2.
This primarily updates code that uses the I/O port API of Guile.

gdb/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>
            Doug Evans  <dje@google.com>

	PR gdb/21104
	* guile/scm-ports.c (USING_GUILE_BEFORE_2_2): New macro.
	(ioscm_memory_port)[read_buf_size, write_buf_size]: Wrap in #if
	USING_GUILE_BEFORE_2_2.
	(stdio_port_desc, memory_port_desc) [!USING_GUILE_BEFORE_2_2]:
	Change type to 'scm_t_port_type *'.
	(natural_buffer_size) [!USING_GUILE_BEFORE_2_2]: New variable.
	(ioscm_open_port) [USING_GUILE_BEFORE_2_2]: Add 'stream'
	parameter and honor it.  Update callers.
	(ioscm_open_port) [!USING_GUILE_BEFORE_2_2]: New function.
	(ioscm_read_from_port, ioscm_write) [!USING_GUILE_BEFORE_2_2]: New
	functions.
	(ioscm_fill_input, ioscm_input_waiting, ioscm_flush): Wrap in #if
	USING_GUILE_BEFORE_2_2.
	(ioscm_init_gdb_stdio_port) [!USING_GUILE_BEFORE_2_2]: Use
	'ioscm_read_from_port'.  Call 'scm_set_port_read_wait_fd'.
	(ioscm_init_stdio_buffers) [!USING_GUILE_BEFORE_2_2]: New function.
	(gdbscm_stdio_port_p) [!USING_GUILE_BEFORE_2_2]: Use 'SCM_PORTP'
	and 'SCM_PORT_TYPE'.
	(gdbscm_memory_port_end_input, gdbscm_memory_port_seek)
	(ioscm_reinit_memory_port): Wrap in #if USING_GUILE_BEFORE_2_2.
	(gdbscm_memory_port_read, gdbscm_memory_port_write)
	(gdbscm_memory_port_seek, gdbscm_memory_port_close)
	[!USING_GUILE_BEFORE_2_2]: New functions.
	(gdbscm_memory_port_print): Remove use of 'SCM_PTOB_NAME'.
	(ioscm_init_memory_port_type) [!USING_GUILE_BEFORE_2_2]: Use
	'gdbscm_memory_port_read'.
	Wrap 'scm_set_port_end_input', 'scm_set_port_flush', and
	'scm_set_port_free' calls in #if USING_GUILE_BEFORE_2_2.
	(gdbscm_get_natural_buffer_sizes) [!USING_GUILE_BEFORE_2_2]: New
	function.
	(ioscm_init_memory_port): Remove.
	(ioscm_init_memory_port_stream): New function
	(ioscm_init_memory_port_buffers) [USING_GUILE_BEFORE_2_2]: New
	function.
	(gdbscm_memory_port_read_buffer_size) [!USING_GUILE_BEFORE_2_2]:
	Return scm_from_uint (0).
	(gdbscm_set_memory_port_read_buffer_size_x)
	[!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'.
	(gdbscm_memory_port_write_buffer_size) [!USING_GUILE_BEFORE_2_2]:
	Return scm_from_uint (0).
	(gdbscm_set_memory_port_write_buffer_size_x)
	[!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'.
	* configure.ac (try_guile_versions): Add "guile-2.2".
	* configure: Regenerate.
	* NEWS: Add entry.

gdb/testsuite/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

	* gdb.guile/scm-error.exp ("source $remote_guile_file_1"): Relax
	error regexp to match on Guile 2.2.

gdb/doc/ChangeLog
2020-06-28  Ludovic Courtès  <ludo@gnu.org>

	* guile.texi (Memory Ports in Guile): Mark
	'memory-port-read-buffer-size',
	'set-memory-port-read-buffer-size!',
	'memory-port-write-buffer-size',
	'set-memory-port-read-buffer-size!' as deprecated.
	* doc/guile.texi (Guile Introduction): Clarify which Guile
	versions are supported.

Change-Id: Ib119b10a2787446e0ae482a5e1b36d809c44bb31
2020-07-20 10:59:47 -04:00
746ebfe8dd Add tests for new alias default-args related commands and arguments.
Test the new default-args behaviour and completion for the alias command.
Note that gdb.base/default-args.exp is somewhat copied from
with.exp (the test of the with command), while default-exp.c
is a plain copy of with.c.

gdb/testsuite/ChangeLog
2020-06-22  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

	* gdb.base/default-args.exp: New test.
	* gdb.base/default-args.c: New file.
	* gdb.base/alias.exp: Update expected error msg for alias foo=bar.
	* gdb.base/default.exp: Update to new help text.
	* gdb.base/help.exp: Likewise.
	* gdb.base/page.exp: Likewise.
	* gdb.base/style.exp: Likewise.
	* gdb.guile/guile.exp: Likewise.
	* gdb.python/python.exp: Likewise.
2020-06-22 21:15:14 +02:00
6e4e3fe1b6 [gdb/testsuite] Add xfails for PR gcc/90232
With target board debug-types, we have these FAILs:
...
FAIL: gdb.guile/scm-symtab.exp: test simple_struct in static symbols
FAIL: gdb.python/py-symtab.exp: test simple_struct in static symbols
...
due to PR gcc/90232, as explained in commit 15cd93d05e8 "[gdb/symtab] Handle
struct decl with DW_AT_signature".

Marks these as XFAILs.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2020-04-29  Tom de Vries  <tdevries@suse.de>

	* lib/gdb.exp (debug_types): New proc.
	* gdb.guile/scm-symtab.exp: Add xfail for PR gcc/90232.
	* gdb.python/py-symtab.exp: Same.
2020-04-29 13:22:21 +02:00
bcfe6157ca Use the linkage name if it exists
The DWARF reader has had some odd code since the "physname" patches landed.

In particular, these patches caused PR symtab/12707; namely, they made
it so "set print demangle off" no longer works.

This patch attempts to fix the problem.  It arranges to store the
linkage name on the symbol if it exists, and it changes the DWARF
reader so that the demangled name is no longer (usually) stored in the
symbol's "linkage name" field.

c-linkage-name.exp needed a tweak, because it started working
correctly.  This conforms to what I think ought to happen, so this
seems like an improvement here.

compile-object-load.c needed a small change to use
symbol_matches_search_name rather than directly examining the linkage
name.  Looking directly at the name does the wrong thing for C++.

There is still some name-related confusion in the DWARF reader:

* "physname" often refers to the logical name and not what I would
  consider to be the "physical" name;

* dwarf2_full_name, dwarf2_name, and dwarf2_physname all exist and
  return different strings -- but this seems like at least one name
  too many.  For example, Fortran requires dwarf2_full_name, but other
  languages do not.

* To my surprise, dwarf2_physname prefers the form emitted by the
  demangler over the one that it computes.  This seems backward to me,
  given that the partial symbol reader prefers the opposite, and it
  seems to me that this choice may perform better as well.

I didn't attempt to clean up these things.  It would be good to do,
but whenever I contemplate it I get caught up in dreams of truly
rewriting the DWARF reader instead.

gdb/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

	PR symtab/12707:
	* dwarf2/read.c (add_partial_symbol): Use the linkage name if it
	exists.
	(new_symbol): Likewise.
	* compile/compile-object-load.c (get_out_value_type): Use
	symbol_matches_search_name.

gdb/testsuite/ChangeLog
2020-04-24  Tom Tromey  <tom@tromey.com>

	PR symtab/12707:
	* gdb.python/py-symbol.exp: Update expected results for
	linkage_name test.
	* gdb.cp/print-demangle.exp: New file.
	* gdb.base/c-linkage-name.exp: Fix test.
	* gdb.guile/scm-symbol.exp: Update expected results for
	linkage_name test.
2020-04-24 15:35:03 -06:00
121b3efd49 Add "info connections" command, "info inferiors" connection number/string
This commit extends the CLI a bit for multi-target, in three ways.

#1 - New "info connections" command.

This is a new command that lists the open connections (process_stratum
targets).  For example, if you're debugging two remote connections, a
couple local/native processes, and a core dump, all at the same time,
you might see something like this:

 (gdb) info connections
   Num  What                     Description
   1    remote 192.168.0.1:9999  Remote serial target in gdb-specific protocol
   2    remote 192.168.0.2:9998  Remote serial target in gdb-specific protocol
 * 3    native                   Native process
   4    core                     Local core dump file

#2 - New "info inferiors" "Connection" column

You'll also see a new matching "Connection" column in "info
inferiors", showing you which connection an inferior is bound to:

 (gdb) info inferiors
   Num  Description       Connection                   Executable
   1    process 18526     1 (remote 192.168.0.1:9999)  target:/tmp/a.out
   2    process 18531     2 (remote 192.168.0.2:9998)  target:/tmp/a.out
   3    process 19115     3 (native)                   /tmp/prog1
   4    process 6286      4 (core)                     myprogram
 * 5    process 19122     3 (native)                   /bin/hello

#3 - Makes "add-inferior" show the inferior's target connection

"add-inferior" now shows you the connection you've just bound the
inferior to, which is the current process_stratum target:

 (gdb) add-inferior
 [New inferior 2]
 Added inferior 2 on connection 1 (extended-remote localhost:2346)

gdb/ChangeLog:
2020-01-10  Pedro Alves  <palves@redhat.com>

	* Makefile.in (COMMON_SFILES): Add target-connection.c.
	* inferior.c (uiout_field_connection): New function.
	(print_inferior): Add new "connection-id" column.
	(add_inferior_command): Show connection number/string of added
	inferior.
	* process-stratum-target.h
	(process_stratum_target::connection_string): New virtual method.
	(process_stratum_target::connection_number): New field.
	* remote.c (remote_target::connection_string): New override.
	* target-connection.c: New file.
	* target-connection.h: New file.
	* target.c (decref_target): Remove process_stratum targets from
	the connection list.
	(target_stack::push): Add process_stratum targets to the
	connection list.

gdb/testsuite/ChangeLog:
2020-01-10  Pedro Alves  <palves@redhat.com>

	* gdb.base/kill-detach-inferiors-cmd.exp: Adjust expected output
	of "add-inferior".
	* gdb.base/quit-live.exp: Likewise.
	* gdb.base/remote-exec-file.exp: Likewise.
	* gdb.guile/scm-progspace.exp: Likewise.
	* gdb.linespec/linespec.exp: Likewise.
	* gdb.mi/new-ui-mi-sync.exp: Likewise.
	* gdb.mi/user-selected-context-sync.exp: Likewise.
	* gdb.multi/multi-target.exp (setup): Add "info connection" and
	"info inferiors" tests.
	* gdb.multi/remove-inferiors.exp: Adjust expected output of
	"add-inferior".
	* gdb.multi/watchpoint-multi.exp: Likewise.
	* gdb.python/py-inferior.exp: Likewise.
	* gdb.server/extended-remote-restart.exp: Likewise.
	* gdb.threads/fork-plus-threads.exp: Adjust expected output of
	"info inferiors".
	* gdb.threads/forking-threads-plus-breakpoint.exp: Likewise.
	* gdb.trace/report.exp: Likewise.
2020-01-10 20:06:14 +00:00
b811d2c292 Update copyright year range in all GDB files.
gdb/ChangeLog:

        Update copyright year range in all GDB files.
2020-01-01 10:20:53 +04:00
bac7c5cf92 Fix scripted probe breakpoints
The documentation for make-breakpoint from the Guile API and the `spec'
variant of the gdb.Breakpoint constructor from the Python API state that
the format acceptable for location strings is the same as that accepted
by the break command. However, using the -probe qualifier at the
beginning of the location string causes a GDB internal error as it
attempts to decode a probe location in the wrong code path. Without this
functionality, there doesn't appear to be another way to set breakpoints
on probe points from Python or Guile scripts.

This patch introduces a new helper function that returns a
breakpoint_ops instance appropriate for a parsed location and updates
the Guile and Python bindings to use said function, rather than the
current hard-coded use of bkpt_breakpoint_ops. Since this logic is
duplicated in the handling of the `break' and `trace' commands, those
are also updated to call into the new helper function.

gdb/ChangeLog:
2019-12-10  George Barrett  <bob@bob131.so>

	Fix scripted probe breakpoints.
	* breakpoint.c (tracepoint_probe_breakpoint_ops): Move
	declaration forward.
	(breakpoint_ops_for_event_location_type)
	(breakpoint_ops_for_event_location): Add function definitions.
	(break_command_1, trace_command): Use
	breakpoint_ops_for_event_location.
	* breakpoint.h (breakpoint_ops_for_event_location): Add function
	declarations.
	* guile/scm-breakpoint.c (gdbscm_register_breakpoint_x): Use
	breakpoint_ops_for_event_location.
	* python/py-breakpoint.c (bppy_init): Use
	breakpoint_ops_for_event_location.

gdb/testsuite/ChangeLog:
2019-12-10  George Barrett  <bob@bob131.so>

	Test scripted probe breakpoints.
	* gdb.guile/scm-breakpoint.c (main): Add probe point.
	* gdb.python/py-breakpoint.c (main): Likewise.
	* gdb.guile/scm-breakpoint.exp (test_bkpt_probe): Add probe
	specifier test.
	* gdb.python/py-breakpoint.exp (test_bkpt_probe): Likewise.
2019-12-09 16:51:33 -05:00
d1e36019c1 [gdb/testsuite] Remove superfluous 3rd argument from gdb_test call (2)
There's a pattern:
...
gdb_test <command> <pattern> <command>
...
that can be written shorter as:
...
gdb_test <command> <pattern>
...

Detect this pattern in proc gdb_test:
...
     global gdb_prompt
     upvar timeout timeout

     if [llength $args]>2 then {
        set message [lindex $args 2]
+       if { $message == [lindex $args 0] && [llength $args] == 3 } {
+           error "HERE"
+       }
     } else {
         set message [lindex $args 0]
     }
...
and fix all occurrences in some gdb testsuite subdirs.

Tested on x86_64-linux.

gdb/testsuite/ChangeLog:

2019-10-31  Tom de Vries  <tdevries@suse.de>

	* gdb.arch/amd64-disp-step-avx.exp: Drop superfluous 3rd argument to
	gdb_test.
	* gdb.arch/amd64-disp-step.exp: Same.
	* gdb.asm/asm-source.exp: Same.
	* gdb.btrace/buffer-size.exp: Same.
	* gdb.btrace/cpu.exp: Same.
	* gdb.btrace/enable.exp: Same.
	* gdb.dwarf2/count.exp: Same.
	* gdb.dwarf2/dw2-ranges-func.exp: Same.
	* gdb.dwarf2/dw2-ranges-psym.exp: Same.
	* gdb.fortran/vla-datatypes.exp: Same.
	* gdb.fortran/vla-history.exp: Same.
	* gdb.fortran/vla-ptype.exp: Same.
	* gdb.fortran/vla-value.exp: Same.
	* gdb.fortran/whatis_type.exp: Same.
	* gdb.guile/guile.exp: Same.
	* gdb.multi/tids.exp: Same.
	* gdb.python/py-finish-breakpoint.exp: Same.
	* gdb.python/py-framefilter.exp: Same.
	* gdb.python/py-pp-registration.exp: Same.
	* gdb.python/py-xmethods.exp: Same.
	* gdb.python/python.exp: Same.
	* gdb.server/connect-with-no-symbol-file.exp: Same.
	* gdb.server/no-thread-db.exp: Same.
	* gdb.server/run-without-local-binary.exp: Same.
	* gdb.stabs/weird.exp: Same.
	* gdb.threads/attach-many-short-lived-threads.exp: Same.
	* gdb.threads/thread-find.exp: Same.
	* gdb.threads/tls-shared.exp: Same.
	* gdb.threads/tls.exp: Same.
	* gdb.threads/wp-replication.exp: Same.
	* gdb.trace/ax.exp: Same.
	* lib/gdb.exp (gdb_test_exact, help_test_raw): Same.

Change-Id: I2fa544c68f8c0099a77e03ff04ddc010eb2b6c7c
2019-10-31 23:03:25 +01:00
2daf894ed0 "set print raw frame-arguments" -> "set print raw-frame-arguments"
A following patch will introduce options for the "backtrace" command,
based on some "set print" and "set backtrace" settings.  There's one
setting in particular that is a bit annoying if we want to describe
the backtrace options and the settings commands using the same data
structures:

  "set print raw frame-arguments"

The problem is that space between "raw" and "frame-arguments".

Calling the option

  "bt -raw frame-arguments"

would be odd.  So I'm calling the option

  "bt -raw-frame-arguments"

instead.

And for consistency, this patch renames the set/show commands to:

 "set print raw-frame-arguments"
 "show print raw-frame-arguments"

I.e., dash instead of space.  The old commands are left in place, but
marked deprecated.

We need to adjust a couple testcases, because the relevant tests use
gdb_test_no_output and the old commands are no longer silent:

  (gdb) set print raw frame-arguments on
  Warning: command 'set print raw frame-arguments' is deprecated.
  Use 'set print raw-frame-arguments'.

gdb/ChangeLog:
2019-06-13  Pedro Alves  <palves@redhat.com>

	* NEWS (Changed commands): Mention set/show print raw-frame-arguments,
	and that "set/show print raw frame-arguments" are now deprecated.

	* cli/cli-decode.c (add_setshow_boolean_cmd): Now returns the
	command.
	* command.h (add_setshow_boolean_cmd): Return cmd_list_element *.
	* stack.c (_initialize_stack): Install "set/show print
	raw-frame-arguments", and deprecate "set/show print raw
	frame-arguments".
	* valprint.c (_initialize_valprint): Deprecate "set/show print
	raw".

gdb/doc/ChangeLog:
2019-06-13  Pedro Alves  <palves@redhat.com>

	* gdb.texinfo (Print Settings): Document "set/show print
	raw-frame-arguments" instead of "set/show print raw
	frame-arguments".

gdb/testsuite/ChangeLog:
2019-06-13  Pedro Alves  <palves@redhat.com>

	* gdb.guile/scm-frame-args.exp: Use "set print
	raw-frame-arguments" instead of "set print raw frame-arguments".
	* gdb.python/py-frame-args.exp: Likewise.
2019-06-13 00:18:41 +01:00