| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
REX2.M affects what insn we're actually dealing with, so we better check
this to avoid transforming (future) insns we must not touch.
|
|
With us doing the transformation to an immediate operand for MOV and
various ALU insns, there's little reason to then not support the same
conversion for the other two insns which have respective immediate
operand forms. Unfortunately for IMUL (due to the 0F opcode prefix)
there's no suitable relocation, so the pre-APX forms cannot be marked
for relaxation in the assembler.
|
|
H.J. requested this adjustment; I'm unaware of any specific technical
background.
|
|
Just like was done recently for x86-64 (commit 4998f9ea9d35): Even if
the assembler avoids using the relaxable relocation for inapplicable
insns, the relocation type can still appear for other reasons. Be more
thorough in the opcode checking we do, to avoid bogusly altering other
insns.
Furthermore correct an opcode mask (even if with the added condition
that's now fully benign).
|
|
|
|
The part "... this command by default creates it produces a single ..."
sounds wrong. Replace with "... this command by default produces a
single ...".
Change-Id: I39cc533fa5a2bf473ca9e361ee0e6426d7d37ac6
|
|
Today I learned that, at least on my system (Fedora 40), the printf
"%#x" format will produce "0" rather than "0x0" when given 0 as an
argument.
This causes dwarf-mode.el to not correctly fontify the very first
"Compilation Unit" line it sees.
This patch adapts dwarf-mode.el. As always, this patch bumps the
version number for easier installation.
I am checking this in.
|
|
Change-Id: Ibd8d6c35c2cc02e309f83b11b5fd1172dfa05283
|
|
clang 19 fails to build gdb with this error:
/home/simark/src/binutils-gdb/gdb/compile/compile-object-load.c:302:3: error: cannot initialize a member subobject of type 'void (*)(const char *, ...) __attribute__((noreturn))' with an lvalue of type 'void (const char *, ...)'
302 | link_callbacks_einfo, /* einfo */
| ^~~~~~~~~~~~~~~~~~~~
This illustrates that the bfd_link_callbacks array is missing an entry
for the "fatal" callback, add it.
The fatal field was added very recently, in d26161914 ("PR 32603, more
ld -w misbehaviour"). We're lucky that the new callback was marked with
the noreturn attribute and that clang checks that, otherwise this would
have gone unnoticed.
Change-Id: I68b63d89f2707359e6254da23bdc0776b0e03ba2
|
|
While working on another series, I discovered that the existing code
in gdb.ada/complete.exp that conditionally accepts a completion does
not work correctly. The code assumes that wrapping a line in "(...)?"
will make the entire line optional, but really this will only match a
blank line.
Meanwhile, I needed this same patch for a second series I'm working
on, so I've pulled this out. As it only affects Ada, I am going to
check it in.
|
|
I noticed a non-bool-like use of target_get_tib_address in
windows-tdep.c. After fixing this I thought it would be good to
document the target method; and this also lead to some non-bool-like
commentary in remote.c. This patch fixes all of these nits.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Now that stabs is deprecated, we should probably warn our users of it
before removing support, so that they have time to react and either make
themselves heard, or fix things on their end so that they can still debug
their applications.
This commit adds a new function that emits a warning whenever GDB does
stabs reading. Since there are several places where stabs is
re-invented, this warning had to be added to many places, but I think I
managed to warn everywhere relevant without duplicating warnings.
Also, the test gdb.stabs/weird.exp explicitly checks for GDB warnings
when reading stabs, so it had to be updated to account for the
deprecation warning. It is done generically, since it will be removed in
the next release anyway.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
pr30117 showed one of the assertions added by 4d1bb7955a8b was too
strict. oss-fuzz also found the second assertion to be too strict,
with this testcase distilled from 7k of garbage source:
A=%eax%%!
Y=A
Z=A
or $6,Z
PR 32721
* config/tc-i386.c (parse_register): Move "know" into
condition. Simplify.
|
|
Right now, cooked_index_functions::expand_symtabs_matching computes
the language for each component of a split name, using the language of
the corresponding entry.
Instead, I think that we want to do all the comparisons using the
final entry's language. I don't think there's a way to trigger bad
behavior here right now, but with another series I'm working on, we
end up with some entries whose language can't reliably be determined;
and in this case using the final entry's language avoids issues.
I suspect we could also dispense with the per-segment name-matcher
lookup as well.
|
|
This changes the various producer-checking functions to be methods on
dwarf2_cu. It adds a few new caching members as well -- every one
that could reasonably be done this way has been converted, with the
only exception being a gdbarch hook.
Note the new asserts in the accessors. Without the earlier
prepare_one_comp_unit change, these could trigger in some modes.
|
|
This changes prepare_one_comp_unit to be a private method of
cutu_reader. This should make it somewhat simpler to reason about.
|
|
Currently, prepare_one_comp_unit is called somewhat haphazardly: it is
mostly called when a CU is read, but some places manage to instantiate
a cutu_reader* without calling it, and some code (e.g.,
read_file_scope) calls it without really needing to.
Aside from contributing to the general confusion around CU reading,
this doesn't really cause problems in the current tree. However, it
is possible for the DWARF reader to check the CU's producer before it
is ever set -- which is certainly unintended.
|
|
This moves the producer_is_realview to producer.c.
|
|
In dwarf2/read.c:new_symbol, DW_TAG_namelist is listed in the same
part of the "switch" as other tags. However, it effectively shares no
code with these. This patch splits it into its own case.
Longer term I think new_symbol should be split up drastically.
|
|
|
|
gas/
* config/tc-avr.c (md_assemble): Fix indentation.
|
|
When using the MI interpreter, if someone was to attach to a ROCm
process which has active GPU waves, GDB would issue a segfault as
follows:
attach 1994813
&"attach 1994813\n"
~"Attaching to process 1994813\n"
=thread-group-started,id="i1",pid="1994813"
=thread-created,id="1",group-id="i1"
=thread-created,id="2",group-id="i1"
~"[New LWP 1994828]\n"
*running,thread-id="2"
=thread-created,id="3",group-id="i1"
~"[New LWP 1994825]\n"
*running,thread-id="3"
=thread-created,id="4",group-id="i1"
~"[New LWP 1994823]\n"
*running,thread-id="4"
^done
=library-loaded,...
[...]
~"[Thread debugging using libthread_db enabled]\n"
~"Using host libthread_db library \"/lib/x86_64-linux-gnu/libthread_db.so.1\".\n"
=thread-created,id="5",group-id="i1"
&"\n\n"
&"Fatal signal: "
&"Segmentation fault"
&"\n"
&"----- Backtrace -----\n"
&"Backtrace unavailable\n"
&"---------------------\n"
&"A fatal error internal to GDB has been detected, further\ndebugging is not possible. GDB will now terminate.\n\n"
&"This is a bug, please report it."
&" For instructions, see:\n"
&"<https://github.com/ROCm-Developer-Tools/ROCgdb/issues>"
&"."
&"\n\n"
Segmentation fault
The issue comes from using a non-initialized pointer in mi_on_resume_1:
if (!mi->running_result_record_printed && mi->mi_proceeded)
{
gdb_printf (mi->raw_stdout, "%s^running\n",
mi->current_token ? mi->current_token : "");
}
In this instance, "mi->current_token" has an uninitialized value. This is a
regression introduced by:
commit def2803789208a617c429b5dcf2026decb25ce0c
Date: Wed Sep 6 11:02:00 2023 -0400
gdb/mi: make current_token a field of mi_interp
Before this patch, current_token was a global implicitly 0-initialized. Since
it is now a class field, it is not 0-initialized by default anymore. This
patch changes this.
Change-Id: I3f00b080318a70405d881ff0abe02b2c5cb1f9d8
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I was trying to get an understanding of which CUs were expanded when,
and how much time it was taking. I wrote this patch to add some logging
related to that, and I think it would be useful to have upstream, to
better understand performance problems related to over-eager CU
expansion, for example.
- add DWARF_READ_SCOPED_DEBUG_START_END
- use it in process_queue, to wrap the related expansion messages
together
- add a message in maybe_queue_comp_unit when enqueuing a comp unit
- add timing information to messages in process_queue, indicating how
much time it took to expand a given symtab
- count the number of expansions done in a single call to process_queue
[dwarf-read] process_queue: start: Expanding one or more symtabs of objfile /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw-form-ref-addr-with-type-units/dw-form-ref-addr-with-type-units ...
[dwarf-read] process_queue: Expanding symtab of CU at offset 0xc
[dwarf-read] maybe_queue_comp_unit: Queuing CU for expansion: section offset = 0x38b, queue size = 2
[dwarf-read] process_queue: Done expanding CU at offset 0xc, took 0.001s
[dwarf-read] process_queue: Expanding symtab of CU at offset 0x38b
[dwarf-read] process_queue: Done expanding CU at offset 0x38b, took 0.000s
[dwarf-read] process_queue: Done expanding 2 symtabs.
[dwarf-read] process_queue: end: Expanding one or more symtabs of objfile /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/dw-form-ref-addr-with-type-units/dw-form-ref-addr-with-type-units ...
Change-Id: I5237d50e0c1d06be33ea83a9120b5fe1cf7ab8c2
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This makes it more obvious that all created signatured_type objects have
this flag set.
Also, remove an unnecessary assignment in create_cus_hash_table: when
constructing the dwarf2_per_cu_data object, is_debug_types is already
initialized to 0/false.
Change-Id: I6d28b17ac77edc040172254f6970d05ebc4a47f4
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Same as the previous patch, but for the containing section.
Change-Id: I469147cce21525d61b3cf6edd9a9f4b12027c176
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Similar to the previous patch, but for the offset within the containing
section.
Change-Id: I1d76e1f88002bca924e0b12fd78c7ea49d36c0ec
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Pass a dwarf2_per_bfd to the constructor of dwarf2_per_cu_data and set
the per_bfd field there. All "real" instantiations of
dwarf2_per_cu_data must have a valid, non-nullptr dwarf2_per_bfd
backlink, this makes it a bit more obvious. The instantiations of
dwarf2_per_cu_data that receive a nullptr dwarf2_per_bfd are the ones
used to do hash map lookups and the ones used in selftests.
Remove an unnecessary assignment of per_bfd in
fill_in_sig_entry_from_dwo_entry: the per_bfd field is already set when
the signatured_type object is constructor (before that, it was set in
allocate_signatured_type).
Change-Id: Ifeebe55fdb1bc2de4de9c852033fafe8abdfde8a
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that the following functions accept a "dwarf2_per_objfile",
but they can actually accept a less specific "dwarf2_per_bfd". This
makes it more obvious that the work they do is per BFD and not per
objfile.
- add_type_unit
- lookup_dwo_file_slot
- create_dwo_unit_in_dwp_v1
- create_dwp_v2_or_v5_section
- create_dwo_unit_in_dwp_v2
- create_dwo_unit_in_dwp_v5
- lookup_dwo_unit_in_dwp
Change-Id: I200cd77850ce0ffa29fc1b9d924056fdce2559f8
Approved-By: Tom Tromey <tom@tromey.com>
|
|
No behavior changes expected.
Change-Id: I16ff6c67058362c65cc8edb05d1948e48be6b2e1
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This change makes it possible to debug PE executables run in e.g. Qemu
without needing to set osabi to none, it breaks backtrace
and commands like finish if frame pointers are not present but SEH unwind info is.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The maximum number of load/store watchpoints and fetch instruction
watchpoints is 14 each according to LoongArch Reference Manual [1],
so extend the maximum number of hardware watchpoints from 8 to 14.
A new struct user_watch_state_v2 was added into uapi in the related
kernel commit 531936dee53e ("LoongArch: Extend the maximum number of
watchpoints") [2], but there may be no struct user_watch_state_v2 in
the system header in time. Modify the struct loongarch_user_watch_state
in GDB which is same with the uapi struct user_watch_state_v2.
As far as I can tell, the only users for this struct in the userspace
are GDB and LLDB, there are no any problems of software compatibility
between the application and kernel according to the analysis.
The compatibility problem has been considered while developing and
testing. When the applications in the userspace get watchpoint state,
the length will be specified which is no bigger than the sizeof struct
user_watch_state or user_watch_state_v2, the actual length is assigned
as the minimal value of the application and kernel in the generic code
of ptrace:
kernel/ptrace.c: ptrace_regset():
kiov->iov_len = min(kiov->iov_len,
(__kernel_size_t) (regset->n * regset->size));
if (req == PTRACE_GETREGSET)
return copy_regset_to_user(task, view, regset_no, 0,
kiov->iov_len, kiov->iov_base);
else
return copy_regset_from_user(task, view, regset_no, 0,
kiov->iov_len, kiov->iov_base);
For example, there are four kind of combinations, all of them work well.
(1) "older kernel + older app", the actual length is 8+(8+8+4+4)*8=200;
(2) "newer kernel + newer app", the actual length is 8+(8+8+4+4)*14=344;
(3) "older kernel + newer app", the actual length is 8+(8+8+4+4)*8=200;
(4) "newer kernel + older app", the actual length is 8+(8+8+4+4)*8=200.
BTW, LLDB also made this change in the related commit ff79d83caeee
("[LLDB][LoongArch] Extend the maximum number of watchpoints") [3]
[1] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=531936dee53e
[3] https://github.com/llvm/llvm-project/commit/ff79d83caeee
Signed-off-by: Hui Li <lihui@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
plus a few other formatting fixes.
|
|
It is possible with fuzzed files to have num_debug_info_entries zero
after allocating space for debug_information, leading to multiple
allocations.
* dwarf.c (process_debug_info): Don't test num_debug_info_entries
to determine whether debug_information has been allocated,
test alloc_num_debug_info_entries.
|
|
GDB prints the target id of a thread in various places such as the
output of the "info threads" command in the "Target Id" column or when
switching to a thread. A target can define what to print for a given
ptid by overriding the `pid_to_str` method.
The remote target is a gateway behind which one of many various
targets could be running. The remote target converts a given ptid to
a string in a uniform way, without consulting the low target at the
server-side.
In this patch we introduce a new attribute in the XML that is sent in
response to the "qXfer:threads:read" RSP packet, so that a low target
at the server side, if it wishes, can specify what to print as the
target id of a thread.
Note that the existing "name" attribute or the "extra" text provided
in the XML are not sufficient for the server-side low target to
achieve the goal. Those attributes, when present, are simply appended
to the target id by GDB.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
|
|
--disable-default-stack is an alias for --enable-default-execstack=no.
The existing check only looked for the latter config option.
PR 32715
* testsuite/ld-elf/elf.exp (target_defaults_to_execstack): Look
in config.h for result of --enable-default-execstack.
|
|
PR binutils/32716
* bucomm.c (display_info): Free arg.info.
|
|
NULL is a possible return from bfd_section_already_linked_table_lookup
if out-of-memory.
PR 32703
* linker.c (_bfd_generic_section_already_linked): Catch
bfd_section_already_linked_table_lookup failure.
* coffgen.c (_bfd_coff_section_already_linked): Likewise.
|
|
If there is a large number of threads in the input program, the expect
buffer in `get_mi_thread_list` would become full. Prevent this by
consuming the buffer in small pieces.
Regression-tested using the gdb.mi tests.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
In test-case gdb.base/gstack.exp we start a gdb implicitly using
prepare_for_testing.
The gdb is not really used, but its spawn_id (available in variable
gdb_spawn_id) is used in a gdb_test_multiple, which is used to interact with
the gstack process.
Usually, a running gdb is cleaned up at test-case exit in gdb_finish, which
calls gdb_exit, which by default calls gdb_default_exit, which does
'send_gdb "quit\n"'.
However, this sends a quit to the host process expect is currently talking to,
defined by board_info(host,fileid), and after spawning gstack that's gstack, not
gdb.
Fix this by:
- using build_executable instead of prepare_for_testing to not spawn an unused
gdb, and
- changing the gdb_test_multiple into a gdb_expect, eliminating the implicit use
of gdb_spawn_id.
Tested on x86_64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
PR testsuite/32709
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32709
|
|
Fix typos:
...
overriden -> overridden
reate -> create
...
Tested on x86_64-linux.
I
|
|
Without
commit 230a788eb28a64d628e623068c44add2a24aa5d3
Author: Alan Modra <amodra@gmail.com>
Date: Tue Feb 18 08:54:06 2025 +1030
PR32690, assertion failure in lang_size_relro_segment
this test triggers the linker error:
.../ld: internal error .../ld/ldlang.c 6618
collect2: error: ld returned 1 exit status
with GCC 10 or above on x86-64.
PR ld/32690
* testsuite/ld-elf/elf.exp: Run PR ld/32690 tests.
* testsuite/ld-elf/pr32690.h: New file.
* testsuite/ld-elf/pr32690a.c: Likewise.
* testsuite/ld-elf/pr32690b.c: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
|
|
Fix another one for aarch64.
|
|
Some of these aren't relevant to the relro bug. Some are. They all
matter if early estimation of section layout needs to be good.
PR ld/32690
* elf32-bfin.c (bfin_adjust_dynamic_symbol),
* elf32-hppa.c (elf32_hppa_late_size_sections),
* elf32-microblaze.c (microblaze_elf_adjust_dynamic_symbol),
* elf32-nds32.c (nds32_elf_adjust_dynamic_symbol),
* elf64-ppc.c (size_global_entry_stubs),
* elflink.c (_bfd_elf_tls_setup),
* elfxx-mips.c (mips_elf_add_la25_intro),
(mips_elf_add_la25_trampoline),
(_bfd_mips_elf_adjust_dynamic_symbol),
* elfxx-x86.c (_bfd_x86_elf_late_size_sections): Use
bfd_link_align_section to ensure correct output section
alignment.
|
|
|
|
I noticed when making the change from "einfo" to "fatal" that the
alignment error in _bfd_elf_link_create_gnu_property_sec lacked a %P,
and then decided that a bfd_set_section_alignment that can't happen
does not merit a separate error message. elfxx-x86.c had copied the
same code, so fix that too. In fact, every bfd_set_section_alignment
call in elfxx-x86.c will always return true absent some future
programming error. This patch makes those that accompany making a
section lose their "failed to align " error and share the "failed to
create" error. Those that are changing alignment of a section created
elsewhere now abort on bfd_set_section_alignment returning false.
|
|
Commit 8d97c1a53f3d claimed to replace all einfo calls using %F with
a call to fatal. It did so only for the ld/ directory. This patch
adds a "fatal" to linker callbacks, and replaces those calls in bfd/
too.
|
|
This introduces a new function which should be used whenever the
linker needs to increase section alignment after mapping input to
output sections.
PR ld/32690
* linker.c (bfd_link_align_section): New function.
* elflink.c (_bfd_elf_adjust_dynamic_copy): Use it.
* bfd-in2.h: Regenerate.
|
|
Change-Id: I9a6bf27b72f7efb1cc4cea5345db14969e794bdb
|
|
Change-Id: I420280721cb734a2e061743309bf9b25d2179f8f
|
