binutils-gdb/gdb/testsuite/gdb.ada/info_auto_lang.exp

158 lines
5.2 KiB
Plaintext
Raw Normal View History

# Copyright 2018-2021 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
load_lib "ada.exp"
Add skip_ada_tests to more Ada testcases This adds missing skip_ada_tests checks to Ada testcases, using the exact same pattern the existing files that do check it use. gdb/testsuite/ChangeLog: * gdb.ada/access_tagged_param.exp: Check skip_ada_tests. * gdb.ada/access_to_packed_array.exp: Likewise. * gdb.ada/access_to_unbounded_array.exp: Likewise. * gdb.ada/addr_arith.exp: Likewise. * gdb.ada/arr_acc_idx_w_gap.exp: Likewise. * gdb.ada/arr_arr.exp: Likewise. * gdb.ada/arr_enum_idx_w_gap.exp: Likewise. * gdb.ada/array_bounds.exp: Likewise. * gdb.ada/array_of_variable_length.exp: Likewise. * gdb.ada/array_ptr_renaming.exp: Likewise. * gdb.ada/array_subscript_addr.exp: Likewise. * gdb.ada/arraydim.exp: Likewise. * gdb.ada/arrayparam.exp: Likewise. * gdb.ada/arrayptr.exp: Likewise. * gdb.ada/assign_1.exp: Likewise. * gdb.ada/assign_arr.exp: Likewise. * gdb.ada/atomic_enum.exp: Likewise. * gdb.ada/attr_ref_and_charlit.exp: Likewise. * gdb.ada/bad-task-bp-keyword.exp: Likewise. * gdb.ada/bias.exp: Likewise. * gdb.ada/boolean_expr.exp: Likewise. * gdb.ada/bp_c_mixed_case.exp: Likewise. * gdb.ada/bp_enum_homonym.exp: Likewise. * gdb.ada/bp_inlined_func.exp: Likewise. * gdb.ada/bp_on_var.exp: Likewise. * gdb.ada/bp_range_type.exp: Likewise. * gdb.ada/bp_reset.exp: Likewise. * gdb.ada/call_pn.exp: Likewise. * gdb.ada/catch_assert_if.exp: Likewise. * gdb.ada/catch_ex.exp: Likewise. * gdb.ada/catch_ex_std.exp: Likewise. * gdb.ada/char_enum.exp: Likewise. * gdb.ada/char_param.exp: Likewise. * gdb.ada/complete.exp: Likewise. * gdb.ada/cond_lang.exp: Likewise. * gdb.ada/convvar_comp.exp: Likewise. * gdb.ada/dgopt.exp: Likewise. * gdb.ada/disc_arr_bound.exp: Likewise. * gdb.ada/display_nested.exp: Likewise. * gdb.ada/dot_all.exp: Likewise. * gdb.ada/dyn_loc.exp: Likewise. * gdb.ada/dyn_stride.exp: Likewise. * gdb.ada/excep_handle.exp: Likewise. * gdb.ada/expr_delims.exp: Likewise. * gdb.ada/expr_with_funcall.exp: Likewise. * gdb.ada/exprs.exp: Likewise. * gdb.ada/fin_fun_out.exp: Likewise. * gdb.ada/fixed_cmp.exp: Likewise. * gdb.ada/formatted_ref.exp: Likewise. * gdb.ada/frame_arg_lang.exp: Likewise. * gdb.ada/frame_args.exp: Likewise. * gdb.ada/fullname_bp.exp: Likewise. * gdb.ada/fun_addr.exp: Likewise. * gdb.ada/fun_in_declare.exp: Likewise. * gdb.ada/fun_overload_menu.exp: Likewise. * gdb.ada/fun_renaming.exp: Likewise. * gdb.ada/funcall_char.exp: Likewise. * gdb.ada/funcall_param.exp: Likewise. * gdb.ada/funcall_ptr.exp: Likewise. * gdb.ada/funcall_ref.exp: Likewise. * gdb.ada/homonym.exp: Likewise. * gdb.ada/info_addr_mixed_case.exp: Likewise. * gdb.ada/info_auto_lang.exp: Likewise. * gdb.ada/info_exc.exp: Likewise. * gdb.ada/info_types.exp: Likewise. * gdb.ada/int_deref.exp: Likewise. * gdb.ada/interface.exp: Likewise. * gdb.ada/iwide.exp: Likewise. * gdb.ada/lang_switch.exp: Likewise. * gdb.ada/length_cond.exp: Likewise. * gdb.ada/maint_with_ada.exp: Likewise. * gdb.ada/mi_catch_assert.exp: Likewise. * gdb.ada/mi_catch_ex.exp: Likewise. * gdb.ada/mi_catch_ex_hand.exp: Likewise. * gdb.ada/mi_dyn_arr.exp: Likewise. * gdb.ada/mi_ex_cond.exp: Likewise. * gdb.ada/mi_exc_info.exp: Likewise. * gdb.ada/mi_interface.exp: Likewise. * gdb.ada/mi_prot.exp: Likewise. * gdb.ada/mi_ref_changeable.exp: Likewise. * gdb.ada/mi_string_access.exp: Likewise. * gdb.ada/mi_task_arg.exp: Likewise. * gdb.ada/mi_task_info.exp: Likewise. * gdb.ada/mi_var_array.exp: Likewise. * gdb.ada/mi_var_union.exp: Likewise. * gdb.ada/mi_variant.exp: Likewise. * gdb.ada/minsyms.exp: Likewise. * gdb.ada/mod_from_name.exp: Likewise. * gdb.ada/nested.exp: Likewise. * gdb.ada/null_array.exp: Likewise. * gdb.ada/optim_drec.exp: Likewise. * gdb.ada/out_of_line_in_inlined.exp: Likewise. * gdb.ada/packed_array_assign.exp: Likewise. * gdb.ada/packed_tagged.exp: Likewise. * gdb.ada/pp-rec-component.exp: Likewise. * gdb.ada/print_chars.exp: Likewise. * gdb.ada/print_pc.exp: Likewise. * gdb.ada/ptr_typedef.exp: Likewise. * gdb.ada/ptype_arith_binop.exp: Likewise. * gdb.ada/ptype_array.exp: Likewise. * gdb.ada/ptype_field.exp: Likewise. * gdb.ada/ptype_tagged_param.exp: Likewise. * gdb.ada/ptype_union.exp: Likewise. * gdb.ada/py_range.exp: Likewise. * gdb.ada/py_taft.exp: Likewise. * gdb.ada/rdv_wait.exp: Likewise. * gdb.ada/rec_comp.exp: Likewise. * gdb.ada/rec_return.exp: Likewise. * gdb.ada/ref_param.exp: Likewise. * gdb.ada/ref_tick_size.exp: Likewise. * gdb.ada/rename_subscript_param.exp: Likewise. * gdb.ada/repeat_dyn.exp: Likewise. * gdb.ada/same_component_name.exp: Likewise. * gdb.ada/same_enum.exp: Likewise. * gdb.ada/scalar_storage.exp: Likewise. * gdb.ada/set_wstr.exp: Likewise. * gdb.ada/small_reg_param.exp: Likewise. * gdb.ada/str_binop_equal.exp: Likewise. * gdb.ada/str_ref_cmp.exp: Likewise. * gdb.ada/str_uninit.exp: Likewise. * gdb.ada/sub_variant.exp: Likewise. * gdb.ada/sym_print_name.exp: Likewise. * gdb.ada/taft_type.exp: Likewise. * gdb.ada/tagged.exp: Likewise. * gdb.ada/tagged_access.exp: Likewise. * gdb.ada/task_bp.exp: Likewise. * gdb.ada/task_switch_in_core.exp: Likewise. * gdb.ada/tasks.exp: Likewise. * gdb.ada/tick_last_segv.exp: Likewise. * gdb.ada/tick_length_array_enum_idx.exp: Likewise. * gdb.ada/type_coercion.exp: Likewise. * gdb.ada/unc_arr_ptr_in_var_rec.exp: Likewise. * gdb.ada/unchecked_union.exp: Likewise. * gdb.ada/uninitialized_vars.exp: Likewise. * gdb.ada/var_arr_attrs.exp: Likewise. * gdb.ada/var_arr_typedef.exp: Likewise. * gdb.ada/var_rec_arr.exp: Likewise. * gdb.ada/variant-record.exp: Likewise. * gdb.ada/variant.exp: Likewise. * gdb.ada/variant_record_packed_array.exp: Likewise. * gdb.ada/varsize_limit.exp: Likewise. * gdb.ada/whatis_array_val.exp: Likewise. * gdb.ada/widewide.exp: Likewise. * gdb.ada/win_fu_syms.exp: Likewise.
2020-08-14 00:34:21 +08:00
if { [skip_ada_tests] } { return -1 }
# This test verifies that the commands
# info [functions|variables|types]
# respect the 'set language auto|ada|c' setting, whatever the language
# of the current frame.
# Similarly, checks that rbreak reports its results respecting
# the language mode.
standard_ada_testfile proc_in_ada
set cfile "some_c"
Ensure deterministic result order in gdb.ada/info_auto_lang.exp standard_ada_testfile, standard_test_file and the explicit csrcfile assignment in info_auto_lang.exp all gives similar pathnames prefix for a source, such as /home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.<something>. Note that the above pathnames contain ../ which appears when a relative pathname is used to call configure. In any case, the gnat compiler normalizes Ada sources path when compiling. So, the 'Ada' .o object are referencing a pathname such as /home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/info_auto_lang/proc_in_ada.adb, while the 'C' .o object still references the not normalized pathname. As the results of 'info functions | ...' are sorted by pathname first, the order of the results depends on the comparison between different directories, leading to results that can change depending on these directories. => Ensure the result order is always the same, by normalising the C source file, which makes the results independent of the way configure is launched. Tested by running the testcase in 2 different builds, that without normalize were giving different results. Note: such 'set csrcfile' is used in 4 other tests mixing Ada and C. After discussion, it was deemed sufficient to just normalize the pathname for this test. gdb/testsuite/ChangeLog 2018-12-20 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/info_auto_lang.exp: Normalize some_c source file. Update order of results accordingly.
2018-12-01 21:10:10 +08:00
# gnat normalizes proc_in_ada source file when compiling.
# As the 'info' commands results are sorted by absolute path names, also normalize
# the some_c source file to ensure that the 'info' results are always
# giving Ada results first.
set csrcfile [file normalize ${srcdir}/${subdir}/${testdir}/${cfile}.c]
set cobject [standard_output_file ${cfile}.o]
if { [gdb_compile "${csrcfile}" "${cobject}" object [list debug]] != "" } {
untested "failed to compile"
return -1
}
if {[gdb_compile_ada "${srcfile}" "${binfile}" executable [list debug]] != "" } {
untested "failed to compile"
return -1
}
clean_restart ${testfile}
set bp_location [gdb_get_line_number "STOP" ${testdir}/some_c.c]
if ![runto "some_c.c:$bp_location"] then {
fail "can't run to some_c.c STOP location"
return
}
set func_in_c(c_syntax) "${decimal}: void proc_in_c\\\(void\\\);"
set func_in_c(ada_syntax) "${decimal}: procedure proc_in_c;"
set func_in_ada(c_syntax) "${decimal}: void proc_in_ada\\\(void\\\);"
set func_in_ada(ada_syntax) "${decimal}: procedure proc_in_ada;"
gdb: Show type summary for anonymous structures from c_print_typedef Currently each language has a la_print_typedef method, this is only used for the "info types" command. The documentation for "info types" says: Print a brief description of all types whose names match the regular expression @var{regexp} (or all types in your program, if you supply no argument). However, if we consider this C code: typedef struct { int a; } my_type; Then currently with "info types" this will be printed like this: 3: typedef struct { int a; } my_type; I see two problems with this, first the indentation is clearly broken, second, if the struct contained more fields then it feels like the actual type names could easily get lost in the noise. Given that "info types" is about discovering type names, I think there is an argument to be made that we should focus on giving _only_ the briefest summary for "info types", and if the user wants to know more they can take the type name and plug it into "ptype". As such, I propose that a better output would be: 3: typedef struct {...} my_type; The user understands that there is a type called `my_type`, and that it's an alias for an anonymous structure type. The change to achieve this turns out to be pretty simple, but only effects languages that make use of c_print_typedef, which are C, C++, asm, minimal, d, go, objc, and opencl. Other languages will for now do whatever they used to do. The patch to change how anonymous structs are displayed also changes the display of anonymous enums, consider this code sample: typedef enum { AA, BB, CC } anon_enum_t; This used to be displayed like this: 3: typedef enum {AA, BB, CC} anon_enum_t; Which will quickly become cluttered for enums with a large number of values. The modified output looks like this: 3: typedef enum {...} anon_enum_t; Again, the user can always make use of ptype if they want to see the details of the anon_enum_t type. It is worth pointing out that this change (to use {...}) only effects anonymous structs and enums, named types don't change with this patch, consider this code: struct struct_t { int i; }; enum enum_t { AA, BB, CC }; The output from 'info types' remains unchanged, like this: 4: enum enum_t; 1: struct struct_t; An additional area of interest is how C++ handles anonymous types used within a typedef; enums are handled basically inline with how C handles them, but structs (and classes) are slightly different. The behaviour before the patch is different, and is unchanged by this patch. Consider this code compiled for C++: typedef struct { int i; } struct_t; Both before and after this patch, this is show by 'info types' as: 3: typedef struct_t struct_t; Unions are displayed similarly to structs in both C and C++, the handling of anonymous unions changes for C in the same way that it changes for anonymous structs. I did look at ada, as this is the only language to actually have some tests for "info types", however, as I understand it ada doesn't really support typedefs, however, by forcing the language we can see what ada would print. So, if we 'set language ada', then originally we printed this: 3: record a: int; end record Again the indentation is clearly broken, but we also have no mention of the type name at all, which is odd, but understandable given the lack of typedefs. If I make a similar change as I'm proposing for C, then we now get this output: 3: record ... end record Which is even less informative I think. However, the original output _is_ tested for in gdb.ada/info_auto_lang.exp, and its not clear to me if the change is a good one or not, so for now I have left this out. gdb/ChangeLog: * c-typeprint.c (c_print_typedef): Pass -1 instead of 0 to type_print. gdb/testsuite/ChangeLog: * gdb.ada/info_auto_lang.exp: Update expected results. * gdb.base/info-types.c: Add additional types to check. * gdb.base/info-types.exp: Update expected results.
2019-07-12 18:26:32 +08:00
set type_in_c(c_syntax) "${decimal}: typedef struct {\\.\\.\\.} some_type_in_c;"
set type_in_c(ada_syntax) [multi_line \
"${decimal}: record" \
" some_component_in_c: int;" \
"end record" ]
set type_in_ada(c_syntax) "${decimal}: struct global_pack__some_type_in_ada;"
set type_in_ada(ada_syntax) "${decimal}: global_pack.some_type_in_ada;"
set var_in_c(c_syntax) "${decimal}: some_type_in_c some_struct_in_c;"
set var_in_c(ada_syntax) "${decimal}: some_struct_in_c: some_type_in_c;"
set var_in_ada(c_syntax) "${decimal}: struct global_pack__some_type_in_ada global_pack.some_struct_in_ada;"
set var_in_ada(ada_syntax) "${decimal}: global_pack.some_struct_in_ada: global_pack.some_type_in_ada;"
set rbreak_func_in_c(c_syntax) "void proc_in_c\\\(void\\\);"
set rbreak_func_in_c(ada_syntax) "procedure proc_in_c;"
set rbreak_func_in_ada(c_syntax) "void proc_in_ada\\\(void\\\);"
set rbreak_func_in_ada(ada_syntax) "procedure proc_in_ada;"
foreach_with_prefix language_choice { "auto" "ada" "c" } {
# Check that switching to the desired language_choice when the selected
# frame has the same language (or the desired language is auto) gives no
# warning. Also set the expected matches for the various commands
# tested afterwards.
if {$language_choice == "auto"} {
gdb_test "frame 0" "#0 .*" "select frame with lang c"
set c_match c_syntax
set ada_match ada_syntax
} elseif {$language_choice == "ada"} {
gdb_test "frame 1" "#1 .*" "select frame with lang ada"
set c_match ada_syntax
set ada_match ada_syntax
} elseif {$language_choice == "c"} {
gdb_test "frame 0" "#0 .*" "select frame with lang c"
set c_match c_syntax
set ada_match c_syntax
} else {
error "unexpected language choice"
}
gdb_test_no_output "set language $language_choice" "set language language_choice"
foreach frame {
"0"
"1" } {
if { $frame == 0 } {
set frame_lang "c"
} else {
set frame_lang "ada"
}
with_test_prefix "frame=$frame, frame_lang=$frame_lang" {
gdb_test "frame $frame" "#$frame .*" "select frame"
gdb_test "info functions proc_in_" \
[multi_line \
"All functions matching regular expression \"proc_in_\":" \
"" \
"File .*proc_in_ada.adb:" \
Ensure deterministic result order in gdb.ada/info_auto_lang.exp standard_ada_testfile, standard_test_file and the explicit csrcfile assignment in info_auto_lang.exp all gives similar pathnames prefix for a source, such as /home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.<something>. Note that the above pathnames contain ../ which appears when a relative pathname is used to call configure. In any case, the gnat compiler normalizes Ada sources path when compiling. So, the 'Ada' .o object are referencing a pathname such as /home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/info_auto_lang/proc_in_ada.adb, while the 'C' .o object still references the not normalized pathname. As the results of 'info functions | ...' are sorted by pathname first, the order of the results depends on the comparison between different directories, leading to results that can change depending on these directories. => Ensure the result order is always the same, by normalising the C source file, which makes the results independent of the way configure is launched. Tested by running the testcase in 2 different builds, that without normalize were giving different results. Note: such 'set csrcfile' is used in 4 other tests mixing Ada and C. After discussion, it was deemed sufficient to just normalize the pathname for this test. gdb/testsuite/ChangeLog 2018-12-20 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/info_auto_lang.exp: Normalize some_c source file. Update order of results accordingly.
2018-12-01 21:10:10 +08:00
$func_in_ada($ada_match) \
"" \
"File .*some_c.c:" \
$func_in_c($c_match)
]
gdb_test "info types some_type" \
[multi_line \
Ensure deterministic result order in gdb.ada/info_auto_lang.exp standard_ada_testfile, standard_test_file and the explicit csrcfile assignment in info_auto_lang.exp all gives similar pathnames prefix for a source, such as /home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.<something>. Note that the above pathnames contain ../ which appears when a relative pathname is used to call configure. In any case, the gnat compiler normalizes Ada sources path when compiling. So, the 'Ada' .o object are referencing a pathname such as /home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/info_auto_lang/proc_in_ada.adb, while the 'C' .o object still references the not normalized pathname. As the results of 'info functions | ...' are sorted by pathname first, the order of the results depends on the comparison between different directories, leading to results that can change depending on these directories. => Ensure the result order is always the same, by normalising the C source file, which makes the results independent of the way configure is launched. Tested by running the testcase in 2 different builds, that without normalize were giving different results. Note: such 'set csrcfile' is used in 4 other tests mixing Ada and C. After discussion, it was deemed sufficient to just normalize the pathname for this test. gdb/testsuite/ChangeLog 2018-12-20 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/info_auto_lang.exp: Normalize some_c source file. Update order of results accordingly.
2018-12-01 21:10:10 +08:00
"All types matching regular expression \"some_type\":" \
"" \
"File .*global_pack.ads:" \
Ensure deterministic result order in gdb.ada/info_auto_lang.exp standard_ada_testfile, standard_test_file and the explicit csrcfile assignment in info_auto_lang.exp all gives similar pathnames prefix for a source, such as /home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.<something>. Note that the above pathnames contain ../ which appears when a relative pathname is used to call configure. In any case, the gnat compiler normalizes Ada sources path when compiling. So, the 'Ada' .o object are referencing a pathname such as /home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/info_auto_lang/proc_in_ada.adb, while the 'C' .o object still references the not normalized pathname. As the results of 'info functions | ...' are sorted by pathname first, the order of the results depends on the comparison between different directories, leading to results that can change depending on these directories. => Ensure the result order is always the same, by normalising the C source file, which makes the results independent of the way configure is launched. Tested by running the testcase in 2 different builds, that without normalize were giving different results. Note: such 'set csrcfile' is used in 4 other tests mixing Ada and C. After discussion, it was deemed sufficient to just normalize the pathname for this test. gdb/testsuite/ChangeLog 2018-12-20 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/info_auto_lang.exp: Normalize some_c source file. Update order of results accordingly.
2018-12-01 21:10:10 +08:00
$type_in_ada($ada_match)\
"" \
"File .*some_c.c:" \
$type_in_c($c_match)
]
gdb_test "info variables some_struct" \
[multi_line \
"All variables matching regular expression \"some_struct\":" \
"" \
"File .*global_pack.ads:" \
Ensure deterministic result order in gdb.ada/info_auto_lang.exp standard_ada_testfile, standard_test_file and the explicit csrcfile assignment in info_auto_lang.exp all gives similar pathnames prefix for a source, such as /home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.<something>. Note that the above pathnames contain ../ which appears when a relative pathname is used to call configure. In any case, the gnat compiler normalizes Ada sources path when compiling. So, the 'Ada' .o object are referencing a pathname such as /home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/info_auto_lang/proc_in_ada.adb, while the 'C' .o object still references the not normalized pathname. As the results of 'info functions | ...' are sorted by pathname first, the order of the results depends on the comparison between different directories, leading to results that can change depending on these directories. => Ensure the result order is always the same, by normalising the C source file, which makes the results independent of the way configure is launched. Tested by running the testcase in 2 different builds, that without normalize were giving different results. Note: such 'set csrcfile' is used in 4 other tests mixing Ada and C. After discussion, it was deemed sufficient to just normalize the pathname for this test. gdb/testsuite/ChangeLog 2018-12-20 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/info_auto_lang.exp: Normalize some_c source file. Update order of results accordingly.
2018-12-01 21:10:10 +08:00
$var_in_ada($ada_match) \
"" \
"File .*some_c.c:" \
$var_in_c($c_match)
]
gdb_test "rbreak proc_in_" \
[multi_line \
"Breakpoint.*file .*proc_in_ada.adb,.*" \
Ensure deterministic result order in gdb.ada/info_auto_lang.exp standard_ada_testfile, standard_test_file and the explicit csrcfile assignment in info_auto_lang.exp all gives similar pathnames prefix for a source, such as /home/philippe/gdb/git/build_binutils-gdb/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.<something>. Note that the above pathnames contain ../ which appears when a relative pathname is used to call configure. In any case, the gnat compiler normalizes Ada sources path when compiling. So, the 'Ada' .o object are referencing a pathname such as /home/philippe/gdb/git/binutils-gdb/gdb/testsuite/gdb.ada/info_auto_lang/proc_in_ada.adb, while the 'C' .o object still references the not normalized pathname. As the results of 'info functions | ...' are sorted by pathname first, the order of the results depends on the comparison between different directories, leading to results that can change depending on these directories. => Ensure the result order is always the same, by normalising the C source file, which makes the results independent of the way configure is launched. Tested by running the testcase in 2 different builds, that without normalize were giving different results. Note: such 'set csrcfile' is used in 4 other tests mixing Ada and C. After discussion, it was deemed sufficient to just normalize the pathname for this test. gdb/testsuite/ChangeLog 2018-12-20 Philippe Waroquiers <philippe.waroquiers@skynet.be> * gdb.ada/info_auto_lang.exp: Normalize some_c source file. Update order of results accordingly.
2018-12-01 21:10:10 +08:00
$rbreak_func_in_ada($ada_match) \
"Breakpoint.*file .*some_c.c,.*" \
$rbreak_func_in_c($c_match)
]
delete_breakpoints
}
}
}