aarch64.ld is the linker script used by most of the relocation tests in AArch64
testsuite. The script does not provide information enough to the linker to assess
the right set of permisssions on segments (i.e. Read/Write/Execute).
This insufficiency caused the linker to bundle all the sections in a same segment
with the union of all the required permissions, i.e. RWX.
A segment with such lax permissions constitutes a security hole, so the linker
emits the following warning message:
<ELF file> has a LOAD segment with RWX permissions.
This warning message is noisy in the tests, and has no reason to exist.
This issue can be addressed in two ways:
- either by providing the right set of permissions on a section so that the
linker assigns them to a segment with compatible permissions.
- or by providing alignment constraints so that the linker can move the sections
automatically to a new segment and set the right permission for non-executable
data.
The second option seems to be the preferred approach, even if not explicitly
recommended. Examples of linker scripts for AArch64 are available at [1].
[1]: https://developer.arm.com/documentation/dui0474/m/gnu-ld-script-support-in
-armlink/default-gnu-ld-scripts-used-by-armlink/default-ld-script-when
-building-an-executable?lang=en
This patch adds support for new system registers introduced in the
2024 MPAM extension (Memory Partitioning and Monitoring):
Available in Armv9.3-A:
MPAMBW0_EL1,
MPAMBW1_EL1,
MPAMBW1_EL12,
MPAMBW2_EL2,
MPAMBW3_EL3,
MPAMBWCAP_EL2,
MPAMBWIDR_EL1
Available in Armv9.3-A with SME:
MPAMBWSM_EL1
The details can be found in [1].
[1]: https://developer.arm.com/documentation/ddi0601/latest
ns32k and z8k cast a valueT pointer to a long pointer when loading
md_apply_fix's value. That's quite wrong if the types have different
sizes, as they may eg. on a 32-bit host with 64-bit bfd support.
sparc also loads the value via a cast pointer, but at least in that
case the cast is to the same size pointer. None of these casts are
needed. Get rid of them.
Yet another case of missing fields in struct initialisation, which
I've replaced with a memset, and some complaints about identifiers
shadowing global declarations. Fixing the shadowing in
loongarch-parse.y is easy. This one isn't so easy:
gas/expr.c: In function 'expr':
gas/expr.c:1891:12: error: declaration of 'is_unsigned' shadows a global declaration
include/opcode/loongarch.h:224:14: error: shadowed declaration is here
opcode/loongarch.h declares lots of stuff that shouldn't be made
available to generic gas code, so I've removed that header from
tc-loongarch.h and moved the parts of TC_FORCE_RELOCATION_SUB_LOCAL
and TC_FORCE_RELOCATION_SUB_LOCAL that need LARCH_opts to functions
in tc-loongarch.c
* config/loongarch-parse.y (loongarch_parse_expr): Rename
param to avoid shadowing.
* config/tc-loongarch.c (loongarch_assemble_INSNs): Use memset
rather than struct initialisation.
(loongarch_force_relocation_sub_local): New function.
(loongarch_force_relocation_sub_same): Likewise.
* config/tc-loongarch.h: Don't include opcode/loongarch.h.
(loongarch_force_relocation_sub_local): Declare, and..
(TC_FORCE_RELOCATION_SUB_LOCAL): ..use here.
(loongarch_force_relocation_sub_same): Declare, and..
(TC_FORCE_RELOCATION_SUB_SAME): ..use here.
More missing struct initialisers, for expressionS vars that in this
case don't need to be initialised. Also an error: redefinition of
typedef 'symbolS'. OK, so don't use a typedef.
gcc-4.5 warns about missing csky_cpus struct initialisers. Fix that
by providing everything in the init macros and the zero sentinel,
rather than just a single {0} as allowed by C99.
A 32-bit host with --enable-64-bit-bfd --target=xtensa-lx106-elf give:
gas/config/tc-xtensa.c: In function ‘xg_get_best_chain_entry’:
gas/config/tc-xtensa.c:7689:11: error: absolute value function ‘labs’ given an argument of type ‘offsetT’ {aka ‘long long int’} but has parameter of type ‘long int’ which may cause truncation of value [-Werror=absolute-value]
7689 | if (labs (off) >= J_RANGE - J_MARGIN)
| ^~~~
Let's not use labs. Unlike labs vma_abs deliberately returns an
unsigned value, and does the negation in an unsigned type so that
signed overflow can't happen.
* config/tc-xtensa.c (vma_abs): New function.
(xg_get_best_chain_entry, xg_get_fulcrum, xg_find_best_trampoline),
(xg_is_relaxable_fixup): Use in place of labs.
This is a followup to commt 619f863c55 "dlltool memory leaks".
The name passed to def_name is freed, so if missing we can't just
use "". strdup it.
* defparse.y (opt_name): xstrdup empty string.
The linker scripts for AArch64 and TIC6x were probably originally copied from
Arm testsuite, and contain the same typo in the name of the attributes section.
This patch fixes the typo across all the testsuites.
When writing commit 28f15782ad ("gdb/dwarf: read multiple .debug_info.dwo
sections"), I initially thought that the gcc behavior of producing multiple
.debug_info.dwo sections was a bug (it is not). I updated the commit
message, but it looks like this comment stayed. Remove it, since it can
be misleading.
Change-Id: I027712d44b778e836f41afbfafab993da02726ef
Approved-By: Tom Tromey <tom@tromey.com>
This patch adds the dependency of Smrnmi extension on Zicsr extension.
bfd/ChangeLog:
* elfxx-riscv.c: New imply.
gas/ChangeLog:
* testsuite/gas/riscv/imply.d: New test check.
* testsuite/gas/riscv/imply.s: New imply test.
Signed-off-by: Jiawei <jiawei@iscas.ac.cn>
While C++ifying the solib code, I concluded that all arches that use
SVR4 libraries do provide link map offsets, so I think this function is
unnecessary now.
Change-Id: Ifaae2560d92f658df3724def6219e2f89054e4b7
Approved-By: Tom Tromey <tom@tromey.com>
Running gdb.cp/cpexprs.exp on x86-64 GNU/Linux, I see:
break base::~base
Breakpoint 117 at 0x555555555d90: file .../src/gdb/testsuite/gdb.cp/cpexprs.cc, line 135.
(gdb) continue
Continuing.
Breakpoint 117, base::~base (this=0x7fffffffd0f8, __in_chrg=<optimized out>) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135
135 ~base (void) { } // base::~base
(gdb) PASS: gdb.cp/cpexprs.exp: continue to base::~base
Here, the breakpoint only got one location because both the in-charge
and the not-in-charge dtors are identical and got the same address:
$ nm -A ./testsuite/outputs/gdb.cp/cpexprs/cpexprs| c++filt |grep "~base"
./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base()
./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base()
While on Cygwin, we get two locations for the same breakpoint, which
the testcase isn't expecting:
break base::~base
Breakpoint 117 at 0x100402678: base::~base. (2 locations)
(gdb) continue
Continuing.
Thread 1 "cpexprs" hit Breakpoint 117.1, base::~base (this=0x7ffffcaf8, __in_chrg=<optimized out>) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135
135 ~base (void) { } // base::~base
(gdb) FAIL: gdb.cp/cpexprs.exp: continue to base::~base
We got two locations because the in-charge and the not-in-charge dtors
have different addresses:
$ nm -A outputs/gdb.cp/cpexprs/cpexprs.exe | c++filt | grep "~base"
outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402680 T base::~base()
outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402690 T base::~base()
On Cygwin, we also see the typical failure due to not expecting the
inferior to be multi-threaded:
(gdb) continue
Continuing.
[New Thread 628.0xe08]
Thread 1 "cpexprs" hit Breakpoint 200, test_function (argc=1, argv=0x7ffffcc20) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:336
336 derived d;
(gdb) FAIL: gdb.cp/cpexprs.exp: continue to test_function for policyd3::~policyd
Both issues are fixed by this patch, and now the testcase passes
cleanly on Cygwin, for me.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Change-Id: If7eb95d595f083f36dfebf9045c0fc40ef5c5df1
I noticed on Cygwin, gdb.thread/thread-execl.exp would hang, (not that
surprising since we can't follow-exec on Cygwin). Looking at the
process list running on the machine, we end up with a thread-execl.exe
process constantly respawning another process [1].
We see the same constant-reexec if we launch gdb.thread/thread-execl
manually on the shell:
$ ./testsuite/outputs/gdb.threads/thread-execl/thread-execl
# * doesn't exit, constantly re-execing *
^C
Prevent this leftover constantly-re-execing scenario by making the
testcase program only exec once. We now get:
$ ./testsuite/outputs/gdb.threads/thread-execl/thread-execl
$ # exits immediately after one exec.
On Cygwin, the testcase now fails reasonably quickly, and doesn't
leave stale processes behind.
Still passes cleanly on x86-64 GNU/Linux.
[1] Cygwin's exec emulation spawns a new Windows process for the new
image.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I0de1136cf2ef7e89465189bc43489a2139a80efb
Cygwin supports dumping ELF cores via a dumper.exe utility, see
https://www.cygwin.com/cygwin-ug-net/dumper.html.
When I run a testcase that has the "kernel" generate a corefile, like
gdb.base/corefile.exp, Cygwin invokes dumper.exe correctly and
generates an ELF core file, however, the testsuite doesn't find the
generated core:
Running /home/alves/gdb/src/gdb/testsuite/gdb.base/corefile.exp ...
WARNING: can't generate a core file - core tests suppressed - check ulimit -c
The file is correctly put under $coredir, e.g., like so:
outputs/gdb.base/corefile/coredir.8926/corefile.exe.core
The problem is in this line in core_find:
foreach i "${coredir}/core ${coredir}/core.coremaker.c ${binfile}.core" {
Note that that isn't looking for "${binfile}.core" inside
${coredir}... That is fixed in this patch.
However, that still isn't sufficient for Cygwin + dumper, as in that
case the core is going to be called foo.exe.core, not foo.core. Fix
that by looking for foo.exe.core in the core dir as well.
With this, gdb.base/corefile.exp and other tests that use core_find
now run. They don't pass cleanly, but at least now they're exercised.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ic807dd2d7f22c5df291360a18c1d4fbbbb9b993e
The gdb.base/sigall.exp testcase has many FAILs on Cygwin currently.
From:
Thread 1 "sigall" received signal SIGPWR, Power fail/restart.
0x00007ffeac9ed134 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) FAIL: gdb.base/sigall.exp: get signal LOST
we see two issues. The test is expecting "Program received ..." which
only appears if the inferior is single-threaded. All Cygwin inferiors
are multi-threaded, because both Windows and the Cygwin runtime spawn
a few helper threads.
And then, SIGLOST is the same as SIGPWR on Cygwin. The testcase
already knows to treat them the same on SPARC64 GNU/Linux. We just
need to extend the relevant code to treat Cygwin the same.
With this, the test passes cleanly on Cygwin.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ie3553d043f4aeafafc011347b6cb61ed58501667
The gdb.arch/amd64-watchpoint-downgrade.exp testcase is assuming the
output of debugging a single-thread program, like so, on e.g.,
GNU/Linux:
starti
Starting program: .../gdb.arch/amd64-watchpoint-downgrade/amd64-watchpoint-downgrade
warning: watchpoint 1 downgraded to software watchpoint
Program stopped.
0x00007ffff7fe32b0 in _start () from /lib64/ld-linux-x86-64.so.2
However, on Cygwin, where all inferiors are multi-threaded (because
both Windows and the Cygwin runtime spawn a few helper threads), we
get:
starti
Starting program: .../gdb.arch/amd64-watchpoint-downgrade/amd64-watchpoint-downgrade
[New Thread 4652.0x17e4]
warning: watchpoint 1 downgraded to software watchpoint
Thread 1 stopped.
0x00007ffbfc1c0911 in ntdll!LdrInitShimEngineDynamic () from C:/Windows/SYSTEM32/ntdll.dll
This commit adjusts the testcase to work with either output.
(Note GDB may print a thread name after the thread number.)
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I3aedfec04924ea3fb3bb87ba3251e2b720f8d59c
On Cygwin, all inferiors are multi-threaded, because both Windows and
the Cygwin runtime spawn a few helper threads. Adjust the
gdb.base/bp-permanent.exp testcase to work with either single- or
multi-threaded inferiors.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I28935b34fc9f739c2a5490e83aa4995d29927be2
Currently on Cygwin, I get:
Running /home/alves/gdb/src/gdb/testsuite/gdb.base/bp-cond-failure.exp ...
FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: single-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=short: cond_eval=auto: multi-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=short: cond_eval=auto: single-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=int: cond_eval=auto: multi-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=int: cond_eval=auto: single-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=long long: cond_eval=auto: multi-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=long long: cond_eval=auto: single-loc: continue
On GNU/Linux, we see:
Breakpoint 2.1, foo () at .../src/gdb/testsuite/gdb.base/bp-cond-failure.c:21
21 return 0; /* Multi-location breakpoint here. */
(gdb) PASS: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue
While on Cygwin, we see:
Thread 1 "bp-cond-failure" hit Breakpoint 2.1, foo () at .../src/gdb/testsuite/gdb.base/bp-cond-failure.c:21
21 return 0; /* Multi-location breakpoint here. */
(gdb) FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue
The difference is the "Thread 1" part in the beginning of the quoted
output. It appears on Cygwin, but not on Linux. That's because on
Cygwin, all inferiors are multi-threaded, because both Windows and the
Cygwin runtime spawn a few helper threads.
Fix this by adjusting the gdb.base/bp-cond-failure.exp testcase to
work with either single- or multi-threaded inferiors.
The testcase passes cleanly for me after this.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I5ff11d06ac1748d044cef025f1e78b8f84ad3349
Now that most of the effort of updating the number of feature words is
handled by macros, add an additional one, taking the number of
supported features to 192.
There are quite a few macros that need to be changed when we need to
increase the number of words in the features data structure. With
some macro trickery we can automate most of this so that a single
macro needs to be updated.
With C2X we could probably do even better by using recursion, but this
is still a much better situation than we had previously.
A static assertion is used to ensure that there is always enough space
in the flags macro for the number of feature bits we need to support.
I was puzzling over how it was correct to cast what is clearly a
struct line_entry** pointer to a struct line_entry* pointer for a
few moments, and was going to write a comment but then decided we
really don't require the "next" pointer to be where it is. Replace
the assert with an inline function that does any necessary pointer
adjustments.
* dwarf2dbg.c (line_entry.next): Delete static assertion.
(line_entry_at_tail): New inline function.
(dwarf2_gen_line_info_1, dwarf2_finish): Replace casts in
set_or_check_view arguments with line_entry_at_tail.
Putting an explicit cast on the void* return from str_hash_find isn't
necessary and doesn't add much to code clarity. In other cases, poor
choice of function parameter types, eg. "void *value" in
tc-aarch64.c checked_hash_insert rather than "const void *value" leads
to needing (void *) casts all over the place just to cast away const.
Fix that by correcting the parameter type. (And it really is a const,
the function and str_hash_insert don't modify the strings.)
This patch also removes some unnecessary casts in hash.c
This changes the internal representation of string_tuple.value from
a void* to an intptr_t, removing any concerns that code wanting to
store an integer value will use values that are trap encodings or
suchlike for a pointer. The ISO C standard says any void* can be
converted to intptr_t and back again and will compare equal to the
original pointer. It does *not* say any intptr_t can be converted to
void* and back again to get the original integer..
Two new functions, str_hash_find_int and str_hash_insert_int are
provided for handling integer values. str_hash_find_int returns
(intptr_t) -1 on failing to find the key string.
Most target code need minimal changes to use the new interface, but
some simplification is possible since now a zero can be stored and
differentiated from the NULL "can't find" return. (Yes, that means
(intptr_t) -1 can't be stored.)
I've changed the avr_no_sreg_hash dummy value to zero, and the
loongarch register numbers don't need to be incremented. loongarch
also doesn't need to store an empty key string (if it ever did).
gas/config/tc-metag.c: In function ‘parse_dsp_addr’:
gas/config/tc-metag.c:4386:29: error: ‘regs[0]’ may be used uninitialized [-Werror=maybe-uninitialized]
4386 | if (!is_addr_unit (regs[0]->unit) &&
| ~~~~~~~^~~~~~
It looks like regs_read can be zero with "l" non-NULL, so this gcc
complaint is accurate.
* config/tc-metag.c (parse_dsp_addr, parse_dget_set): Check
regs_read.
When building on x86_64-cygwin, I run into:
...
In file included from gdbsupport/common-defs.h:203,
from gdb/defs.h:26,
from <command-line>:
gdb/ser-unix.c: In function ‘void hardwire_setbaudrate(serial*, int)’:
gdbsupport/gdb_locale.h:28:20: error: expected ‘)’ before ‘gettext’
28 | # define _(String) gettext (String)
| ^~~~~~~
gdbsupport/gdb_assert.h:43:43: note: in expansion of macro ‘_’
43 | internal_error_loc (__FILE__, __LINE__, _("%s: " message), __func__, \
| ^
gdb/ser-unix.c:590:7: note: in expansion of macro ‘gdb_assert_not_reached’
590 | gdb_assert_not_reached (_("Serial baud rate was not found in B_codes"));
| ^~~~~~~~~~~~~~~~~~~~~~
gdb/ser-unix.c:590:31: note: in expansion of macro ‘_’
590 | gdb_assert_not_reached (_("Serial baud rate was not found in B_codes"));
| ^
gdbsupport/gdb_locale.h:28:28: note: to match this ‘(’
28 | # define _(String) gettext (String)
| ^
gdbsupport/gdb_assert.h:43:43: note: in expansion of macro ‘_’
43 | internal_error_loc (__FILE__, __LINE__, _("%s: " message), __func__, \
| ^
gdb/ser-unix.c:590:7: note: in expansion of macro ‘gdb_assert_not_reached’
590 | gdb_assert_not_reached (_("Serial baud rate was not found in B_codes"));
| ^~~~~~~~~~~~~~~~~~~~~~
...
Fix this by dropping the unneeded _() on the gdb_assert_not_reached argument.
PR build/33064
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33064
On s390x-linux, with test-case gdb.ada/dyn-bit-offset.exp and gcc 7.5.0 I get:
...
(gdb) print spr^M
$1 = (discr => 3, array_field => (-5, -6, -7), field => -6, another_field => -6)^M
(gdb) FAIL: $exp: print spr
print spr.field^M
$2 = -6^M
(gdb) FAIL: $exp: print spr.field
...
On x86_64-linux, with the same compiler version I get:
...
(gdb) print spr^M
$1 = (discr => 3, array_field => (-5, -6, -7), field => -4, another_field => -4)^M
(gdb) XFAIL: $exp: print spr
print spr.field^M
$2 = -4^M
(gdb) PASS: $exp: print spr.field
...
In both cases, we're hitting the same compiler problem, but it manifests
differently on little and big endian.
Make sure the values seen for both little and big endian trigger xfails
for both tests.
Printing spr.field gives the expected value -4 for x86_64, but that's an
accident. Change the actual spr.field value to -5, to make sure
that we get the same number of xfails on x86_64 and s390x.
Finally, make the xfails conditional on the compiler version.
Tested using gcc 7.5.0 on both x86_64-linux and s390x-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR testsuite/33042
https://sourceware.org/bugzilla/show_bug.cgi?id=33042
This patch locates the linker stubs / trampolines *after* all the .progmem
sections. This is the natural placement since progmem data has to reside
in the lower 64 KiB (it is accessed using LPM), whereas the linker stubs
are only required to be located in the lower 128 KiB of program memory.
(They must be in the range of EICALL / EIJMP with EIND = 0.)
The current location of the linker stubs was motivated by an invalid test
case from PR13812 that allocates more than 64 KiB of progmem data.
The patch adds an assertion that makes sure that no progmem data is
allocated past 0xffff.
Data that is accessed using ELPM should be located to .progmemx so that
no .progmem addresses are wasted. .progmemx was introduced in 2017 and
is used by __memx, __flashx and by the current AVR-LibC.
(The compiler uses .jumptables.gcc for its jump dispatch tables since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63223 / GCC v4.9.2).
PR ld/32968
ld/
* scripttempl/avr.sc: Move the trampolines section after the
.progmem sections. Assert that .progmem is in the lower 64 KiB.
For reference see the previous commit.
Fix a memory leak in gdbscm_parse_command_name when a guile exception
is thrown. To reveal the memory leak I placed the following content
into a file 'leak.scm':
(use-modules (gdb))
(register-command!
(make-command
"break cmd"
#:command-class COMMAND_OBSCURE
#:invoke (lambda (self arg from-tty)
(display "Hello World"))))
Then in GDB:
(gdb) source leak.scm
ERROR: In procedure register-command!:
In procedure gdbscm_register_command_x: Out of range: 'break' is not a prefix command in position 1: "break cmd"
Error while executing Scheme code.
Running this under valgrind reveals a memory leak for 'result' and
'prefix_text' from gdbscm_parse_command_name.
Another leak can be revealed with this input script:
(use-modules (gdb))
(register-command!
(make-command
"unknown-prefix cmd"
#:command-class COMMAND_OBSCURE
#:invoke (lambda (self arg from-tty)
(display "Hello World"))))
This one occurs earlier in gdbscm_parse_command_name, and now only
'result' leaks.
The problem is that, when guile throws an exception then a longjmp is
performed from the function that raise the exception back to the guile
run-time. A consequence of this is that no function local destructors
will be run.
In gdbscm_parse_command_name, this means that the two function locals
`result` and `prefix_text` will not have their destructors run, and
any memory managed by these objects will be leaked.
Fix this by assigning nullptr to these two function locals before
throwing an exception. This will cause the managed memory to be
deallocated.
I could have implemented a fix that made use of Guile's dynwind
mechanism to register a cleanup callback, however, this felt like
overkill. At the point the exception is being thrown we know that we
no longer need the managed memory, so we might as well just free the
memory at that point.
With this fix in place, the two leaks are now fixed in the valgrind
output.
Approved-By: Tom Tromey <tom@tromey.com>
In gdbpy_parse_command_name (python/py-cmd.c) there is a call to
xmalloc that can easily be replaced with a call to
make_unique_xstrndup, which makes the code easier to read (I think).
In gdbscm_parse_command_name (guile/scm-cmd.c) the same fix can be
applied to remove an identical xmalloc call. And there is an
additional xmalloc call, which can also be replaced with
make_unique_xstrndup in the same way.
The second xmalloc call in gdbscm_parse_command_name was also present
in gdbpy_parse_command_name at one point, but was replaced with a use
of std::string by this commit:
commit 075c55e0cc
Date: Wed Dec 26 11:05:57 2018 -0700
Remove more calls to xfree from Python
I haven't changed the gdbscm_parse_command_name to use std::string
though, as that doesn't work well with the guile exception model.
Guile exceptions work by performing a longjmp from the function that
raises the exception, back to the guile run-time. The consequence of
this is that destructors are not run. For example, if
gdbscm_parse_command_name calls gdbscm_out_of_range_error, then any
function local objects in gdbscm_parse_command_name will not have
their destructors called.
What this means is that, for the existing `result` and `prefix_text`
locals, any allocated memory managed by these objects will be leaked
if an exception is called. However, fixing this is pretty easy, one
way is to just assign nullptr to these locals before raising the
exception, this would cause the allocated memory to be released.
But for std::string it is harder to ensure that the managed memory has
actually been released. We can call std::string::clear() and then
maybe std::string::shrink_to_fit(), but this is still not guaranteed
to release any managed memory. In fact, I believe the only way to
ensure all managed memory is released, is to call the std::string
destructor.
And so, for functions that can throw a guile exception, it is easier
to just avoid std::string.
As for the memory leak that I identify above; I'll fix that in a
follow on commit.
Approved-By: Tom Tromey <tom@tromey.com>
When the convenience variable $_linker_namespace was introduced, I meant
for it to print the namespace of the frame that where the user was
stopped. However, due to confusing what "current_frame" and
"selected_frame" meant, it instead printed the namespace of the
lowermost frame.
This commit updates the code to follow my original intent. Since the
variable was never in a GDB release, updating the behavior should not
cause any disruption. It also adds a test to verify the functionality.
Approved-By: Tom Tromey <tom@tromey.com>
Modern unix systems allow to set custom baud rate instead of predefined in termios.h.
- To use this in Linux it must have BOTHER macro in "asm/termio.h"
- MacOS could handle this using IOSSIOSPEED passed to ioctl()
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I5bc95982f5d90c7030b73f484ecc0f75c060ebf7
Added B_codes that may be supported in some unix systems
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I48624d6573dc6c72e26818dd44b24182c1dabb70
Replace a manual xfree with unique_xmalloc_ptr.
Change-Id: Id4d2065e3294c4761fe3c852962360712b53d7a8
Approved-By: Tom Tromey <tom@tromey.com>
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Replace a manual xfree with unique_xmalloc_ptr.
Change-Id: I12a20106545905f1a80d069fc0555812cc3d6680
Approved-By: Tom Tromey <tom@tromey.com>
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Internal AdaCore testing using -gdwarf-4 found a spot where GCC will
emit a negative DW_AT_bit_offset. However, my recent signed/unsigned
changes assumed that this value had to be positive.
I feel this bug somewhat invalidates my previous thinking about how
DWARF attributes should be handled.
In particular, both GCC and LLVM at understand that a negative bit
offset can be generated -- but for positive offsets they might use a
smaller "data" form, which is expected not to be sign-extended. LLVM
has similar code but GCC does:
if (bit_offset < 0)
add_AT_int (die, DW_AT_bit_offset, bit_offset);
else
add_AT_unsigned (die, DW_AT_bit_offset, (unsigned HOST_WIDE_INT) bit_offset);
What this means is that this attribute is "signed but default
unsigned".
To fix this, I've added a new attribute::confused_constant method.
This should be used when a constant value might be signed, but where
narrow forms (e.g., DW_FORM_data1) should *not* cause sign extension.
I examined the GCC and LLVM DWARF writers to come up with the list of
attributes where this applies, namely DW_AT_bit_offset,
DW_AT_const_value and DW_AT_data_member_location (GCC only, but LLVM
always emits it as unsigned, so we're safe here).
This patch corrects the bug and imports the relevant test case.
Regression tested on x86-64 Fedora 41.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
Approved-By: Simon Marchi <simon.marchi@efficios.com>
