| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* ldlang.c: Whitespace.
(stat_free, stat_concat): New functions.
* ldlang.h (stat_free, stat_concat): Declare.
* plugin.c (asymbol_from_plugin_symbol): Use stat_concat.
|
|
This one happens with --gc-sections and a linker script that either
discards some or all .eh_frame sections (eg. ld-elf/pr14265 test) or
maps an input .eh_frame to some other named output section. In that
case the discarded/renamed .eh_frame won't have local_cies freed.
* elf-eh-frame.c (_bfd_elf_parse_eh_frame): Correct comment.
* elf.c (_bfd_elf_free_cached_info): Free eh_frame cies.
|
|
This fixes an even more obvious leak.
* ldelf.c (ldelf_before_allocation): Free copied elf_dt_audit.
Simplify loop.
|
|
* testsuite/ld-elf/indirect.exp: Run compiler capability checks
using run_host_noleak.
* testsuite/ld-ifunc/ifunc.exp: Don't exit without restoring
ASFLAGS. Don't run ifuncmod5 twice.
|
|
ld/
PR ld/32580
* scripttempl/elf.sc: Fix '==' bashism.
|
|
|
|
This removes gnatmake_version_at_least in favor of using the more
flexible gnat_version_compare. I think these two version numbers
should be the same, as gnatmake is shipped with the compiler.
|
|
While testing gnat-llvm, I found a gdb crash when applying 'length to
a non-array type. This patch fixes the crash.
|
|
I found another Ada test case where gnat-llvm optimizes away the local
variables. This patch applies the same fix to it as previous patches.
|
|
After commit:
commit bd32be01c997f686ab0b53f0640eaa0aeb61fbd3
Date: Fri Dec 3 00:23:20 2021 -0500
bfd: merge doc subdir up a level
And the follow-up commit:
commit 98b1464bdf6306a8ab4614b5e9f76cdb2dd00b33
Date: Wed Oct 2 22:58:08 2024 +0300
bfd: fix unnecessary bfd.info regen
There is still a problem building the bfd docs from a release tar
file.
As the release tar file contains the pre-generated .texi files we
expect the bfd/doc build stage to symlink to the pre-existing .texi
files in the source tree.
However, this is still not working as expected if $(srcdir) is
relative. The problem is this line in REGEN_TEXI:
test -e $$texi || test ! -f $(srcdir)/$$texi || $(LN_S) $(srcdir)/$$texi $$texi; \
This is executed from the build/bfd/ directory, so if $(srcdir) is
relative, then this will get you from the bfd/ directory in the build
tree to the corresponding bfd/ directory in the src tree. However,
the symlink is created in the bfd/doc/ build directory. The relative
path will then fail to take you to the bfd/ directory in the src
tree.
Fix this by using $(abs_srcdir) when creating the symlink.
Approved-By: Nick Clifton <nickc@redhat.com>
|
|
On arm-linux (ubuntu 24.04 with gcc 13.3.0) with target board unix/-marm and
test-case gdb.base/branch-to-self.exp I run into:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint
si^M
0x0040058c 38 for (;;); /* loop-line */^M
(gdb) FAIL: $exp: single-step: si
...
In contrast, on the same machine but with debian testing and gcc 14.2.0 we have:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: continue to breakpoint: hit breakpoint
si^M
^M
Breakpoint 2, main () at branch-to-self.c:38^M
38 for (;;); /* loop-line */^M
(gdb) PASS: $exp: single-step: stepi
...
The difference is in the instruction(s) generated for the loop.
In the passing case, we have:
...
588: eafffffe b 588 <main+0x24>
...
and in the failing case:
...
588: e320f000 nop {0}
58c: eafffffd b 588 <main+0x24>
...
The purpose of this part of the test-case is to:
- generate a branch instruction that jumps to itself, and
- set a breakpoint on it, and check that stepi-ing from that breakpoint
triggers the breakpoint again.
As we can see, in the failing case we failed to generate a branch instruction
that jumps to itself, and consequently we cannot expect to hit the breakpoint
again after issuing a single si.
Fix this by issuing stepi until we hit the breakpoint.
Tested on arm-linux.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
|
|
PR gas/32579
The deprecated .s (swapped operand encoding) functionality got in the
way of properly recognizing this specific form. Move the Solaris-
specific code ahead of that.
|
|
The canonical form (in the testsuite) is %progbits and alike.
|
|
I have missed @tab for .gmiccs and .padlockphe2, so fix this doc error.
gas/ChangeLog:
* doc/c-i386.texi: Add the missing @tab for .gmiccs and
.padlockphe2
|
|
|
|
When running test-case gdb.base/fission-macro.exp on openSUSE Tumbleweed
(using gcc 14) with target board unix/-m32, I get:
...
(gdb) info macro FIRST^M
Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:0^M
-DFIRST=1^M
(gdb) FAIL: $exp: \
dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST
...
instead of the expected:
...
(gdb) info macro FIRST^M
Defined at /data/vries/gdb/src/gdb/testsuite/gdb.base/fission-macro.c:18^M
(gdb) PASS: $exp: \
dwarf_version=5: dwarf_bits=32: strict_dwarf=0: info macro FIRST
...
A dwarf-5 .debug_str_offsets section starts with a header consisting of:
- an initial length (4 bytes for 32-bit and 12 bytes for 64-bit),
- a 2 byte version string, and
- 2 bytes padding
so in total 8 bytes for 32-bit and 16 bytes for 64-bit.
This offset is calculated here in dwarf_decode_macros:
...
str_offsets_base = cu->header.addr_size;
...
which is wrong for both dwarf-5 cases (and also happens to be wrong for
dwarf-4).
Fix this by computing str_offsets_base correctly for dwarf-5, for both the
32-bit and 64-bit case.
Likewise, fix this for dwarf-4, using str_offsets_base 0. We can only test
this with gcc-15, because gcc 14 and earlier don't have the fix for
PR debug/115066.
Tested on x86_64-linux.
Tested test-case using a current gcc trunk build, and gcc 14.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/31897
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31897
|
|
The stated intention of test-case gdb.base/lineinc.exp is:
...
# Test macro handling of #included files.
...
However, the test-case does not produce any macro debug information.
Fix this by adding macros in the compilation flags.
Tested on x86_64-linux.
|
|
|
|
|
|
On casual reading of older gcc configure scripts it might be supposed
that the test for gas string merge support tries with %progbits after
a fail on ARM with @progbits. It doesn't succeed due to a bug. So to
support building of older gcc's for ARM without users having to edit
gcc sources, add a hack to gas. The hack can disappear in a few years
when building older gcc's likely requires other work too.
I've changed the docs to reflect what we actually allow for .section
syntax prior to this patch. (No way should this hack be documented as
allowed!)
PR 32491
* config/obj-elf.c (obj_elf_section): Allow missing entsize
for ARM gcc configure bug.
* doc/as.texi: Correct syntax of ELF .section directive.
* testsuite/gas/elf/string.s,
* testsuite/gas/elf/string.d: Test it.
|
|
This allows you to specify a run_dump_test warning that may or may not
be present using
warning: (warning_text_goes_here)?
ie. the regexp matches an empty string.
|
|
I found that building binutils with -fsanitize=address,undefined
results in much of the testsuite not being run. The problem is that
running gcc results in linker plugin memory leaks which of course are
errors, so the testsuite sees this as lack of compiler support.
* testsuite/lib/ld-lib.exp (run_host_noleak): New proc.
(check_compiler_available, check_lto_available),
(check_lto_fat_available, check_lto_shared_available),
(check_ifunc_available, check_ifunc_attribute_available),
(check_libdl_available, check_gnu2_tls_available),
(compile_one_cc): Use run_host_noleak.
* testsuite/config/default.exp (compiler_supports): Likewise.
|
|
Delete an extra 2.44 NEWS marker that has crept in by chance.
|
|
|
|
|
|
|
|
The newly added test gdb.base/backtrace-through-cu-nodebug.exp had a
problem in the call to gdb_compile, that caused the .o files to be
outputted in the GDB file tree. This commit fixes the issues in the calls.
Reported-By: Tom de Vries <tdevries@suse.de>
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
|
|
Commit af3394d97a8c5187085c0eec5fb03e8da88db5fb allowed sections
declared with "S" (SHF_STRING) to specify the entity size, but then
would warn if the entity size was omitted, as with the old syntax.
Unfortunately, since specifying the entity size is incompatible with
binutils 2.43 or earlier, this makes it impossible to specify a
strings section in source code without generating an assembly warning
(the new syntax isn't supported in older assemblers and the old syntax
generates warnings).
Nevertheless, the old code was wrong in that it did not set the entity
size at all, in contravention of the ELF specification (though to date
there are no known cases where this mattered outside of mergeable
sections).
Fix this by permitting the original syntax without a warning again,
but by defaulting the entity size to 1. This is compatible with the
most common case of strings being byte-based.
Added some tests for the various flavours of declaration that we
support.
|
|
ldelf_before_allocation is passed the audit and depaudit strings built
from command line args, then possibly adds to the depaudit string,
freeing the original. The new string isn't freed. Fix this leak by
keeping the string attached to the static vars.
* ldelf.c (ldelf_before_allocation): Pass char** for audit
and depaudit. Adjust uses.
* ldelf.h (ldelf_before_allocation): Update prototype.
* gld${EMULATION_NAME}_before_allocation: Update call.
|
|
* elflink.c (elf_link_add_object_symbols): Free old_strtab
in another code path. Revert one unnecessary change in last
patch.
|
|
This fixes an error path in _bfd_elf_get_dynamic_symbols, fixes the
minimum size required when reading DT_HASH header, and tidies
formatting in a few places. Nit-fixes all.
Very likely we shouldn't be trying to mmap DT_DYNAMIC as it won't be
large enough for the mmap size threshold.
* elf.c (_bfd_elf_get_dynamic_symbols): Use _bfd_munmap_temporary
in error return path rather than free. Corrent size passed to
offset_from_vma when reading DT_HASH header. Formatting.
|
|
On arm-linux, with target board unix/-mthumb, we get:
...
(gdb) PASS: gdb.cp/non-trivial-retval.exp: continue to breakpoint: Break here
p f1 (i1, i2)^M
$1 = {a = -136274256}^M
(gdb) FAIL: gdb.cp/non-trivial-retval.exp: gdb-command<p f1 (i1, i2)>
...
This is not a problem with the inferior call, which works fine:
...
(gdb) p f1 (23, 100)
$3 = {a = 123}
...
but instead it's a problem with the location information:
...
(gdb) p i1
$1 = -136274356
(gdb) p i2
$2 = 100
...
which tells us to find the value of i1 in (DW_OP_fbreg: -12).
The test-case passes if we drop -fvar-tracking, in which case the debug info
tells us to find the value of i1 in (DW_OP_fbreg: -20).
This is with gcc 13.3.0 on Ubuntu 24.04. With gcc 14.2.0 on Debian testing,
the code is the same, but -fvar-tracking does use the correct
'(DW_OP_fbreg: -20)'.
There seems to be some bugfix in -fvar-tracking for gcc 14.
Workaround the bug by using constants 23 and 100 instead of i1 and i2 when
using -fvar-tracking and gcc < 14.
Tested on arm-linux.
PR testsuite/32549
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32549
|
|
|
|
This arranges to free section relocs cached in elf_section_data. To
do that, some relocs stored there need to use bfd_malloc buffers
rather than bfd_alloc ones.
* elf.c (_bfd_elf_free_cached_info): Free relocs.
* elf32-ppc.c (ppc_elf_relax_section): Realloc relocs rather
than malloc, copy, free old.
* elf64-ppc.c (get_relocs): bfd_malloc relocs.
* elflink.c (_bfd_elf_link_info_read_relocs): Always
bfd_malloc relocs.
|
|
This modifies _bfd_elf_free_cached_info to unmap/free section
contents. To do that we need to *not* free sections where contents
are bfd_alloc'd or point to constant strings or somesuch. I've chosen
to implement this be adding another flag to struct bfd_section,
"alloced" to say the section contents can't be freed. Most of the
patch is about setting that flag in many places.
|
|
Do unmap/free cached contents to avoid some memory leaks we'd
otherwise see.
* elf.c (_bfd_elf_munmap_section_contents): Clear pointers to
contents that we unmap/free rather than not unmapping/freeing.
|
|
A few place dealing with ld script handling made some attempt to free
memory, but this was generally ignored and would be quite a lot of
work to implement. Instead, use the stat_obstack rather than
mallocing in many more cases.
* ldexp.c (exp_get_fill): Use stat_alloc for fill.
* ldfile.c (ldfile_try_open_bfd): Don't free yylval fields.
* ldgram.y: Replace xmalloc with stat_alloc throughout.
* ldlang.c (stat_memdup, stat_strdup): New functions.
(ldirname): Use stat_memdup. Don't strdup ".".
(output_section_callback_sort): Use stat_alloc.
(output_section_callback_tree_to_list): Don't free.
(lang_memory_region_lookup): Use stat_strdup.
(lang_memory_region_alias): Likewise.
(add_excluded_libs): Use stat_alloc and stat_memdup.
(ldlang_add_undef, ldlang_add_require_defined): Use stat_strdup.
(lang_add_nocrossref, lang_leave_overlay): Use stat_alloc.
(realsymbol): Use stat_strdup for return value and always
free symbol.
(lang_new_vers_pattern, lang_new_vers_node): Use stat_alloc.
(lang_finalize_version_expr_head): Don't free. Delete FIXME.
(lang_register_vers_node): Don't free.
(lang_add_vers_depend): Use stat_alloc.
(lang_do_version_exports_section): Likewise.
(lang_add_unique): Use stat_alloc and stat_strdup.
(lang_append_dynamic_list): Use stat_alloc.
* ldlang.h (stat_memdup, stat_strdup): Declare.
* ldlex.l: Replace xstrdup with stat_strdup throughout.
Replace xmemdup with stat_memdup too.
* lexsup.c (parse_args): Don't free export list or dynamic
list.
|
|
We never free the tv array.
* plugin.c (plugin_load_plugins): Use stat_alloc.
|
|
|
|
|
|
|
|
|
|
The "of course to free outsymbols" turned out to be wrong. outsymbols
belongs to objcopy which frees them, so commit 6ca01b0bdd59 introduced
a double free.
* srec.c (srec_write_symbols): Don't free outsymbols.
* tekhex.c (tekhex_write_object_contents): Likewise.
|
|
|
|
This simplifies get_frame_unwind_table, changing it to use the
registry 'emplace' method and to pass the initialization iterators to
the constructor. This fixes a build problem on x86 -- reported by the
auto-builder -- as a side effect.
Tested-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Tom de Vries reported that some of the test for the vmov[u|a]p[s|d] were
failing. In my machine xmm3 was consistently set to 0x54, but apparently
that is different depending on the system. This commit zeroes out xmm3
at the start of the test instead.
While debugging the test failures, I also noticed an issue where the
recording wasn't saving all the required memory. That happened because
vmovs[s|d] shares its opcode with vmovap[s|d], meaning they seem to
share code paths, but the latter encodes memory modification size on
VEX.L whereas the former encodes in VEX.pp. So this commit fixed that,
and made the relevant tests more robust and complete.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32561
Approved-By: Guinevere Larsen <guinevere@redhat.com>
|
|
My earlier changes introduced a self-test crash. This patch fixes the
bug by introducing a new method overload into mock_mapped_index.
|
|
After some recent discussions on the mailing list, I've made some
changes to the README to (I hope) provide more clarity.
The changes I made are:
1. Removed the use of a lone 'HOST' on the configure line. I tried
this and 'configure' gave me a warning:
configure: WARNING: you should use --build, --host, --target
So I don't think this is approved practice any more. We should
encourage users to use `--host` instead.
2. Added and reworded the --host, --target, and --enable-targets
descriptions in the 'configure options' section. My goals here are
to clarify that 'cross-debugging' is really the same as 'remote
debugging', and also to make it clearer what the defaults are.
3. Added some additional text to the 'Remote debugging' section
mentioning that 'remote debugging' is basically the same as 'cross
debugging', given that we use 'cross-debugging' in the text above.
Reviewed-By: Keith Seitz <keiths@redhat.com>
|
|
This commit fixes an issue with the commit:
commit d3d13bf876aae425ae0eff2ab0f1af9f7da0264a
Date: Thu Apr 25 09:36:43 2024 +0100
gdb: add gdbarch method to get execution context from core file
The above commit improves GDB's ability to display inferior arguments
when opening a core file, however, if an argument includes white
space, then this is not displayed as well as it should be. For
example:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e e e e e'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 return ret;
(gdb) show args
Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e".
(gdb)
Notice the 'Core was generated by ...' line. In this case it is not
clear if the "e e e e e" is a single argument containing white space,
or 5 single arguments.
But when we 'show args' it is immediately clear that this is a single
argument, as the white space is now escaped.
This problem was caused by the above commit building the argument
string itself, and failing to consider white space escaping.
This commit changes things around, first we place the arguments into
the inferior, then, to print the 'Core was generated by ...' line, we
ask the inferior for the argument string. In this way the quoting is
handled just as it is for 'show args'. The initial output is now:
(gdb) core-file /tmp/corefile-exec-context.2.core
[New LWP 4069711]
Reading symbols from /tmp/corefile-exec-context...
Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007f4f007af625 in raise () from /lib64/libc.so.6
(gdb)
Much better. The existing test is extended to cover this case.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
