summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Automatic date update in version.inGDB Administrator2021-12-061-1/+1
|
* Preserve artificial CU name in process_psymtab_comp_unit_readerTom Tromey2021-12-052-7/+11
| | | | | | | | This fixes a use-after-free that Simon pointed out. process_psymtab_comp_unit_reader was allocating an artificial name for a CU, and then discarding it. However, this name was preserved in the cached file_and_directory. This patch arranges for the allocated name to be preserved there.
* sim: include ansidecl.h when neededMike Frysinger2021-12-0416-1/+26
| | | | | Avoid implicit include deps with this to help untangle sim headers so we can get rid of arch-specific sim-main.h.
* sim: include stdint.h when neededMike Frysinger2021-12-043-0/+3
| | | | | Avoid implicit include deps with this to help untangle sim headers so we can get rid of arch-specific sim-main.h.
* sim: include stdarg.h when usedMike Frysinger2021-12-0420-0/+22
| | | | | Avoid implicit include deps with this to help untangle sim headers so we can get rid of arch-specific sim-main.h.
* sim: reorder header includesMike Frysinger2021-12-0445-164/+176
| | | | | | | | | | | | We're including system headers after local headers in a bunch of places, but this leads to conflicts when our local headers happen to define symbols that show up in the system headers. Use the more standard order of: * config.h (via defs.h) * system headers * local library headers (e.g. bfd & libiberty) * sim specific headers
* gdbsupport: fix memory leak in create_file_handler when re-using file handlerSimon Marchi2021-12-041-7/+6
| | | | | | | | | | | | | ASan made me notice a memory leak, where the memory tied to the file handle name string wasn't freed. When register a file handler with an fd that is already registered, we re-use the file_handler object, so we ended up creating a new std::string object and overwriting the file_handler::name pointer, without free-ing the old std::string. Fix this by allocating file_handler with new, deleting it with delete, and making file_handler::name not a pointer. Change-Id: Ie304cc78ab5ae5dfad9a1366e9890c09de651f43
* Automatic date update in version.inGDB Administrator2021-12-051-1/+1
|
* sim: moxie: hoist dtb rules up to common buildsMike Frysinger2021-12-044-49/+116
| | | | | These rules don't depend on the target compiler settings, so hoist the build logic up to the common builds for better parallelization.
* sim: m68hc11: delete unused profile flagsMike Frysinger2021-12-041-1/+0
| | | | | These were moved to the common configure script a while ago and have the same default as these, so just delete it.
* sim: msp430: delete redundant comments & settingsMike Frysinger2021-12-041-22/+0
| | | | These were copied from the example docs, so aren't adding any value.
* sim: erc32: drop old configure targetMike Frysinger2021-12-041-8/+0
| | | | There is no configure script in here anymore to regenerate.
* sim: m32c/rl78: drop redundant -Wall settingsMike Frysinger2021-12-042-3/+1
| | | | We already turn these on in the configure script.
* Cache the result of find_file_and_directoryTom Tromey2021-12-042-8/+18
| | | | | | This changes the DWARF reader to cache the result of find_file_and_directory. This is not especially important now, but it will help the new DWARF indexer.
* Move file_and_directory to new file and C++-izeTom Tromey2021-12-042-45/+129
| | | | | | | | This moves file_and_directory to a new file, and then C++-izes it -- replacing direct assignments with methods, and arranging for it to own any string that must be computed. Finally, the CU's objfile will only be used on demand; this is an important property for the new DWARF indexer's parallel mode.
* Remove Irix case from find_file_and_directoryTom Tromey2021-12-041-9/+0
| | | | | | | | find_file_and_directory has a special case for the Irix 6.2 compiler. Since this is long obsolete, this patch removes it.
* sim: frv: split up testsuite a bitMike Frysinger2021-12-049-19/+136
| | | | | | Running frv's allinsn in serial is quite slow due to the sheer number of tests it contains. By splitting it up and running in parallel, the execution time on my system goes from ~100sec to ~60sec.
* gdb: don't show deprecated aliasesSimon Marchi2021-12-042-3/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I don't think it's very useful to show deprecated aliases to the user. It encourages the user to use them, when the goal is the opposite. For example, before: (gdb) help set index-cache enabled set index-cache enabled, set index-cache off, set index-cache on alias set index-cache off = set index-cache enabled off alias set index-cache on = set index-cache enabled on Enable the index cache. When on, enable the use of the index cache. (gdb) help set index-cache on Warning: 'set index-cache on', an alias for the command 'set index-cache enabled', is deprecated. Use 'set index-cache enabled on'. set index-cache enabled, set index-cache off, set index-cache on alias set index-cache off = set index-cache enabled off alias set index-cache on = set index-cache enabled on Enable the index cache. When on, enable the use of the index cache. After: (gdb) help set index-cache enabled Enable the index cache. When on, enable the use of the index cache. (gdb) help set index-cache on Warning: 'set index-cache on', an alias for the command 'set index-cache enabled', is deprecated. Use 'set index-cache enabled on'. Enable the index cache. When on, enable the use of the index cache. Change-Id: I989b618a5ad96ba975367e9d16db95523cd57a4c
* gdb/testsuite: fix two "maint info line-table"-related testsSimon Marchi2021-12-032-0/+8
| | | | | | | | | | Commit 92228a334ba2 ("gdb: small "maintenance info line-table" readability improvements") change the output format of "maint info line-table" slightly, adding some empty lines between each line-table. This causes two tests to start failing, update them to account for those empty lines. Change-Id: I9d33a58fce3e860ba0554b25f5582e8066a5c519
* gdb: revert one array_view copy change in ada-lang.cSimon Marchi2021-12-031-1/+3
| | | | | | | | | | | | | | | Commit 4bce7cdaf481 ("gdbsupport: add array_view copy function") caused an internal error when running gdb.ada/packed_array_assign.exp: print pra(1) := pr^M /home/smarchi/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed.^M I am not sure what's the root cause of this, whether it is a GDB bug exposed by using the array_view copy function or not. Back out the change that triggers the internal error for now, while we investigate it. Change-Id: I055ab14143e4cfd3ca7ce8f4855c6c3c05db52a7
* bfd: unify header generation rulesMike Frysinger2021-12-032-98/+40
| | | | | The logic between these rules are extremely similar, so unify them into a single variable.
* bfd: move header updates up a directoryMike Frysinger2021-12-034-236/+131
| | | | | | | | | | The rules for rebuilding the bfd headers live in the doc/ subdir (most likely) because they rely on the chew & related tools. But we can collapse them into the main Makefile while keeping the tools in the doc subdir easily enough. This makes the code simpler and allows for rebuilding them in parallel. Also add automake silent rule support while we're here.
* bfd: convert bfdver.h to silent automake rulesMike Frysinger2021-12-032-4/+4
|
* Automatic date update in version.inGDB Administrator2021-12-041-1/+1
|
* gdb: small "maintenance info line-table" readability improvementsSimon Marchi2021-12-031-6/+13
| | | | | | | | | | | | | | | | - separate each entry with a newline, to visually separate them - style filenames with the filename style - print the name of the compunit_symtab A header now looks like this, with the compunit_symtab name added (and the coloring, but you can't really see it here): objfile: /home/simark/build/babeltrace/src/cli/.libs/babeltrace2 ((struct objfile *) 0x613000005980) compunit_symtab: babeltrace2-cfg-cli-args.c ((struct compunit_symtab *) 0x62100da1ed10) symtab: /usr/include/glib-2.0/glib/gdatetime.h ((struct symtab *) 0x62100d9ee530) linetable: ((struct linetable *) 0x0): Change-Id: Idc23e10aaa66e2e692adb0a6a74144f72c4fa1c7
* gdb: change some alias functions parameters to const-referenceSimon Marchi2021-12-031-32/+32
| | | | | | | | Now that we use intrusive list to link aliases, it becomes easier to pass cmd_list_element arguments by const-reference rather than by pointer to some functions, change a few. Change-Id: Id0df648ed26e9447da0671fc2c858981cda31df8
* gdb: use intrusive_list for cmd_list_element aliases listSimon Marchi2021-12-032-50/+50
| | | | | | | Change the manually-implemented linked list to use intrusive_list. This is not strictly necessary, but it makes the code much simpler. Change-Id: Idd08090ebf2db8bdcf68e85ef72a9635f1584ccc
* gdb: trivial changes to use array_viewSimon Marchi2021-12-035-32/+19
| | | | | | | Change a few relatively obvious spots using value contents to propagate the use array_view a bit more. Change-Id: I5338a60986f06d5969fec803d04f8423c9288a15
* gdb: make extract_integer take an array_viewSimon Marchi2021-12-0314-55/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I think it would make sense for extract_integer, extract_signed_integer and extract_unsigned_integer to take an array_view. This way, when we extract an integer, we can validate that we don't overflow the buffer passed by the caller (e.g. ask to extract a 4-byte integer but pass a 2-byte buffer). - Change extract_integer to take an array_view - Add overloads of extract_signed_integer and extract_unsigned_integer that take array_views. Keep the existing versions so we don't need to change all callers, but make them call the array_view versions. This shortens some places like: result = extract_unsigned_integer (value_contents (result_val).data (), TYPE_LENGTH (value_type (result_val)), byte_order); into result = extract_unsigned_integer (value_contents (result_val), byte_order); value_contents returns an array view that is of length `TYPE_LENGTH (value_type (result_val))` already, so the length is implicitly communicated through the array view. Change-Id: Ic1c1f98c88d5c17a8486393af316f982604d6c95
* gdbsupport: add array_view copy functionSimon Marchi2021-12-037-62/+184
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An assertion was recently added to array_view::operator[] to ensure we don't do out of bounds accesses. However, when the array_view is copied to or from using memcpy, it bypasses that safety. To address this, add a `copy` free function that copies data from an array view to another, ensuring that the destination and source array views have the same size. When copying to or from parts of an array_view, we are expected to use gdb::array_view::slice, which does its own bounds check. With all that, any copy operation that goes out of bounds should be caught by an assertion at runtime. copy is implemented using std::copy and std::copy_backward, which, at least on libstdc++, appears to pick memmove when copying trivial data. So in the end there shouldn't be much difference vs using a bare memcpy, as we do right now. When copying non-trivial data, std::copy and std::copy_backward assigns each element in a loop. To properly support overlapping ranges, we must use std::copy or std::copy_backward, depending on whether the destination is before the source or vice-versa. std::copy and std::copy_backward don't support copying exactly overlapping ranges (where the source range is equal to the destination range). But in this case, no copy is needed anyway, so we do nothing. The order of parameters of the new copy function is based on std::copy and std::copy_backward, where the source comes before the destination. Change a few randomly selected spots to use the new function, to show how it can be used. Add a test for the new function, testing both with arrays of a trivial type (int) and of a non-trivial type (foo). Test non-overlapping ranges as well as three kinds of overlapping ranges: source before dest, dest before source, and dest == source. Change-Id: Ibeaca04e0028410fd44ce82f72e60058d6230a03
* gdb: change store_waitstatus to return a target_waitstatus by valueSimon Marchi2021-12-038-19/+20
| | | | | | | | | | | | | | | store_waitstatus is basically a translation function between a status integer and an equivalent target_waitstatus object. It would make sense for it to take the integer as a parameter and return the target_waitstatus by value. Do that, and rename to host_status_to_waitstatus. Users can then do: ws = host_status_to_waitstatus (status) which does the right thing, given the move constructor of target_waitstatus. Change-Id: I7a07d59d3dc19d3ed66929642f82f44f3e85d61b
* gdb: return *this in target_waitstatus settersSimon Marchi2021-12-031-16/+32
| | | | | | | | | | | | | | | | | | | | | | | | | While playing with some code creating target_waitstatus objects, I was mildly annoyed by the fact that we can't just return a new target_waitstatus object. We have to do: target_waitstatus ws; ws.set_exited (123); return ws; Make the setters return the "this" object as a reference, such that it's possible to do: return target_waitstatus ().set_exited (123); I initially thought of adding static creation functions, which you would use like: return target_waitstatus::make_exited (123); However, making the setters return a reference to the object achieves pretty much the same thing, with less new code. Change-Id: I45159b7f9fcd9db5b20603480e323020b14ed147
* gdb: make saved_filename an std::stringSimon Marchi2021-12-031-10/+10
| | | | | | Make this variable an std::string, avoiding manual memory management. Change-Id: Ie7a8d7381449ab9c4dfc4cb8b99e63b9ffa8f947
* aarch64: Fix uninitialised memoryRichard Sandiford2021-12-032-1/+3
| | | | | | | | | | | | | AARCH64_OPDE_EXPECTED_A_AFTER_B and AARCH64_OPDE_A_SHOULD_FOLLOW_B are not paired with an error string, but we had an assert that the error was nonnull. Previously this assert was testing uninitialised memory and so could pass or fail arbitrarily. opcodes/ * aarch64-opc.c (verify_mops_pme_sequence): Initialize the error field to null for AARCH64_OPDE_EXPECTED_A_AFTER_B and AARCH64_OPDE_A_SHOULD_FOLLOW_B. * aarch64-dis.c (print_verifier_notes): Move assert.
* gdb: make value_subscripted_rvalue staticAndrew Burgess2021-12-032-6/+8
| | | | | | | The function value_subscripted_rvalue is only used in valarith.c, so lets make it a static function. There should be no user visible change after this commit.
* gdb/testsuite: give a test a real nameAndrew Burgess2021-12-031-1/+2
| | | | | | | | | | | | | | | | | A test in gdb.python/py-send-packet.exp added in this commit: commit 24b2de7b776f8f23788d855b1eec290c6e208821 Date: Tue Aug 31 14:04:36 2021 +0100 gdb/python: add gdb.RemoteTargetConnection.send_packet included a large amount of binary data in the command sent to GDB. As this test didn't have a real test name the binary data was included in the gdb.sum file. The contents of the binary data could change between different runs of GDB, and this makes comparing results harder. This commit gives the test a real test name.
* gdb/remote: fix use after free bugAndrew Burgess2021-12-031-2/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit: commit 288712bbaca36bff6578bc839ebcdc3707662f81 Date: Mon Nov 22 15:16:27 2021 +0000 gdb/remote: use scoped_restore to control starting_up flag introduced a use after free bug. The scoped restore added in the above commit resets a flag within a remote_target's remote_state object. However, in some situations, the remote_target can be unpushed before the error is thrown. If the only reference to the target is the one in the target stack, then unpushing the target will cause the remote_target to be deleted, which, in turn, will delete the remote_state object. The scoped restore will then try to reset the flag within a deleted object. This problem was caught in the gdb.server/server-connect.exp test, which, when run with the address sanitizer enabled, highlights the write after free bug described above. This commit resolves this issue by adding a new class specifically for the purpose of managing the starting_up flag. As well as setting, and then clearing the starting_up flag, this new class increments, and then decrements the reference count on the remote_target object. This prevents the remote_target from being deleted until after the flag has been reset. The gdb.server/server-connect.exp now runs cleanly with the address sanitizer enabled.
* libctf: workaround automake bug with conditional info pagesMike Frysinger2021-12-023-20/+32
| | | | | | | | | | | | | It looks like automake makes assumptions about its ability to build info pages based on the GNU standard behavior of shipping info pages with the distributions. So even though the info pages were conditionalized, and automake disabled some of the targets, it was still creeping in by way of unconditional INFO_DEPS settings. We can workaround this by adding a stub target for the info page when building info pages are disabled. This tricks automake into disabling its own extended generation target. I'll follow up with the automake folks to see what they think.
* Add myself and Zhensong Liu as the LoongArch port maintainer.Chenghua Xu2021-12-032-0/+7
|
* Revert "Re: Don't compile some opcodes files when bfd is 32-bit only"Alan Modra2021-12-032-10/+10
| | | | | This reverts commit 7a53275579e7cec9389ccb924f5ecf69e8d89d41. The bpf sim doesn't work with a 32-bit bfd after all.
* Automatic date update in version.inGDB Administrator2021-12-031-1/+1
|
* gdb: remove unexpected xstrdup in _initialize_maint_test_settingsSimon Marchi2021-12-021-1/+1
| | | | | | | | That xstrdup is not correct, since we are assigning an std::string. The result of xstrdup is used to initialize the string, and then lost forever. Remove it. Change-Id: Ief7771055e4bfd643ef3b285ec9fb7b1bfd14335
* Fix illegal memory access whilst parsing corrupt DWARF debug information.Nick Clifton2021-12-022-2/+22
| | | | | | PR 28645 * dwarf.c (process_cu_tu_index): Add test for overruning section whilst processing slots.
* [gdb/tdep] Fix avx512 -m32 support in gdbserverTom de Vries2021-12-021-13/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PR27257 reports a problem that can be reproduced as follows: - use x86_64 machine with avx512 support - compile a hello world with -m32 to a.out - start a gdbserver session with a.out - use gdb to connect to the gdbserver session This makes us run into: ... Listening on port 2346 Remote debugging from host ::1, port 34940 src/gdbserver/regcache.cc:257: \ A problem internal to GDBserver has been detected. Unknown register zmm16h requested ... The problem is that i387_xsave_to_cache in gdbserver/i387-fp.cc can't find a register zmm16h in the register cache. To understand how this happens, first some background. SSE has 16 128-bit wide xmm registers. AVX extends the SSE registers set as follows: - it extends the 16 existing 128-bit wide xmm registers to 256-bit wide ymm registers. AVX512 extends the AVX register set as follows: - it extends the 16 existing 256-bit wide ymm registers to 512-bit wide zmm registers. - it adds 16 additional 512-bit wide zmm registers (with corresponding ymm and xmm subregisters added as well) However, in 32-bit mode, there are only 8 xmm/ymm/zmm registers. The problem we're running into is that gdbserver/i387-fp.cc uses these constants to describe the size of the register file: ... static const int num_avx512_zmmh_low_registers = 16; static const int num_avx512_zmmh_high_registers = 16; static const int num_avx512_ymmh_registers = 16; static const int num_avx512_xmm_registers = 16; ... which are all incorrect for the 32-bit case. Fix this by replacing the constants with variables that have the appropriate values in 64-bit and 32-bit mode. Tested on x86_64-linux with native and unix/-m32.
* gdb/testsuite: update tests looking for "DWARF 2" debug formatSimon Marchi2021-12-029-16/+16
| | | | | | | | | | | | | | | | | | Commit ab557072b8ec ("gdb: use actual DWARF version in compunit's debugformat field") changes the debug format string in "info source" to show the actual DWARF version, rather than always show "DWARF 2". However, it failed to consider that some tests checked for the "DWARF 2" string to see if the test program is compiled with DWARF debug information. Since everything is compiled with DWARF 4 or 5 nowadays, that changed the behavior of those tests. Notably, it prevent the tests using skip_inline_var_tests to run. Grep through the testsuite for "DWARF 2" and change all occurrences I could find to use "DWARF [0-9]" instead (that string is passed to TCL's string match). Change-Id: Ic7fb0217fb9623880c6f155da6becba0f567a885
* (PPC64) fix handling of fixed-point values when using "return" commandJoel Brobecker2021-12-021-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the gdb.ada/fixed_points_function.exp testcase, we have the following Ada code... type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary function Call_FP1 (F : FP1_Type) return FP1_Type is begin FP1_Arg := F; return FP1_Arg; end Call_FP1; ... used as follow: F1 : FP1_Type := 1.0; F1 := Call_FP1 (F1); The testcase, among other things, verifies that "return" works properly as follow: | (gdb) return 1.0 | Make pck.call_fp1 return now? (y or n) y | [...] | 9 F1 := Call_FP1 (F1); | (gdb) next | (gdb) print f1 | $1 = 0.0625 The output of the last command shows that we returned the wrong value. The value printed gives a clue about the problem, since it is 1/16th of the value we expected, where 1/16 is FP1_Type's scaling factor. The problem, here, comes from the fact that the function handling return values for base types (ppc64_sysv_abi_return_value_base) writes the return value using unpack_long which, upon seeing that the value being unpacked is a fixed point type, applies the scaling factor, to get the integer-representation of our fixed-point value (similar to what it does with floats, for instance). So, the fix consists in teaching ppc64_sysv_abi_return_value_base about fixed-point types, and to avoid the unwanted application of the scaling factor. Note that the "finish" function, on the other hand, does not suffer from this issue, simply becaue the value returned by the function is read from register without the use of a type, thus avoiding an unwanted application of a scaling factor. No test added, as this change is already tested by gdb.ada/fixed_points_function.exp. Co-Authored-By: Tristan Gingold <gingold@adacore.com>
* (RISCV) fix handling of fixed-point type return valuesJoel Brobecker2021-12-021-3/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit adds support for TYPE_CODE_FIXED_POINT types for "finish" and "return" commands. Consider the following Ada code... type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary function Call_FP1 (F : FP1_Type) return FP1_Type is begin FP1_Arg := F; return FP1_Arg; end Call_FP1; ... used as follow: F1 : FP1_Type := 1.0; F1 := Call_FP1 (F1); "finish" currently behaves as follow: | (gdb) finish | [...] | Value returned is $1 = 0 We expect the returned value to be "1". Similarly, "return" makes the function return the wrong value: | (gdb) return 1.0 | Make pck.call_fp1 return now? (y or n) y | [...] | 9 F1 := Call_FP1 (F1); | (gdb) next | (gdb) print f1 | $1 = 0.0625 (we expect it to print "1" instead). This problem comes from the handling of integral return values when the return value is actually fixed point type. Our type here is actually a range of a fixed point type, but the same principles should also apply to pure fixed-point types. For the record, here is what the debugging info looks like: <1><238>: Abbrev Number: 2 (DW_TAG_subrange_type) <239> DW_AT_lower_bound : -16 <23a> DW_AT_upper_bound : 16 <23b> DW_AT_name : pck__fp1_type <23f> DW_AT_type : <0x248> <1><248>: Abbrev Number: 4 (DW_TAG_base_type) <249> DW_AT_byte_size : 1 <24a> DW_AT_encoding : 13 (signed_fixed) <24b> DW_AT_binary_scale: -4 <24c> DW_AT_name : pck__Tfp1_typeB <250> DW_AT_artificial : 1 ... where the scaling factor is 1/16. Looking at the "finish" command, what happens is that riscv_arg_location determines that our return value should be returned by parameter using an integral convention (via builtin type long). And then, riscv_return_value uses a cast to that builtin type long to store the value of into a buffer with the right register size. This doesn't work in our case, because the underlying value returned by the function is unscaled, which means it is 16, and thus the cast is like doing: arg_val = (FP1_Type) 16 ... In other words, it is trying to create an FP1_Type enty whose value is 16. Applying the scaling factor, that's 256, and because the size of FP1_Type is 1 byte, we overflow and thus it ends up being zero. The same happen with the "return" function, but the other way around. The fix consists in handling fixed-point types separately from integral types.
* (ARM/fixed-point) wrong value shown by "finish" command:Joel Brobecker2021-12-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following Ada code: type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary FP1_Arg : FP1_Type := 0.0; function Call_FP1 (F : FP1_Type) return FP1_Type is begin FP1_Arg := F; return FP1_Arg; end Call_FP1; After having stopped inside function Call_FP1 as follow: Breakpoint 1, pck.call_fp1 (f=1) at /[...]/pck.adb:5 5 FP1_Arg := F; Returning from that function call using "finish" should show that the function return "1.0" (the same value as was passed as an argument). However, this is not the case: (gdb) finish Run till exit from #0 pck.call_fp1 (f=1) [...] 9 F1 := Call_FP1 (F1); Value returned is $1 = 0 This patch enhances the extraction of the return value to know about fixed point types.
* (Ada/AArch64) fix fixed point argument passing in inferior funcallXavier Roirand2021-12-025-1/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following code: type FP1_Type is delta 0.1 range -1.0 .. +1.0; -- Ordinary function Call_FP1 (F : FP1_Type) return FP1_Type is begin return F; end Call_FP1; When the default in GCC is to generate proper DWARF info for fixed point types, then in gdb, printing the result of a call to call_fp1 with a decimal parameter leads to: (gdb) p call_fp1(0.5) $1 = 0 The displayed value is wrong, and we actually expected: (gdb) p call_fp1(0.5) $1 = 0.5 What happened is that our fixed point type parameter got promoted to a 32bit integer because we detected that the length of that object was less than 4 bytes. The compiler does not perform this promotion and therefore GDB should not either. This patch fixes the behavior described above.
* Implement 'task apply'Tom Tromey2021-12-026-18/+277
| | | | | | | | | This adds a 'task apply' command, which is the Ada tasking analogue of 'thread apply'. Unlike 'thread apply', it doesn't offer the 'ascending' flag; but otherwise it's essentially the same.
View Lorry Controller Status