aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-12-06[GOLD] PowerPC64 inline plt sequencesAlan Modra1-64/+162
The fixes gold failures to handle inline PLT sequences properly. PowerPC gold was always turning these back into direct calls due to gsym->use_plt_offset() returning false. This is fixed for dynamic linking by correcting get_reference_flags, and for static linking by overriding use_plt_offset() in relocate(). The rest of the patch revolves around needing to create PLT entries for inline PLT calls when statically linking (for gcc -mlongcall). The lplt section handled that for local symbols, now it does globals too. * powerpc.cc (Target_powerpc::plt_off): Return proper section for static link. (Target_powerpc::symval_for_branch): Make public. (Target_powerpc::make_lplt_section): Add Symbol_table* param. Adjust all calls. (Target_powerpc::make_local_plt_entry): Likewise. (Target_powerpc::make_local_plt_entry): New variant for global syms. (Powerpc_relobj::do_relocate_sections): Don't write lplt contents. (Output_data_plt_powerpc::do_write): Write lplt contents here. (Output_data_plt_powerpc::Output_data_plt_powerpc): Save symbol table pointer. Adjust all uses. (Output_data_plt_powerpc::add_entry): Add stash parameter. Don't do dynamic reloc handling when no reloc section. Save symbol for local plt entries. (Output_data_plt_powerpc::add_local_entry): Save symbol. (Output_data_plt_powerpc::Local_plt_ent): New class. (Output_data_plt_powerpc::sym_ents_): New vector. (Target_powerpc::Scan::get_reference_flags): Return FUNCTION_CALL|RELATIVE_REF for inline plt relocs. (Target_powerpc::Scan::global): Make entries in lplt for inline plt call relocation symbols. (Target_powerpc::Relocate::relocate): Rename has_plt_offset to use_plt_offset. Set use_plt_offset for inline plt relocs.
2021-12-06ld: improve shared tests for AIXClément Chigot4-58/+37
It's now possible to refer symbols in the main program from the shared library. However, it still impossible to have the same overriden features between shared objects and mains than ELF, without using the runtime linking feature which isn't yet fully available. ld/ChangeLog: * testsuite/ld-shared/shared.exp: Improve XCOFF support * testsuite/ld-shared/main.c: Likewise. * testsuite/ld-shared/sh1.c: Likewise. * testsuite/ld-shared/xcoff.dat: Likewise.
2021-12-06Automatic date update in version.inGDB Administrator1-1/+1
2021-12-05Preserve artificial CU name in process_psymtab_comp_unit_readerTom Tromey2-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.
2021-12-04sim: include ansidecl.h when neededMike Frysinger16-1/+26
Avoid implicit include deps with this to help untangle sim headers so we can get rid of arch-specific sim-main.h.
2021-12-04sim: include stdint.h when neededMike Frysinger3-0/+3
Avoid implicit include deps with this to help untangle sim headers so we can get rid of arch-specific sim-main.h.
2021-12-04sim: include stdarg.h when usedMike Frysinger20-0/+22
Avoid implicit include deps with this to help untangle sim headers so we can get rid of arch-specific sim-main.h.
2021-12-04sim: reorder header includesMike Frysinger45-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
2021-12-04gdbsupport: fix memory leak in create_file_handler when re-using file handlerSimon Marchi1-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
2021-12-05Automatic date update in version.inGDB Administrator1-1/+1
2021-12-04sim: moxie: hoist dtb rules up to common buildsMike Frysinger4-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.
2021-12-04sim: m68hc11: delete unused profile flagsMike Frysinger1-1/+0
These were moved to the common configure script a while ago and have the same default as these, so just delete it.
2021-12-04sim: msp430: delete redundant comments & settingsMike Frysinger1-22/+0
These were copied from the example docs, so aren't adding any value.
2021-12-04sim: erc32: drop old configure targetMike Frysinger1-8/+0
There is no configure script in here anymore to regenerate.
2021-12-04sim: m32c/rl78: drop redundant -Wall settingsMike Frysinger2-3/+1
We already turn these on in the configure script.
2021-12-04Cache the result of find_file_and_directoryTom Tromey2-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.
2021-12-04Move file_and_directory to new file and C++-izeTom Tromey2-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.
2021-12-04Remove Irix case from find_file_and_directoryTom Tromey1-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.
2021-12-04sim: frv: split up testsuite a bitMike Frysinger9-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.
2021-12-04gdb: don't show deprecated aliasesSimon Marchi2-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
2021-12-03gdb/testsuite: fix two "maint info line-table"-related testsSimon Marchi2-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
2021-12-03gdb: revert one array_view copy change in ada-lang.cSimon Marchi1-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
2021-12-03bfd: unify header generation rulesMike Frysinger2-98/+40
The logic between these rules are extremely similar, so unify them into a single variable.
2021-12-03bfd: move header updates up a directoryMike Frysinger4-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.
2021-12-03bfd: convert bfdver.h to silent automake rulesMike Frysinger2-4/+4
2021-12-04Automatic date update in version.inGDB Administrator1-1/+1
2021-12-03gdb: small "maintenance info line-table" readability improvementsSimon Marchi1-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
2021-12-03gdb: change some alias functions parameters to const-referenceSimon Marchi1-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
2021-12-03gdb: use intrusive_list for cmd_list_element aliases listSimon Marchi2-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
2021-12-03gdb: trivial changes to use array_viewSimon Marchi5-32/+19
Change a few relatively obvious spots using value contents to propagate the use array_view a bit more. Change-Id: I5338a60986f06d5969fec803d04f8423c9288a15
2021-12-03gdb: make extract_integer take an array_viewSimon Marchi14-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
2021-12-03gdbsupport: add array_view copy functionSimon Marchi7-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
2021-12-03gdb: change store_waitstatus to return a target_waitstatus by valueSimon Marchi8-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
2021-12-03gdb: return *this in target_waitstatus settersSimon Marchi1-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
2021-12-03gdb: make saved_filename an std::stringSimon Marchi1-10/+10
Make this variable an std::string, avoiding manual memory management. Change-Id: Ie7a8d7381449ab9c4dfc4cb8b99e63b9ffa8f947
2021-12-03aarch64: Fix uninitialised memoryRichard Sandiford2-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.
2021-12-03gdb: make value_subscripted_rvalue staticAndrew Burgess2-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.
2021-12-03gdb/testsuite: give a test a real nameAndrew Burgess1-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.
2021-12-03gdb/remote: fix use after free bugAndrew Burgess1-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.
2021-12-02libctf: workaround automake bug with conditional info pagesMike Frysinger3-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.
2021-12-03Add myself and Zhensong Liu as the LoongArch port maintainer.Chenghua Xu2-0/+7
2021-12-03Revert "Re: Don't compile some opcodes files when bfd is 32-bit only"Alan Modra2-10/+10
This reverts commit 7a53275579e7cec9389ccb924f5ecf69e8d89d41. The bpf sim doesn't work with a 32-bit bfd after all.
2021-12-03Automatic date update in version.inGDB Administrator1-1/+1
2021-12-02gdb: remove unexpected xstrdup in _initialize_maint_test_settingsSimon Marchi1-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
2021-12-02Fix illegal memory access whilst parsing corrupt DWARF debug information.Nick Clifton2-2/+22
PR 28645 * dwarf.c (process_cu_tu_index): Add test for overruning section whilst processing slots.
2021-12-02[gdb/tdep] Fix avx512 -m32 support in gdbserverTom de Vries1-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.
2021-12-02gdb/testsuite: update tests looking for "DWARF 2" debug formatSimon Marchi9-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
2021-12-02(PPC64) fix handling of fixed-point values when using "return" commandJoel Brobecker1-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>
2021-12-02(RISCV) fix handling of fixed-point type return valuesJoel Brobecker1-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.
2021-12-02(ARM/fixed-point) wrong value shown by "finish" command:Joel Brobecker1-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.
generated by cgit v1.1 at 2024-08-25 16:26:13 +0000