binutils-gdb

Commit Graph

Author	SHA1	Message	Date
H.J. Lu	5bc71c2a6b	x86-64: Add R_X86_64_CODE_6_GOTTPOFF For add %reg1, name@gottpoff(%rip), %reg2 and add name@gottpoff(%rip), %reg1, %reg2 add #define R_X86_64_CODE_6_GOTTPOFF 50 if the instruction starts at 6 bytes before the relocation offset. They are similar to R_X86_64_GOTTPOFF. Linker can covert GOTTPOFF to add $name@tpoff, %reg1, %reg2 Rewrite fx_tcbit, fx_tcbit2 and fx_tcbit3 usage to generate R_X86_64_GOTPCRELX, R_X86_64_REX_GOTPCRELX, R_X86_64_CODE_4_GOTPCRELX, R_X86_64_CODE_4_GOTTPOFF, R_X86_64_CODE_4_GOTPC32_TLSDESC and R_X86_64_CODE_6_GOTTPOFF. NB: There is no need to check BFD_RELOC_X86_64_CODE_4_GOTTPOFF in md_assemble since there is only BFD_RELOC_X86_64_GOTTPOFF at this stage, which will be converted to BFD_RELOC_X86_64_CODE_4_GOTTPOFF or BFD_RELOC_X86_64_CODE_6_GOTTPOFF in i386_validate_fix. 5 relocations: #define R_X86_64_CODE_5_GOTPCRELX 46 #define R_X86_64_CODE_5_GOTTPOFF 47 #define R_X86_64_CODE_5_GOTPC32_TLSDESC 48 #define R_X86_64_CODE_6_GOTPCRELX 49 #define R_X86_64_CODE_6_GOTPC32_TLSDESC 51 are added for completeness and they are unused. bfd/ * elf64-x86-64.c (x86_64_elf_howto_table): Add R_X86_64_CODE_5_GOTPCRELX, R_X86_64_CODE_5_GOTTPOFF, R_X86_64_CODE_5_GOTPC32_TLSDESC, R_X86_64_CODE_6_GOTPCRELX, R_X86_64_CODE_6_GOTTPOFF and R_X86_64_CODE_6_GOTPC32_TLSDESC. (R_X86_64_standard): Updated. (x86_64_reloc_map): Add R_X86_64_CODE_5_GOTPCRELX, R_X86_64_CODE_5_GOTTPOFF, R_X86_64_CODE_5_GOTPC32_TLSDESC, R_X86_64_CODE_6_GOTPCRELX, R_X86_64_CODE_6_GOTTPOFF and R_X86_64_CODE_6_GOTPC32_TLSDESC. (elf_x86_64_check_tls_transition): Handle R_X86_64_CODE_6_GOTTPOFF. (elf_x86_64_tls_transition): Likewise. (elf_x86_64_scan_relocs): Handle R_X86_64_CODE_6_GOTTPOFF. Issue an error for R_X86_64_CODE_5_GOTPCRELX, R_X86_64_CODE_5_GOTTPOFF, R_X86_64_CODE_5_GOTPC32_TLSDESC, R_X86_64_CODE_6_GOTPCRELX and R_X86_64_CODE_6_GOTPC32_TLSDESC. (elf_x86_64_relocate_section): Handle R_X86_64_CODE_6_GOTTPOFF. * reloc.c (bfd_reloc_code_real): Add BFD_RELOC_X86_64_CODE_5_GOTPCRELX, BFD_RELOC_X86_64_CODE_5_GOTTPOFF, BFD_RELOC_X86_64_CODE_5_GOTPC32_TLSDESC, BFD_RELOC_X86_64_CODE_6_GOTPCRELX, BFD_RELOC_X86_64_CODE_6_GOTTPOFF and BFD_RELOC_X86_64_CODE_6_GOTPC32_TLSDESC. * bfd-in2.h: Regenerated. * libbfd.h: Likewise. elfcpp/ * x86_64.h (R_X86_64_CODE_5_GOTPCRELX): New. (R_X86_64_CODE_5_GOTTPOFF): Likewise. (R_X86_64_CODE_5_GOTPC32_TLSDESC): Likewise. (R_X86_64_CODE_6_GOTPCRELX): Likewise. (R_X86_64_CODE_6_GOTTPOFF): Likewise. (R_X86_64_CODE_6_GOTPC32_TLSDESC): Likewise. gas/ * config/tc-i386.c (tc_i386_fix_adjustable): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. (md_assemble): Don't check BFD_RELOC_X86_64_CODE_4_GOTTPOFF. Allow "add %reg1, foo@gottpoff(%rip), %reg2". (output_disp): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. Rewrite setting fx_tcbitX bits for BFD_RELOC_X86_64_GOTTPOFF, BFD_RELOC_X86_64_GOTPC32_TLSDESC and BFD_RELOC_32_PCREL. (md_apply_fix): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. (i386_validate_fix): Rewrite fx_tcbitX bit checking for BFD_RELOC_X86_64_GOTTPOFF, BFD_RELOC_X86_64_GOTPC32_TLSDESC and BFD_RELOC_32_PCREL. (tc_gen_reloc): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. * testsuite/gas/i386/x86-64-gottpoff.d: Updated. * testsuite/gas/i386/x86-64-gottpoff.s: Add tests for "add %reg1, foo@gottpoff(%rip), %reg2" and "add foo@gottpoff(%rip), %reg, %reg2". gold/ * x86_64.cc (Target_x86_64::optimize_tls_reloc): Handle R_X86_64_CODE_6_GOTTPOFF. (Target_x86_64::Scan::get_reference_flags): Likewise. (Target_x86_64::Scan::local): Likewise. (Target_x86_64::Scan::global): Likewise. (Target_x86_64::Relocate::relocate): Likewise. (Target_x86_64::Relocate::relocate_tls): Likewise. (Target_x86_64::Relocate::tls_ie_to_le): Handle. R_X86_64_CODE_6_GOTTPOFF. * testsuite/x86_64_ie_to_le.s: Add tests for "add %reg1, foo@gottpoff(%rip), %reg2" and "add foo@gottpoff(%rip), %reg, %reg2". * testsuite/x86_64_ie_to_le.sh: Updated. include/ * elf/x86-64.h (elf_x86_64_reloc_type): Add R_X86_64_CODE_5_GOTPCRELX, R_X86_64_CODE_5_GOTTPOFF, R_X86_64_CODE_5_GOTPC32_TLSDESC, R_X86_64_CODE_6_GOTPCRELX, R_X86_64_CODE_6_GOTTPOFF and R_X86_64_CODE_6_GOTPC32_TLSDESC. ld/ * testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_6_GOTTPOFF tests. * testsuite/ld-x86-64/tlsbindesc.d: Updated. * testsuite/ld-x86-64/tlsbindesc.rd: Likewise.	3 years ago
Richard W.M. Jones	3f8f9745c7	PR 31283 windmc: Parse input correctly on big endian hosts On big endian hosts (eg. s390x) the windmc tool fails to parse even trivial files: $ cat test.mc ; $ ./binutils/windmc ./test.mc In test.mc at line 1: parser: syntax error. In test.mc at line 1: fatal: syntax error. The tool starts by reading the input as Windows CP1252 and then converting it internally into an array of UTF-16LE, which it then processes as an array of unsigned short (typedef unichar). There are lots of ways this is wrong, but in the specific case of big endian machines the little endian pairs of bytes are byte-swapped. For example, the ';' character in the input above is first converted to UTF16-LE byte sequence { 0x3b, 0x00 }, which is then cast to unsigned short. On a big endian machine the first unichar appears to be 0x3b00. The lexer is unable to recognize this as the comment character ((unichar)';') and so parsing fails. The simple fix is to convert the input to UTF-16BE on big endian machines (and do the reverse conversion when writing the output). Fixes: https://sourceware.org/bugzilla/show_bug.cgi?id=31283 Signed-off-by: Richard W.M. Jones <rjones@redhat.com>	3 years ago
GDB Administrator	16688387ed	Automatic date update in version.in	3 years ago
Hannes Domani	276d9db22d	Raise exception if ambiguous name is used in gdb.parameter Currently gdb.parameter doesn't raise an exception if an ambiguous name is used, it instead returns the value of the last partly matching parameter: ``` (gdb) show print sym Ambiguous show print command "sym": symbol, symbol-filename, symbol-loading. (gdb) show print symbol-loading Printing of symbol loading messages is "full". (gdb) py print(gdb.parameter("print sym")) full ``` It's because lookup_cmd_composition_1 tries to detect ambigous names by checking the return value of find_cmd for CMD_LIST_AMBIGUOUS, which never happens, since only lookup_cmd_1 returns CMD_LIST_AMBIGUOUS. Instead the nfound argument contains the number of found matches. By using it instead, and by setting *CMD to the special value CMD_LIST_AMBIGUOUS in this case, gdbpy_parameter can now show the appropriate error message: ``` (gdb) py print(gdb.parameter("print sym")) Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: Parameter `print sym' is ambiguous. Error while executing Python code. (gdb) py print(gdb.parameter("print symbol")) True (gdb) py print(gdb.parameter("print symbol-")) Traceback (most recent call last): File "<string>", line 1, in <module> RuntimeError: Parameter `print symbol-' is ambiguous. Error while executing Python code. (gdb) py print(gdb.parameter("print symbol-load")) full ``` Since the document command also uses lookup_cmd_composition, it needed to check for CMD_LIST_AMBIGUOUS as well, so it now also shows an "Ambiguous command" error message in this case. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14639 Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Hannes Domani	ad7b7cb1f4	Fix raw-frame-arguments in combination with frame-filters Currently, if frame-filters are active, raw-values is used instead of raw-frame-arguments to decide if a pretty-printer should be invoked for frame arguments in a backtrace. In this example, "super struct" is the output of the pretty-printer: (gdb) disable frame-filter global BasicFrameFilter (gdb) bt #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 If no frame-filter is active, then the raw-values print option does not affect the backtrace output: (gdb) set print raw-values on (gdb) bt #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 (gdb) set print raw-values off Instead, the raw-frame-arguments option disables the pretty-printer in the backtrace: (gdb) bt -raw-frame-arguments on #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 But if a frame-filter is active, the same rules don't apply. The option raw-frame-arguments is ignored, but raw-values decides if the pretty-printer is used: (gdb) enable frame-filter global BasicFrameFilter (gdb) bt #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 (gdb) set print raw-values on (gdb) bt #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 (gdb) set print raw-values off (gdb) bt -raw-frame-arguments on #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 So this adds the PRINT_RAW_FRAME_ARGUMENTS flag to frame_filter_flag, which is then used in the frame-filter to override the raw flag in enumerate_args. Then the output is the same if a frame-filter is active, the pretty-printer for backtraces is only disabled with the raw-frame-arguments option: (gdb) enable frame-filter global BasicFrameFilter (gdb) bt #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 (gdb) set print raw-values on (gdb) bt #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 (gdb) set print raw-values off (gdb) bt -raw-frame-arguments on #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Ciaran Woodward	6fb99666f4	Remove use of scoped_restore_tmpl from scoped_restore_warning_hook The warning_hook_handler function pointer takes va_list as an argument, which on some platforms (mingw64) includes some attributes. Attributes get ignored in template arguments. This led to the compiler warning: error: ignoring attributes on template argument 'warning_hook_handler' {aka 'void ()(const char, char*)'} [-Werror=ignored-attributes] 387 \| scoped_restore_tmpl<warning_hook_handler> m_save; \| ^ By manually implementing the save/restore behaviour, rather than using the helper template, this warning is fixed. Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Alan Modra	c33ea119b1	asan: NULL dereference in _bfd_mips_final_write_processing Fuzzed object files can easily have unexpected section names. We don't want to segfault on objcopy of any file accepted by the mips object_p functions. For objcopy, an assertion that "sec" is non-NULL followed by deferencing "sec" is wrong. So too is asserting that the section name string starts with a particular prefix, and then blithely accessing past the assumed prefix. * elfxx-mips.c (_bfd_mips_final_write_processing): Replace assertions with conditionals. Don't bother testing for name non-NULL.	3 years ago
Alan Modra	3ef23ee926	memory leak in objdump disassemble_section * objdump.c (disassemble_section): Free rel_ppstart on error path.	3 years ago
Indu Bhagat	f8c50ae270	gas: x86: ginsn: handle sub-QWORD ALU with imm and MOV ops correctly PR gas/31326 SCFI must handle non QWORD ALU with imm and MOV ops correctly As per the x86 ISA manual: - 32-bit operands generate a 32-bit result, zero-extended to a 64-bit result in the destination general-purpose register. - 8-bit and 16-bit operands generate an 8-bit or 16-bit result. The upper 56 bits or 48 bits (respectively) of the destination general-purpose register are not modified by the operation. Unlike previously thought, sub-QWORD ALU/imm and MOV ops do have implications on SCFI. SCFI/ginsn machinery does not track operation size in the ginsn representation. But given that these sub-QWORD ops update only a portion of a 64-bit destination register, for SCFI purposes, this needs to be deemed as an untraceable update (when the destination is REG_SP / REG_FP). Although in most cases, sub-QWORD ops are not expected for stack management, but the SCFI machinery must behave correctly, when such ops are indeed present. As mentioned earlier, ginsn representation does not carry operation size information. To resolve the issue raised in PR gas/31326, an option is to force the generation of GINSN_TYPE_OTHER for all cases when there is a 8/16/32 bit op. But this may dilute the utility of ginsn for other use-cases, when they pop up in future. The current approach is less disruptive than above in that it generates GINSN_TYPE_OTHER for all cases only when: - there is a 8/16/32 bit op, and - the 64-bit op is otherwise traceable. In other words this means: - For add/sub ops where dest is reg and src is reg/mem: these always make dest reg untraceable; So, the current handling is unchanged. We simply skip detecting 8/16/32-bit ops. - An x86 pop instruction is translated to a load ginsn followed by a stack increment add op. A load op always makes dest reg untraceable. Hence, if the pop instruction is sub-QWORD, we continue to (skip detecting 8/16/32-bit op, and) generate the load instruction as usual. This means that if input asm does have save and restore of unequal sized registers, gas/SCFI will not detect nor warn. - For ALU imm or MOV reg,reg, however, a GINSN_TYPE_OTHER is generated when a 8/16/32-bit op is seen. gas/ PR gas/31326 * config/tc-i386.c (x86_ginsn_addsub_reg_mem): Add a code comment. (x86_ginsn_addsub_mem_reg): Likewise. (x86_ginsn_alu_imm): Detect sub-QWORD opsize and exit early. (x86_ginsn_move): Likewise. (x86_ginsn_new): Add comment for 8-bit add/sub opcodes (in opcode_space SPACE_BASE) about skipped handling. gas/testsuite/: PR gas/31326 * gas/scfi/x86_64/ginsn-add-1.l: Update. * gas/scfi/x86_64/ginsn-add-1.s: Add some sub-QWORD add ops. * gas/scfi/x86_64/ginsn-dw2-regnum-1.l: Update. * gas/scfi/x86_64/ginsn-dw2-regnum-1.s: Use mov ops instead of add to invoke and test the ginsn_dw2_regnum code path.	3 years ago
GDB Administrator	b5f29db531	Automatic date update in version.in	3 years ago
Simon Marchi	6fdf95ae53	gdb: remove core_bfd macro The core_bfd macro hides a use of current_program_space. Remove it, so that we have the opportunity to get the program space from the context, if possible. I guess that the macro was introduced at some point to replace a global variable of the same name without changing all the uses. Change-Id: I971a65b29b5e5a5941f3cb7ea234547daa787268 Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
H.J. Lu	0afc614c99	x86: Warn .insn instruction with length > 15 bytes Change .insn instruction with length > 15 bytes from error to warning. PR gas/31323 * config/tc-i386.c (output_insn): Issue a warning when .insn instruction length exceeds the limit of 15 bytes. * testsuite/gas/i386/oversized64.s: Add a test for .insn * testsuite/gas/i386/oversized64.l: Updated.	3 years ago
Tiezhu Yang	be908bd6e7	gdb: LoongArch: Implement the get_syscall_number gdbarch method In the current code, the feature 'catch syscall' is not supported on LoongArch, implement the "get_syscall_number" gdbarch method to get the system call number from the register a7. Without this patch: (gdb) catch syscall The feature 'catch syscall' is not supported on this architecture yet. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>	3 years ago
Feiyang Chen	e4d74c01e7	gdb: LoongArch: Add LBT extension support Loongson Binary Translation (LBT) is used to accelerate binary translation, which contains 4 scratch registers (scr0 to scr3), x86/ARM eflags (eflags) and x87 fpu stack pointer (ftop). This patch support gdb to fetch/store these registers. Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn> # Framework Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> # Detail Optimizes Signed-off-by: Hui Li <lihui@loongson.cn> # Error Fixes Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>	3 years ago
Hui Li	1e9569f383	gdb: LoongArch: Add vector extensions support Add LoongArch's vector extensions support, which including 128bit LSX (i.e., Loongson SIMD eXtension) and 256bit LASX (i.e., Loongson Advanced SIMD eXtension). This patch support gdb to fetch/store vector registers. Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>	3 years ago
Alan Modra	60c95acdac	Link x86-64 mark-plt-1.so with --no-as-needed Fixes FAIL: Build mark-plt-1.so where gcc is built with default --as-needed. * testsuite/ld-x86-64/x86-64.exp (Build mark-plt-1.so): Pass --no-as-needed.	3 years ago
GDB Administrator	df8db2b1fb	Automatic date update in version.in	3 years ago
Simon Marchi	6cedf3bcbf	gdb: rename target_so_ops to solib_ops I don't like the name `target_so_ops`, because: - The name `target` is so overloaded, and in this case it's not even related to target_ops or anything else called "target". - We do have an implementation that actually fetches solibs from the target (solib_target_so_op in solib-target.c), so it's confusing for the "base class" to be called target_something as well. Rename to solib_ops. Change-Id: I46a983d44e81400470e22deb09aaf26ad8a3587f Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Simon Marchi	7b323785ef	gdb: rename struct shobj -> struct solib `struct so_list` was recently renamed to `struct shobj` (in `3fe0dfd160` ("gdb: rename struct so_list to shobj")). In hindsight, `solib` would have been a better name. We have solib.c, the implementations in solib-*.c, many functions with solib in their name, the solib_loaded / solib_unloaded observables, etc. Rename shobj to solib. Change-Id: I0af1c7a9b29bdda027e9af633f6d37e1cfcacd5d Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Tom Tromey	68d3bf7d24	Remove remnants of partial DIEs from DWARF reader When rewriting the DWARF scanner, I forgot to remove dwarf2_cu::load_all_dies and dwarf2_cu::partial_dies. This patch corrects the oversight and fixes up a couple other spots that mention partial DIEs, which no longer exist. Approved-By: Tom de Vries <tdevries@suse.de>	3 years ago
Tom Tromey	4b858d4dbb	Avoid an allocation in attr_to_dynamic_prop I noticed that attr_to_dynamic_prop allocates a dwarf_block, when no allocation is required. This patch stack-allocates the object instead. Reviewed-By: Tom de Vries <tdevries@suse.de>	3 years ago
Thiago Jung Bauermann	9c0aa4c531	Fix disabling of year 2038 support on 32-bit hosts by default Commit `e5f2f7d901` ("Disable year 2038 support on 32-bit hosts by default") fixed a mismatch between 64-bit time_t in GDB and system headers and 32-bit time_t in BFD. However, since commit `862776f26a` ("Finalized intl-update patches") gnulib's year 2038 support has been accidentally re-enabled — causing problems for 32-bit hosts again. The commit split baseargs into {h,b}baseargs, but this hasn't been done for the code that handles --disable-year2038. This patch restores the intended behaviour. With this change, the number of unexpected core files goes from 18 to 4. Tested on armv8l-linux-gnueabihf. Approved-By: Luis Machado <luis.machado@arm.com>	3 years ago
Tom Tromey	a8b1650962	Handling of arrays with optimized-out bounds In Ada, sometimes the compiler must emit array bounds by referencing an artificial variable that's created for this purpose. However, with optimization enabled, these variables can be optimized away. Currently this can result in displays like: (gdb) print mumble $1 = (warning: unable to get bounds of array, assuming null array ) This patch changes this to report that the array is optimized-out, instead, which is closer to the truth, and more generally useful. For example, Python pretty-printers can now recognize this situation. In order to accomplish this, I introduced a new PROP_OPTIMIZED_OUT enumerator and changed one place to use it. Reusing the "unknown" state wouldn't work properly, because in C it is normal for array bounds to be unknown.	3 years ago
Tom de Vries	bae2a57f4c	[gdb/tdep] Fix use-after-free in arm_exidx_fill_cache On arm-linux the linaro CI occasionally reports: ... (gdb) up 10 #4 0x0001b864 in pthread_join () (gdb) FAIL: gdb.threads/staticthreads.exp: up 10 ... while this is expected: ... (gdb) up 10 #3 0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76 76 pthread_join (thread, NULL); (gdb) PASS: gdb.threads/staticthreads.exp: up 10 ... Thiago investigated the problem, and using valgrind found an invalid read in arm_exidx_fill_cache. The problem happens as follows: - an objfile and corresponding per_bfd are allocated - some memory is allocated in arm_exidx_new_objfile using objfile->objfile_obstack, for the "exception table entry cache". - a symbol reread is triggered, and the objfile, including the objfile_obstack, is destroyed - a new objfile is allocated, using the same per_bfd - again arm_exidx_new_objfile is called, but since the same per_bfd is used, it doesn't allocate any new memory for the "exception table entry cache". - the "exception table entry cache" is accessed by arm_exidx_fill_cache, and we have a use-after-free. This is a regression since commit `a2726d4ff8` ("[ARM] Store exception handling information per-bfd instead of per-objfile"), which changed the "exception table entry cache" from per-objfile to per-bfd, but failed to update the obstack_alloc. Fix this by using objfile->per_bfd->storage_obstack instead of objfile->objfile_obstack. I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch fixes it. Tested on arm-linux. Approved-By: Luis Machado <luis.machado@arm.com> PR tdep/31254 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254	3 years ago
GDB Administrator	d1abc68953	Automatic date update in version.in	3 years ago
Tom Tromey	b36a26343a	Use reference result of emplace_back Starting with C++17, emplace_back returns a reference to the new object. This patch changes code that uses emplace_back followed by a call to back() to simply use this reference instead. Approved-By: Simon Marchi <simon.marchi@efficios.com>	3 years ago
Xi Ruoyao	029e52bac7	LoongArch: gas: Fix the types of symbols referred with %le__r in the symtab When a symbol is referred with %le_{hi20,lo12,add}_r, it's definitely a TLS symbol and we should set its type to TLS in the symtab. Otherwise when building Perl with gcc-14 -flto, we get: /usr/bin/ld: PL_current_context: TLS definition in ./miniperl.ltrans0.ltrans.o section .tbss mismatches non-TLS reference in ./miniperl.ltrans1.ltrans.o A minimal reproducer: $ cat t1.s .section .tbss .globl x x: .word 0 $ cat t2.s f: lu12i.w $a0, %le_hi20_r(x) add.d $a0, $a0, $tp, %le_add_r(x) li.w $a1, 1 st.w $a1, $a0, %le_lo12_r(x) $ gas/as-new t1.s -o t1.o $ gas/as-new t2.s -o t2.o $ ld/ld-new t1.o t2.o ld/ld-new: x: TLS definition in t1.o section .tbss mismatches non-TLS reference in t2.o Unfortunately this was undetected before Binutils-2.42 release because GCC < 14 does not use %le__r, and without LTO it's very rare to have a TLS LE definition and its reference in two different translation units. So this fix should be backported to Binutils-2.42 branch too. Signed-off-by: Xi Ruoyao <xry111@xry111.site>	3 years ago
GDB Administrator	9fdd490b6b	Automatic date update in version.in	3 years ago
GDB Administrator	44c91f530f	Automatic date update in version.in	3 years ago
Andrew Burgess	e58beedf2c	gdb: attach to a process when the executable has been deleted Bug PR gdb/28313 describes attaching to a process when the executable has been deleted. The bug is for S390 and describes how a user sees a message 'PC not saved'. On x86-64 (GNU/Linux) I don't see a 'PC not saved' message, but instead I see this: (gdb) attach 901877 Attaching to process 901877 No executable file now. warning: Could not load vsyscall page because no executable was specified 0x00007fa9d9c121e7 in ?? () (gdb) bt #0 0x00007fa9d9c121e7 in ?? () #1 0x00007fa9d9c1211e in ?? () #2 0x0000000000000007 in ?? () #3 0x000000002dc8b18d in ?? () #4 0x0000000000000000 in ?? () (gdb) Notice that the addresses in the backtrace don't seem right, quickly heading to 0x7 and finally ending at 0x0. What's going on, in both the s390 case and the x86-64 case is that the architecture's prologue scanner is going wrong and causing the stack unwinding to fail. The prologue scanner goes wrong because GDB has no unwind information. And GDB has no unwind information because, of course, the executable has been deleted. Notice in the example session above we get this line in the output: No executable file now. which indicates that GDB failed to find an executable to debug. For GNU/Linux when GDB tries to find an executable for a given pid we end up calling linux_proc_pid_to_exec_file in gdb/nat/linux-procfs.c. Within this function we call `readlink` on /proc/PID/exe to find the path of the actual executable. If the `readlink` call fails then we already fallback on using /proc/PID/exe as the path to the executable to debug. However, when the executable has been deleted the `readlink` call doesn't fail, but the path that is returned points to a non-existent file. I propose that we add an `access` call to linux_proc_pid_to_exec_file to check that the target file exists and can be read. If the target can't be read then we should fall back to /proc/PID/exe (assuming that /proc/PID/exe can be read). Now on x86-64 the output looks like this: (gdb) attach 901877 Attaching to process 901877 Reading symbols from /proc/901877/exe... Reading symbols from /lib64/libc.so.6... (No debugging symbols found in /lib64/libc.so.6) Reading symbols from /lib64/ld-linux-x86-64.so.2... (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) 0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6 (gdb) bt #0 0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6 #1 0x00007fa9d9c1211e in sleep () from /lib64/libc.so.6 #2 0x000000000040117e in spin_forever () at attach-test.c:17 #3 0x0000000000401198 in main () at attach-test.c:24 (gdb) which is much better. I've also tagged the bug PR gdb/29782 which concerns the test gdb.server/connect-with-no-symbol-file.exp. After making this change, when running gdb.server/connect-with-no-symbol-file.exp GDB would now pick up the /proc/PID/exe file as the executable in some cases. As GDB is not restarted for the multiple iterations of this test GDB (or rather BFD) would given a warning/error like: (gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: disconnect set sysroot target: BFD: reopening /proc/3283001/exe: No such file or directory (gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: adjust sysroot What's happening is that an executable found for an earlier iteration of the test is still registered for the inferior when we are setting up for a second iteration of the test. When the sysroot changes, if there's an executable registered GDB tries to reopen it, but in this case the file has disappeared (the previous inferior has exited by this point). I did think about maybe, when the executable is /proc/PID/exe, we should auto-delete the file from the inferior. But in the end I thought this was a bad idea. Not only would this require a lot of special code in GDB just to support this edge case: we'd need to track if the exe file name came from /proc and should be auto-deleted, or we'd need target specific code to check if a path should be auto-deleted..... ... in addition, we'd still want to warn the user when we auto-deleted the file from the inferior, otherwise they might be surprised to find their inferior suddenly has no executable attached, so we wouldn't actually reduce the number of warnings the user sees. So in the end I figured that the best solution is to just update the test to avoid the warning. This is easily done by manually removing the executable from the inferior once each iteration of the test has completed. Now, in bug PR gdb/29782 GDB is clearly managing to pick up an executable from the NFS cache somehow. I guess what's happening is that when the original file is deleted /proc/PID/exe is actually pointing to a file in the NFS cache which is only deleted at some later point, and so when GDB starts up we do manage to associate a file with the inferior, this results in the same message being emitted from BFD as I was seeing. The fix included in this commit should also fix that bug. One final note: On x86-64 GNU/Linux, the gdb.server/connect-with-no-symbol-file.exp test will produce 2 core files. This is due to a bug in gdbserver that is nothing to do with this test. These core files are created before and after this commit. I am working on a fix for the gdbserver issue, but will post that separately. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28313 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29782 Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
H.J. Lu	46bd909328	x86: Disallow instructions with length > 15 bytes It is a hard error when an instruction length exceeds the limit of 15 bytes: [hjl@gnu-cfl-3 tmp]$ cat x.s .text xacquire lock addq $0x11223344, %fs:(,%eax) [hjl@gnu-cfl-3 tmp]$ gcc -c x.s x.s: Assembler messages: x.s:2: Warning: instruction length of 16 bytes exceeds the limit of 15 [hjl@gnu-cfl-3 tmp]$ objdump -dw x.o x.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <.text>: 0: 64 67 f2 f0 48 81 04 05 00 00 00 00 44 33 22 xacquire lock (bad) f: 11 .byte 0x11 [hjl@gnu-cfl-3 tmp]$ and [hjl@gnu-cfl-3 tmp]$ cat z.s addq $0xe0, %fs:0, %rdx [hjl@gnu-cfl-3 tmp]$ as -o z.o z.s z.s: Assembler messages: z.s:1: Warning: instruction length of 16 bytes exceeds the limit of 15 [hjl@gnu-cfl-3 tmp]$ objdump -dw z.o z.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <.text>: 0: 64 62 f4 ec 18 81 04 25 00 00 00 00 e0 00 00 (bad) ... [hjl@gnu-cfl-3 pr31323]$ Instructions with length > 15 bytes are always invalid. It is quite easy to generate invalid instructions with AVX now. We should issue an error when instruction length exceeds the limit of 15 bytes. PR gas/31323 * config/tc-i386.c (output_insn): Issue an error when instruction length exceeds the limit of 15 bytes. * testsuite/gas/i386/oversized16.l: Updated. * testsuite/gas/i386/oversized64.l: Likewise. * testsuite/gas/i386/x86-64-apx-inval.l: New file. * testsuite/gas/i386/x86-64-apx-inval.s: Likewise.	3 years ago
Nils-Christian Kempke	6a67441983	gdb, testsuite, fortran: Fix sizeof intrinsic for Fortran pointers For Fortran pointers gfortran/ifx emits DW_TAG_pointer_types like <2><17d>: Abbrev Number: 22 (DW_TAG_variable) <180> DW_AT_name : (indirect string, offset: 0x1f1): fptr <184> DW_AT_type : <0x214> ... <1><219>: Abbrev Number: 27 (DW_TAG_array_type) <21a> DW_AT_type : <0x10e> <216> DW_AT_associated : ... The 'pointer property' in Fortran is implicitly modeled by adding a DW_AT_associated to the type of the variable (see also the DW_AT_associated description in DWARF 5). A Fortran pointer is more than an address and thus different from a C pointer. It is a self contained type having additional fields such as, e.g., the rank of its underlying array. This motivates the intended DWARF modeling of Fortran pointers via the DW_AT_associated attribute. This patch adds support for the sizeof intrinsic by simply dereferencing pointer types when encountered during a sizeof evaluation. The patch also adds a test for the sizeof intrinsic which was not tested before. Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Tom Tromey <tom@tromey.com>	4 years ago
Bernhard Heckel	f18fc7e56f	gdb, types: Resolve pointer types dynamically This commit allows pointers to be dynamic types (on the outmost level). Similar to references, a pointer is considered a dynamic type if its target type is a dynamic type and it is on the outmost level. Also this commit removes the redundant code inside function "value_check_printable" for handling of DW_AT_associated type. The pointer resolution follows the one of references. This change generally makes the GDB output more verbose. We are able to print more details about a pointer's target like the dimension of an array. In Fortran, if we have a pointer to a dynamic type type buffer real, dimension(:), pointer :: ptr end type buffer type(buffer), pointer :: buffer_ptr allocate (buffer_ptr) allocate (buffer_ptr%ptr (5)) which then gets allocated, we now resolve the dynamic type before printing the pointer's type: Before: (gdb) ptype buffer_ptr type = PTR TO -> ( Type buffer real(kind=4) :: alpha(:) End Type buffer ) After: (gdb) ptype buffer_ptr type = PTR TO -> ( Type buffer real(kind=4) :: alpha(5) End Type buffer ) Similarly in C++ we can dynamically resolve e.g. pointers to arrays: int len = 3; int arr[len]; int (ptr)[len]; int ptr = &arr; Once the pointer is assigned one gets: Before: (gdb) p ptr $1 = (int ()[variable length]) 0x123456 (gdb) ptype ptr type = int ()[variable length] After: (gdb) p ptr $1 = (int ()[3]) 0x123456 (gdb) ptype ptr type = int (*)[3] For more examples see the modified/added test cases. Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Tom Tromey <tom@tromey.com>	4 years ago
Ijaz, Abdul B	2e07108364	gdb/testsuite: Fix indentation issues in gdb.dwarf2/dynarr-ptr.exp Improve indentation in the test file by replacing 10 spaces at second level with 4 spaces. This helps to update the test using the right indentation in future. Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Jan Beulich	4e3be89fda	x86: move Q-suffix-to-REX.W translation logic By pulling it ahead of the SHORT_MNEM_SUFFIX case label we can drop a part of another conditional there. While moving, also drop a pointless check: With QWORD_MNEM_SUFFIX, register operands of XCHG necessarily have both been 64-bit ones.	3 years ago
Jan Beulich	1e7dd4a034	x86: actually implement .noopt For quite some time we've had support for -O command line options. With that ignoring at least .noopt isn't really a good idea. Re-purpose the optimize-3 test for testing this directive's effect as well. As to the doc addition - this uses the same text as is there for the {nooptimize} pseudo-prefix, despite me not being convinced of the "size" part being fully accurate there (and hence also here).	3 years ago
Sandra Loosemore	e4d85860c2	MAINTAINERS: Update my e-mail address.	3 years ago
GDB Administrator	f3f71328ae	Automatic date update in version.in	3 years ago
Indu Bhagat	09812f0835	gas: x86: ginsn: adjust ginsns for certain lea ops A review comment on the SCFI V4 series was to handle ginsn creation for certain lea opcodes more precisely. Specifically, we should preferably handle the following two cases of lea opcodes similarly: - #1 lea with "index register and scale factor of 1, but no base register", - #2 lea with "no index register, but base register present". Currently, a ginsn of type GINSN_TYPE_OTHER is generated for the case of #1 above. For #2, however, the lea insn is translated to either a GINSN_TYPE_ADD or GINSN_TYPE_MOV depending on whether the immediate for displacement is non-zero or not respectively. Change the handling in x86_ginsn_lea so that both of the above lea manifestations are handled similarly. While at it, remove the code paths creating GINSN_TYPE_OTHER altogether from the function. It makes sense to piggy back on the x86_ginsn_unhandled code path to create GINSN_TYPE_OTHER if the destination register is interesting. This was also suggested in one of the previous review rounds; the other functions already follow that model, so this keeps functions symmetrical looking. gas/ * gas/config/tc-i386.c (x86_ginsn_lea): Handle select lea ops with no base register similar to the case of no index register. Remove creation of GINSN_TYPE_OTHER from the function. gas/testsuite/ * gas/scfi/x86_64/ginsn-lea-1.l: New test. * gas/scfi/x86_64/ginsn-lea-1.s: Likewise. * gas/scfi/x86_64/scfi-x86-64.exp: Add new test.	3 years ago
Vladimir Mezentsev	b3c670a6ba	gprofng: Remove unused macros gprofng/ChangeLog 2024-02-01 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * common/gp-experiment.h: Remove SP_REMOTE_PROTOCOL_VERSION. * common/hwctable.c: Remove DBG_LT* macros. * libcollector/envmgmt.c: Likewise. * libcollector/hwprofile.c: Likewise. * libcollector/iolib.c: Likewise. * libcollector/jprofile.c: Likewise. * libcollector/memmgr.c: Likewise. * libcollector/profile.c: Likewise. * libcollector/tsd.c: Likewise. * libcollector/unwind.c: Likewise.	3 years ago
Tom Tromey	49ba125f96	Fix "objstack" typo I noticed some comments that mentions "objstack". The type is actually "obstack". This patch fixes the typos.	3 years ago
Tom Tromey	f214edceb8	Rename SEARCH_ALL The constant SEARCH_ALL conflicts with a define in a Windows header. This patch renames the constant to SEARCH_ALL_DOMAINS to avoid the conflict. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31307	3 years ago
Andrew Burgess	05d1b4b4ad	gdb/testsuite: fix some duplicate test names in gdb.trace/ This commit fixes some of the easier duplicate test names in the gdb.trace/ directory. All of these duplicates are resolved by either given tests a name, or by extended the existing name to make it more descriptive. There should be no change in what is tested after this commit.	3 years ago
Andrew Burgess	025f70c861	gdb/testsuite: fix duplicate test names in gdb.base/cond-eval-mode.exp Fix some duplicate test names in gdb.base/cond-eval-mode.exp when running with native-gdbserver or native-extended-gdbserver board files. I've just added some 'with_test_prefix' blocks to make the test names unique, there should be no change in what is tested after this commit.	3 years ago
Aditya Vidyadhar Kamath	49346fa794	Fix AIX build break. A recent commit broke AIX build. The thread_local type defined functions were being considered a weak symbol and hence while creating the binary these symbols were not visible. This patch is a fix for the same.	3 years ago
GDB Administrator	3d4b08fb89	Automatic date update in version.in	3 years ago
Simon Marchi	9c175474a8	gdb: remove some unnecessary frame_info_ptr resets This code was probably needed before we had reinflatable frame_info_ptrs, it's not necessary anymore. Change-Id: I5474c6081ee1e39624c9266b05dbe01351a130b5 Approved-By: Tom Tromey <tom@tromey.com>	3 years ago
Nick Clifton	249e54204b	Mention support for AMD/znver5 in GAS	3 years ago
Georg-Johann Lay	24f5deb64d	PR31124: Addendum: Remove PROVIDE of __flmap_init_label, __flmap. Supply these symbols as computed by the linker scripts, even when there are weak definitions. PR 31124 * scripttempl/avr.sc (__flmap, __flmap_init_label): Remove PROVIDE.	3 years ago
GDB Administrator	aef6ac7800	Automatic date update in version.in	3 years ago

1 2 3 4 5 ...

117696 Commits (5bc71c2a6b8efb27089baa1fecded82be4f550a7) All Branches Search

117696 Commits (5bc71c2a6b8efb27089baa1fecded82be4f550a7)

All Branches