binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Tom Tromey	efd3baf0dc	Replace input_interactive_p with a method This replaces the global input_interactive_p function with a new method ui::input_interactive_p.	4 years ago
Tom Tromey	8f7f9b3a91	Remove ui_register_input_event_handler This patch removes ui_register_input_event_handler and ui_unregister_input_event_handler, replacing them with methods on 'ui'. It also changes gdb to use these methods everywhere, rather than sometimes reaching in to the ui to manage the file descriptor directly.	4 years ago
Claudiu Zissulescu	bbcab3366b	opcodes/arc: Implement style support in the disassembler Update the ARC disassembler to supply style information to the disassembler output. The output formatting remains unchanged. opcodes/ChangeLog: * disassemble.c (disassemble_init_for_target): Set created_styled_output for ARC based targets. * arc-dis.c (find_format_from_table): Use fprintf_styled_ftype instead of fprintf_ftype throughout. (find_format): Likewise. (print_flags): Likewise. (print_insn_arc): Likewise. Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>	4 years ago
Claudiu Zissulescu	5154216259	arc: Update missing cipher. The ciphers 5,7, and 9 are missing when parsing an assembly instruction leading to errors when those ciphers are used. gas/config * tc-arc.c (md_assembly): Update strspn string with the missing ciphers. Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>	4 years ago
Tom de Vries	9a14143c59	[gdb/testsuite] Remove duplicate of supports_gnuc In commit `9d9dd861e9` ("[gdb/testsuite] Fix regression in step-indirect-call-thunk.exp with gcc 7") I accidentally committed a duplicate of supports_gnuc, which caused: ... DUPLICATE: gdb.base/gdb-caching-proc.exp: supports_gnuc: consistency ... Fix this by removing the duplicate. Tested on x86_64-linux.	4 years ago
Andrew Burgess	602d2b520d	gdb/python: look for python, then python 3 at configure time It is possible that a system might have a python3 executable, but no python executable. For example, on my Fedora system the python2 package provides /usr/bin/python2, the python3 package provides /usr/bin/python3, and the python-unversioned-command package provides /usr/bin/python, which picks between python2 and python3. It is quite possible to only have python3 available on a system. Currently, when GDB configures, it looks for a 'python' executable. If non is found then GDB will be built without python support. Or the user needs to configure using --with-python=/usr/bin/python3. This commit updates GDB's configure.ac script to first look for 'python', and then 'python3'. Now, on a system that only has a python3 executable, GDB will automatically find, and use that in order to provide python support, no user supplied configure arguments are needed. I've tested this on my local machine by removing the python-unversioned-command package, confirming that there is no longer a 'python' executable in my $PATH, and then rebuilding GDB from scratch. GDB with this patch has python support.	4 years ago
Jan Beulich	7e864bf71d	x86: correct VMOVSH attributes Both forms were missing VexW0 (thus allowing Evex.W=1 to be encoded by suitable means, which would cause #UD). The memory operand form further was using the wrong Masking value, thus allowing zeroing-masking to be encoded for the store form (which would again cause #UD).	4 years ago
Jan Beulich	37cea58867	x86: re-order insn template fields This saves quite a number of shift instructions: The "operands" field can now be retrieved by just masking (no shift), and extracting the "extension_opcode" field now only requires a (signed) right shift, with no prereq left one. (Of course there may be architectures where, in a cross build, there might be no difference at all, e.g. when there are suitable bitfield extraction insns.)	4 years ago
Tom de Vries	4319180c81	[gdbsupport] Improve thread scheduling in parallel_for_each When running a task using parallel_for_each, we get the following distribution: ... Parallel for: n_elements: 7271 Parallel for: minimum elements per thread: 10 Parallel for: elts_per_thread: 1817 Parallel for: elements on worker thread 0 : 1817 Parallel for: elements on worker thread 1 : 1817 Parallel for: elements on worker thread 2 : 1817 Parallel for: elements on worker thread 3 : 0 Parallel for: elements on main thread : 1820 ... Note that there are 4 active threads, and scheduling elts_per_thread on each of those handles 4 * 1817 == 7268, leaving 3 "left over" elements. These leftovers are currently handled in the main thread. That doesn't seem to matter much for this example, but for say 10 threads and 99 elements, you'd have 9 threads handling 9 elements and 1 thread handling 18 elements. Instead, distribute the left over elements over the worker threads, such that we have: ... Parallel for: elements on worker thread 0 : 1818 Parallel for: elements on worker thread 1 : 1818 Parallel for: elements on worker thread 2 : 1818 Parallel for: elements on worker thread 3 : 0 Parallel for: elements on main thread : 1817 ... Tested on x86_64-linux.	4 years ago
Tom de Vries	c3d3b64b34	[gdb/testsuite] Allow override of ASAN_OPTIONS in lib/gdb.exp Use set_sanitizer_default for ASAN_OPTIONS in lib/gdb.exp. This allows us to override the default detect_leaks=0 setting, by manually doing: ... $ export ASAN_OPTIONS=detect_leaks=1 $ make check ... Tested on x86_64-linux, by building with -fsanitize=address and running test-case gdb.dwarf2/gdb-add-index.exp with and without "export ASAN_OPTIONS=detect_leaks=1".	4 years ago
Tom de Vries	9d9dd861e9	[gdb/testsuite] Fix regression in step-indirect-call-thunk.exp with gcc 7 Since commit `43127ae571` ("Fix gdb.base/step-indirect-call-thunk.exp") I run into: ... gdb compile failed, gcc: error: unrecognized command line option \ '-fcf-protection=none'; did you mean '-flto-partition=none'? UNTESTED: gdb.base/step-indirect-call-thunk.exp: failed to prepare ... The problem is that -fcf-protection is supported starting gcc 8, but I'm using system gcc 7.5.0. Fix this by only adding -fcf-protection=none for gcc 8 and later. Tested on x86_64-linux, with gcc 7.5.0, 8.2.1 and 12.1.1.	4 years ago
Tom de Vries	68a5118c48	[gdb/testsuite] Fix gdb.arch/i386-mpx.exp Since commit `c4a3dbaf11` ("Expose current 'print' settings to Python") we have: ... (gdb) print /x $bnd0 = {0x10, 0x20}^M $22 = {lbound = 0x10, ubound = 0x20} : size 0x11^M (gdb) FAIL: gdb.arch/i386-mpx.exp: verify size for bnd0 ... The regexp in the test-case expects "size 17". Fix this by updating the regexp. Tested on x86_64-linux.	4 years ago
Tom de Vries	53944a3bf5	[gdbsupport] Add parallel_for_each_debug Add a parallel_for_each_debug variable, set to false by default. With an a.out compiled from hello world, we get with parallel_for_each_debug == true: ... $ gdb -q -batch a.out -ex start ... Parallel for: n_elements: 7271 Parallel for: minimum elements per thread: 10 Parallel for: elts_per_thread: 1817 Parallel for: elements on worker thread 0 : 1817 Parallel for: elements on worker thread 1 : 1817 Parallel for: elements on worker thread 2 : 1817 Parallel for: elements on worker thread 3 : 0 Parallel for: elements on main thread : 1820 Temporary breakpoint 1, main () at /home/vries/hello.c:6 6 printf ("hello\n"); ... Tested on x86_64-linux.	4 years ago
GDB Administrator	38733fdc8c	Automatic date update in version.in	4 years ago
GDB Administrator	f39cc214d5	Automatic date update in version.in	4 years ago
GDB Administrator	c3359b8b95	Automatic date update in version.in	4 years ago
Aaron Merey	92b0a182fe	gdb-add-index always generates an error when libdebuginfod wasn't compiled in gdb-add-index runs gdb with -iex 'set debuginfod enabled off'. If gdb is not compiled against libdebuginfod this causes an unnecessary error message to be printed to stderr indicating that gdb was not built with debuginfod support. Fix this by changing the 'set debuginfod enabled off' command to a no-op when gdb isn't built with libdebuginfod.	4 years ago
Bruno Larsen	13c3e10f98	gdb/testsuite: modernize gdb.base/maint.exp gdb.base/maint.exp was using several gdb_expect statements, probably because this test case predates the existance of gdb_test_multiple. This commit updates the test case to use gdb_test_multiple, making it more resilient to internal errors and such. The only gdb_expect left in the testcase is one that specifically looks for an internal error being triggered as a PASS.	4 years ago
Tom Tromey	3028a2dbbf	Add 'nibbles' to gdb.print_options When I rebased and updated the print_options patch, I forgot to update print_options to add the new 'nibbles' feature to the result. This patch fixes the oversight. I'm checking this in.	4 years ago
Carl Love	ebbac1687d	PowerPC: Add support for IEEE 128-bit format. The test gdb.base/infcall-nested-structs-c.exp fails on a gdb assert in function ppc64_sysv_abi_return_value in file gdb/ppc-sysv-tdep.c. The assert is due to the missing IEEE 128-bit support in file gdb/ppc-sysv-tdep.c. The IBM long double was the initial float 128-bit support added by IBM The IEEE 128-bit support, which is similar IBM long double support, was made the default starting with GCC 12. The floating point format differences include the number of bits used to encode the exponent and significand. Also, IBM long double values are passed in a pair of floating point registers. The IEEE 128-bit value is passed in a single vector register. This patch fixes the gdb_assert (ok); in function ppc64_sysv_abi_return_value in gdb/ppc-sysv-tdep.c by adding IEEE FLOAT 128-bit type support for PowerPC. The patch has been tested on Power 10, ELFv2. It fixes the following list of regression failures on Power 10: gdb.base/infcall-nested-structs-c.exp 192 gdb.base/infcall-nested-structs-c++.exp 76 gdb.base/structs.exp 9 The patch has been tested on Power 8 BE which is ELFv1.	4 years ago
Tom Tromey	72be9d6be7	Add 'summary' mode to Value.format_string This adds a 'summary' mode to Value.format_string and to gdb.print_options. For the former, it lets Python code format values using this mode. For the latter, it lets a printer potentially detect if it is being called in a backtrace with 'set print frame-arguments' set to 'scalars'. I considered adding a new mode here to let a pretty-printer see whether it was being called in a 'backtrace' context at all, but I'm not sure if this is really desirable.	4 years ago
Tom Tromey	c4a3dbaf11	Expose current 'print' settings to Python PR python/17291 asks for access to the current print options. While I think this need is largely satisfied by the existence of Value.format_string, it seemed to me that a bit more could be done. First, while Value.format_string uses the user's settings, it does not react to temporary settings such as "print/x". This patch changes this. Second, there is no good way to examine the current settings (in particular the temporary ones in effect for just a single "print"). This patch adds this as well. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17291	4 years ago
Carl Love	aa63b0a77e	PowerPC: fix for gdb.base/eh_return.exp Disable the Traceback Table generation on PowerPC for this test. The Traceback Table consists of a series of bit fields to indicate things like the Traceback Table version, language, and specific information about the function. The Traceback Table is generated following the end of the code for every function by default. The Traceback Table is defined in the PowerPC ELF ABI and is intended to support debuggers and exception handlers. The Traceback Table is displayed in the disassembly of functions by default and is part of the function length. The table is typically interpreted by the disassembler as data represented by .long xxx entries. Generation of the Traceback Table is disabled in this test using the PowerPC specific gcc compiler option -mtraceback=no, the xlc option additional_flags-qtable=none and the clang optons -mllvm -xcoff-traceback-table=false. Disabling the Traceback Table generation in this test results in the gdb_test_multiple statement correctly locating the address of the bclr instruction before the statement "End of assembler dump." in the disassembly output.	4 years ago
Tom Tromey	bf4d777d39	Run 'black' on gdb Running 'black' on gdb fixed a couple of small issues. This patch is the result.	4 years ago
GDB Administrator	9afca381e2	Automatic date update in version.in	4 years ago
Tom de Vries	7d1a572d6b	[gdb/symtab] Fix data race in cooked_index_functions::expand_symtabs_matching When building gdb with -fsanitize-threads and running test-case gdb.ada/char_enum_unicode.exp, I run into: ... WARNING: ThreadSanitizer: data race (pid=21301)^M Write of size 8 at 0x7b2000008080 by main thread:^M #0 free <null> (libtsan.so.2+0x4c5e2)^M #1 _dl_close_worker <null> (ld-linux-x86-64.so.2+0x4b7b)^M #2 convert_between_encodings() charset.c:584^M ... #21 cooked_index_functions::expand_symtabs_matching() read.c:18606 ... This is fixed by making cooked_index_functions::expand_symtabs_matching wait for the cooked index finalization to be done. Tested on x86_64-linux. https://sourceware.org/bugzilla/show_bug.cgi?id=29311 https://sourceware.org/bugzilla/show_bug.cgi?id=29286	4 years ago
Tom de Vries	18a5766d09	[gdbsupport] Add sequential_for_each Add a sequential_for_each alongside the parallel_for_each, which can be used as a drop-in replacement. This can be useful when debugging multi-threading behaviour, and you want to limit multi-threading in a fine-grained way. Tested on x86_64-linux, by using it instead of the parallel_for_each in dwarf2_build_psymtabs_hard.	4 years ago
Tiezhu Yang	e24500cbab	gdb: Document floating-point support for LoongArch Update NEWS and gdb.texinfo to document floating-point support for LoongArch. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>	4 years ago
Tom de Vries	2df41bda2f	[gdb/build] Fix gdb build with gcc 4.8.5 When building gdb with gcc 4.8.5, we run into: ... In file included from /usr/include/c++/4.8/future:43:0, from gdbsupport/thread-pool.h:30, from gdb/dwarf2/cooked-index.h:33, from gdb/dwarf2/read.h:26, from gdb/dwarf2/abbrev-cache.c:21: /usr/include/c++/4.8/atomic: In instantiation of \ ‘_Tp std::atomic<_Tp>::load(std::memory_order) const [with _Tp = \ packed<dwarf_unit_type, 1ul>; std::memory_order = std::memory_order]’: gdb/dwarf2/read.h:332:44: required from here /usr/include/c++/4.8/atomic:208:13: error: no matching function for call to \ ‘packed<dwarf_unit_type, 1ul>::packed()’ _Tp tmp; ^ ... Fix this by adding the default constructor for packed. Tested on x86_64-linux, with gdb build with gcc 4.8.5.	4 years ago
Tom de Vries	14dd1080c6	[gdb/symtab] Make per_cu->m_lang atomic When building gdb with -fsanitize=thread and running test-case gdb.dwarf2/inlined_subroutine-inheritance.exp, we run into a data race between: ... Read of size 1 at 0x7b2000003010 by thread T4: #0 packed<language, 1ul>::operator language() const packed.h:54 #1 dwarf2_per_cu_data::set_lang(language) read.h:363 ... and: ... Previous write of size 1 at 0x7b2000003010 by main thread: #0 dwarf2_per_cu_data::set_lang(language) read.h:365 ... Fix this by making per_cu->m_lang atomic. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29286	4 years ago
Tom de Vries	b35bd7d552	[gdb/symtab] Make per_cu->unit_type atomic With gdb with -fsanitize=thread and test-case gdb.ada/array_bounds.exp, I run into a data race between: ... Read of size 1 at 0x7b2000025f0f by main thread: #0 packed<dwarf_unit_type, 1ul>::operator dwarf_unit_type() const packed.h:54 #1 dwarf2_per_cu_data::set_unit_type(dwarf_unit_type) read.h:339 ... and: ... Previous write of size 1 at 0x7b2000025f0f by thread T3: #0 dwarf2_per_cu_data::set_unit_type(dwarf_unit_type) read.h:341 ... Fix this by making per_cu->unit_type atomic. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29286	4 years ago
Tom de Vries	4f92e10cda	[gdb/symtab] Fix data race in ~charset_vector When doing: ... $ gdb ./outputs/gdb.ada/char_enum_unicode/foo -batch -ex "break foo.adb:26" ... with a gdb build with -fsanitize=thread I run into a data race: ... WARNING: ThreadSanitizer: data race (pid=30917) Write of size 8 at 0x7b0400004070 by main thread: #0 free <null> (libtsan.so.2+0x4c5e2) #1 xfree<char> gdbsupport/gdb-xfree.h:37 (gdb+0x650f17) #2 charset_vector::clear() gdb/charset.c:703 (gdb+0x651354) #3 charset_vector::~charset_vector() gdb/charset.c:697 (gdb+0x6512d3) #4 <null> <null> (libtsan.so.2+0x32643) #5 captured_main_1 gdb/main.c:1310 (gdb+0xa3975a) ... The problem is that we're freeing the charset_vector elements in the destructor, which may still be used by a worker thread. Fix this by not freeing the charset_vector elements in the destructor. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29311	4 years ago
Alan Modra	5f6c92298a	Re: PowerPC: implement md_operand to parse register names I meant to make this change before committing, to let compilers know the code on the false branch of md_parse_name is dead. * config/tc-ppc.c (ppc_parse_name): Return void. * config/tc-ppc.h (md_parse_name): Always true. (ppc_parse_name): Update prototype.	4 years ago
Alan Modra	00b37cc41e	PowerPC: implement md_operand to parse register names Allows register names to appear in symbol assignments, so for example tocp = %r2 mr %r3,tocp now assembles. * gas/config/tc-ppc.c (REG_NAME_CNT): Delete, replace uses with ARRAY_SIZE. (register_name): Rename to.. (md_operand): ..this. Only handle %reg. (cr_names): Rename to.. (cr_cond): ..this. Just keep conditions. (ppc_parse_name): Add mode param. Search both cr_cond and pre_defined_registers. Handle absolute and register symbol values here rather than in expr.c:operand(). (md_assemble): Don't special case register name matching in operands, except to set cr_operand as appropriate. * gas/config/tc-ppc.h (md_operand): Don't define. (md_parse_name, ppc_parse_name): Update. * read.c (pseudo_set): Copy over entire O_register value. * testsuite/gas/ppc/regsyms.d. * testsuite/gas/ppc/regsyms.s: New test. * testsuite/gas/ppc/ppc.exp: Run it.	4 years ago
GDB Administrator	869fa2b36c	Automatic date update in version.in	4 years ago
Pedro Alves	9779607aff	Tighten gdb.threads/no-unwaited-for-left.exp regexps A WIP version of a patch (https://sourceware.org/pipermail/gdb-patches/2022-June/190202.html) resulted in a bug that went unnoticed by the testuite, like so: (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: enable scheduler-locking, for main thread continue Continuing. [New Thread 1251861.1251861] No unwaited-for children left. (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits info threads Id Target Id Frame 3 Thread 1251861.1251863 "no-unwaited-for" __pthread_clockjoin_ex (threadid=140737351558976, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145 4 Thread 1251861.1251861 "no-unwaited-for" <unavailable> in ?? () The current thread <Thread ID 1> has terminated. See `help thread'. (gdb) PASS: gdb.threads/no-unwaited-for-left.exp: only thread 3 left, main thread terminated Somehow, above, GDB re-added the zombie leader back before printing "No unwaited-for children left.". The "only thread 3 left, main thread terminated" test should have caught this, but didn't. That is because the test's regexp has a ".*" after the part that matches thread 3. This commit tightens that regexp to catch such a bug. It also tightens the "only main thread left, thread 2 terminated" test's regexp in the same way. Change-Id: I8744f327a0aa0e2669d1ddda88247e99b91cefff	4 years ago
Carl Love	2b8b0dca3b	Fix for gdb.base/stap-probe.c On PowePC, the test fails on a compile error: /../binutils-gdb-current/gdb/testsuite/gdb.base/stap-probe.c:107:1: error: expected '=', ',', ';', 'asm' or 'attribute' before 'use_xmm_reg' 107 \| use_xmm_reg (int val) \| ^~~~~~~~~~~ Where the source code for stap-probe.c is: static const char * __attribute__((noinline)) ATTRIBUTE_NOCLONE use_xmm_reg (int val) <-- line 107 { ... The issue is the ATTRIBUTE_NOCLONE is not defined as an attribute as expected. The #define for ATTRIBUTE_NOCLONE can be found in ../lib/attributes.h. This patch adds the missing include statement for the definition of ATTRIBUTE_NOCLONE. The patch has been tested and verified on a Power10 system.	4 years ago
Carl Love	485caa08c0	Add PowerPC support to gdb.cp/call-method-register.cc This patch adds the needed define ASM_REG for PowerPC. The patch was run on a Power 10 system. The gdb Summary for the run lists 2 expected passes, no unexpected failures or untested testcases. Please let me know if this patch is acceptable for mainline. Carl Love	4 years ago
Carl Love	43127ae571	Fix gdb.base/step-indirect-call-thunk.exp Due to recent changes in the default value of -fcf-protection for gcc, the test gdb.base/step-indirect-call-thunk.exp fails on Intel X86-64 with the error: Executing on host: gcc -fno-stack-protector -fdiagnostics-color=never -mindirect-branch=thunk -mfunction-return=thunk -c -g -o /.../gdb/testsuite/outputs/gdb.base/step-indirect-call-thunk/step-indirect-call-thunk0.o /.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c (timeout = 300) builtin_spawn -ignore SIGHUP gcc -fno-stack-protector -fdiagnostics-color=never -mindirect-branch=thunk -mfunction-return=thunk -c -g -o /.../gdb/testsuite/outputs/gdb.base/step-indirect-call-thunk/step-indirect-call-thunk0.o /.../binutils-gdb-current/gdb/testsuite/gdb.base/step-indirect-call-thunk.c /.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c: In function 'inc': /.../gdb/testsuite/gdb.base/step-indirect-call-thunk.c: 22:1: error: '-mindirect-branch' and '-fcf-protection' are not compatible 22 \| { /* inc.1 */ As stated in the error message the default "-fcf-protection" and "-mindirect-branch' are in compatible. The fcf-protection argument needs to be "-fcf-protection=none" for the test to compile on Intel. The gcc command line "-mindirect-branch' is an Intel specific and will give an error on other platforms. A check for X86 is added so the test will only run on X86 platforms. The patch has been tested and verified on Power 10 and Intel X86-64 systems with no regressions.	4 years ago
Pedro Alves	0f443d1b70	Fix "until LINE" in main, when "until" runs into longjmp With a test like this: 1 #include <dlfcn.h> 2 int 3 main () 4 { 5 dlsym (RTLD_DEFAULT, "FOO"); 6 return 0; 7 } and then "start" followed by "until 6", GDB currently incorrectly stops inside the runtime loader, instead of line 6. Vis: ... Temporary breakpoint 1, main () at until.c:5 4 { (gdb) until 6 0x00007ffff7f0a90d in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffdb00, operate=<optimized out>, args=0x7ffff7f0a90d <__GI__dl_catch_exception+109>) at dl-error-skeleton.c:206 206 dl-error-skeleton.c: No such file or directory. (gdb) The problem is related to longjmp handling -- dlsym internally longjmps on error. The testcase can be reduced to this: 1 #include <setjmp.h> 2 void func () { 3 jmp_buf buf; 4 if (setjmp (buf) == 0) 5 longjmp (buf, 1); 6 } 7 8 int main () { 9 func (); 10 return 0; /* until to here / 11 } and then with "start" followed by "until 10", GDB currently incorrectly stops at line 4 (returning from setjmp), instead of line 10. The problem is that the BPSTAT_WHAT_CLEAR_LONGJMP_RESUME code in infrun.c fails to find the initiating frame, and so infrun thinks that the longjmp jumped somewhere outer to "until"'s originating frame. Here: case BPSTAT_WHAT_CLEAR_LONGJMP_RESUME: { struct frame_info init_frame; /* There are several cases to consider. 1. The initiating frame no longer exists. In this case we must stop, because the exception or longjmp has gone too far. ... init_frame = frame_find_by_id (ecs->event_thread->initiating_frame); if (init_frame) // this is NULL! { ... } /* For Cases 1 and 2, remove the step-resume breakpoint, if it exists. */ delete_step_resume_breakpoint (ecs->event_thread); end_stepping_range (ecs); // case 1., so we stop. } The initiating frame is set by until_break_command -> set_longjmp_breakpoint. The initiating frame is supposed to be the frame that is selected when the command was issued, but until_break_command instead passes the frame id of the _caller_ frame by mistake. When the "until LINE" command is issued from main, the caller frame is the caller of main. When later infrun tries to find that frame by id, it fails to find it, because frame_find_by_id doesn't unwind past main. The bug is that we passed the caller frame's id to set_longjmp_breakpoint. We should have passed the selected frame's id instead. Change-Id: Iaae1af7cdddf296b7c5af82c3b5b7d9b66755b1c	4 years ago
Enze Li	cf6c1e710e	gdbserver: remove unused variable When building with clang 15, I got this error: CXX server.o server.cc:2985:10: error: variable 'new_argc' set but not used [-Werror,-Wunused-but-set-variable] int i, new_argc; ^ Remove the unused variable to eliminate the error. Tested by rebuilding on x86_64-linux with clang 15.	4 years ago
Tom de Vries	52c0a45546	[gdb/symtab] Make per_cu->set_lang more strict We have in per_cu->set_lang this comment: ... void set_lang (enum language lang) { /* We'd like to be more strict here, similar to what is done in set_unit_type, but currently a partial unit can go from unknown to minimal to ada to c. */ ... Fix this by not setting m_lang for partial units. This requires us to move the m_unit_type initialization to ensure that m_unit_type is initialized before per_cu->m_lang. Tested on x86_64-linux, with native and target board cc-with-dwz-m.	4 years ago
GDB Administrator	dd4c046506	Automatic date update in version.in	4 years ago
Pedro Alves	d21d919bc1	Improve "set scheduler-locking" documentation This improves the "set scheduler-locking" documentation in the GDB manual: - Use a table to describe the four available modes. - Describe "step" in terms of "on" and "off". - Tweak the "replay" mode's description to describe replay first instead of recording, and also mention how the mode behaves during normal execution. - Say what is the default mode. Change-Id: Ie12140138b37534b7fc1d904da34f0f174aa11ce	5 years ago
Tom de Vries	3da5576c91	[gdb/symtab] Add dwarf2_cu::lang () The cu->per_cu->lang field was added to carry information from the initial partial symtabs phase to the symtab expansion phase, for the benefit of a particular optimization in process_imported_unit_die. Other uses have been added, but since the first phase now has been parallelized, those have become problematic and sources of race conditions. Fix this by adding dwarf2_cu::lang () and using it where we can to replace cu->per_cu->lang () with cu->lang (). Also assert in dwarf2_cu::lang () that we're not returning language_unknown. Tested on x86_64-linux.	4 years ago
Martin Liska	98f49277b5	LTO plugin: sync header file with GCC include/ChangeLog: * plugin-api.h (enum ld_plugin_tag): Sync with GCC.	4 years ago
Tom de Vries	43f074cde4	[gdb/record] Support recording of getrandom Add missing support for recording of linux syscall getrandom. Tested on x86_64-linux with native and target board unix/-m32. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22081	4 years ago
Tiezhu Yang	3f6227c2f4	gdbserver: LoongArch: Add floating-point support This commit adds floating-point support for LoongArch gdbserver. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>	4 years ago
Tiezhu Yang	657a50227b	gdb: LoongArch: Add floating-point support This commit adds floating-point support for LoongArch gdb. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>	4 years ago
Tom de Vries	75948417af	[gdb/testsuite] Run two test-cases with ASAN_OPTIONS=verify_asan_link_order=0 When building gdb with -fsanitize=address we run into: ... builtin_spawn gdb -nw -nx -iex set height 0 -iex set width 0 -data-directory \ build/gdb/data-directory^M ==10637==ASan runtime does not come first in initial library list; you \ should either link runtime to your application or manually preload it with \ LD_PRELOAD.^M ERROR: GDB process no longer exists ... Prevent the ASan runtime error by using ASAN_OPTIONS=verify_asan_link_order=0. This makes both test-cases pass. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29358	4 years ago

1 2 3 4 5 ...

110745 Commits (efd3baf0dcb38d7ecc2c8b4d1553254d3c022b7a) All Branches Search

110745 Commits (efd3baf0dcb38d7ecc2c8b4d1553254d3c022b7a)

All Branches