binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Vladimir Mezentsev	08328cfbaf	gprofng docs: mention HTML / PDF in the gprofng README The HTML and PDF formats are described in the gprofng tutorial (info topic "Other Document Formats"). In addition, describe them in the README because: they are important; they are easily searchable; and the README is primarily oriented to the person who is installing gprofng, who may differ from the person who follows a user tutorial.	4 years ago
Vladimir Mezentsev	8e2de6c81a	gprofng: fix build with -Werror=format-security gprofng/ChangeLog 2022-06-13 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> PR gprofng/28968 * src/src/Hist_data.cc (print_row): Make param const. * src/src/Hist_data.h (print_row): Likewise. * src/src/Print.h: Remove unused functions and variables. * src/Print.cc: Fix -Werror=format-security errors. * src/parse.cc: Likewise.	4 years ago
Tom de Vries	362a867f2a	[gdb/testsuite] Handle unordered dict in gdb.python/py-mi-cmd.exp When running test-case gdb.python/py-mi-cmd.exp on openSUSE Leap 42.3 with python 3.4, I occasionally run into: ... Expecting: ^(-pycmd dct[^M ]+)?(\^done,result={hello="world",times="42"}[^M ]+[(]gdb[)] ^M [ ]*) -pycmd dct^M ^done,result={times="42",hello="world"}^M (gdb) ^M FAIL: gdb.python/py-mi-cmd.exp: -pycmd dct (unexpected output) ... The problem is that the data type used here in py-mi-cmd.py: ... elif argv[0] == "dct": return {"result": {"hello": "world", "times": 42}} ... is a dictionary, and only starting version 3.6 are dictionaries insertion ordered, so using PyDict_Next in serialize_mi_result doesn't guarantee a fixed order. Fix this by allowing the alternative order. Tested on x86_64-linux.	4 years ago
Tom Tromey	965b71a7f7	Implement lazy FPU initialization for ravenscar Some ravenscar runtimes implement lazy FPU handling. On these runtimes, the FPU is only initialized when a task tries to use it. Furthermore, the FP registers aren't automatically saved on a task switch -- instead, the save is deferred until the new task tries to use the FPU. Furthermore, each task's context area has a flag indicating whether the FPU has been initialized for this task. This patch teaches GDB to understand this implementation. When fetching or storing registers, GDB now checks to see whether the live FP registers should be used. If not, the task's saved FP registers will be used if the task has caused FPU initialization. Currently only AArch64 uses this code. bb-runtimes implements this for ARM as well, but GDB doesn't yet have an arm-ravenscar-thread.c.	4 years ago
Tom Tromey	e73434e38f	Reimplement ravenscar registers using tables Currently, the ravenscar-thread implementation for each architecture is written by hand. However, these are actually written by copy-paste. It seems better to switch to a table-driven approach. The previous code also fetched all registers whenever any register was requested. This is corrected in the new implementation.	4 years ago
Tom Tromey	2808125fbb	Fix bugs in aarch64-ravenscar-thread.c We found a few bugs in aarch64-ravenscar-thread.c. First, some of the register offsets were incorrect. The "bb-runtimes" file for this runtime had the wrong offsets in comments, which GDB took to be correct. However, those comments didn't account for alignment. This patch adjusts the offsets. Next, the "FPU Saved field" is not a register -- it is an implementation detail of the runtime. This is removed. Finally, I think the FP registers are actually named V0-V31, and the "Q" names are pseudo-registers. This patch fixes the comment.	4 years ago
Tom Tromey	edb6b77c75	Allow 'interrupt -a' in all-stop mode PR gdb/17160 points out that "interrupt -a" errors in all-stop mode, but there's no good reason for this. This patch removes the error. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17160	4 years ago
Youling Tang	e5ab6af52d	gdbserver: Add LoongArch/Linux support Implement LoongArch/Linux support, including XML target description handling based on features determined, GPR regset support, and software breakpoint handling. In the Linux kernel code of LoongArch, ptrace implements PTRACE_POKEUSR and PTRACE_PEEKUSR in the arch_ptrace function, so srv_linux_usrregs is set to yes. With this patch on LoongArch: $ make check-gdb TESTS="gdb.server/server-connect.exp" [...] # of expected passes 18 [...] Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>	4 years ago
Tom de Vries	476288fa2b	Revert "Fix fbsd core matching" This reverts commit `a7e29f797c`. I accidentally pushed this, so revert.	4 years ago
Tom de Vries	c5a72a8d1c	[gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp With gcc-12 and target board unix/-m32, we run into: ... (gdb) ^M Expecting: ^(-var-create A_String_Access \* A_String_Access[^M ]+)?(\^done,name="A_String_Access",numchild="1",.[^M ]+[(]gdb[)] ^M [ ]) -var-create A_String_Access * A_String_Access^M ^error,msg="Value out of range."^M (gdb) ^M FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output) ... What happens is easier to understand if we take things out of the mi context: ... $ gdb -q -batch \ outputs/gdb.ada/mi_var_access/mi_access \ -ex "b mi_access.adb:19" \ -ex run \ -ex "p A_String_Access" ... Breakpoint 1, mi_access () at mi_access.adb:19 19 A_String : String (3 .. 5) := "345"; -- STOP $1 = (pck.string_access) <error reading variable: Value out of range.> ... while with target board unix we have instead: ... $1 = (pck.string_access) 0x431b40 <ada_main.sec_default_sized_stacks> ... The var-create command samples the value of the variable at a location where the variable is not yet initialized, and with target board unix we accidentally hit a valid address, but with target board unix/-m32 that's not the case. Fix the FAIL by accepting the error message. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28464	4 years ago
Alan Modra	a7e29f797c	Fix fbsd core matching On Thu, Jun 09, 2022 at 08:59:37AM -0700, John Baldwin wrote: > On 6/9/22 1:58 AM, Tom de Vries via Gdb-patches wrote: > > Hi, > > > > With an --enable-targets=all build and target board unix/-m32 I run into a > > FAIL in test-case gdb.base/corefile.exp: > > ... > > (gdb) file outputs/gdb.base/corefile/corefile^M > > Reading symbols from outputs/gdb.base/corefile/corefile...^M > > (gdb) core-file outputs/gdb.base/corefile/corefile.core^M > > warning: core file may not match specified executable file.^M > > [New LWP 12011]^M > > Core was generated by `outputs/gdb.base/corefile/co'.^M > > Program terminated with signal SIGABRT, Aborted.^M > > (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free > > ... > > > > The warning is there because of this mismatch between core and exec: > > ... > > (gdb) p core_bfd->xvec > > $3 = (const struct bfd_target ) 0x20112a0 <i386_elf32_fbsd_vec> > > (gdb) p exec_bfd->xvec > > $4 = (const struct bfd_target ) 0x2010b00 <i386_elf32_vec> > > ... > > > > In the exec case, the detected architecture is i386_elf32_vec because this bit > > of code in elfcode.h:elf_object_p(): > > ... > > if (ebd->elf_machine_code != EM_NONE > > && i_ehdrp->e_ident[EI_OSABI] != ebd->elf_osabi > > && ebd->elf_osabi != ELFOSABI_NONE) > > goto got_wrong_format_error; > > ... > > prevents i386_elf32_fbsd from matching. > > > > Fix the core matching by copying that code to elfcore.h:elf_core_file_p(). > > > > Tested on x86_64-linux. > > > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29227 > > > > Any comments? Looks good. > Looking at elfcore.h, it seems to have not gotten changes made to elfcode.h over > time and is a bit rotted. I suspect that all of changes made in commit `0aabe54e62` > that added these lines in elfcode.h (along with several other changes) need to > be applied to this function in elfcore.h, not just adding these lines. Yes, the commit `0aabe54e62` changes likely should go in too. I'm a little wary of adding all the sanity checks to elf_core_file_p since that might result in some core files not being recognised at all. For example, despite the FIXME I'd guess leaving out the EI_VERSION check was deliberate. The following seems reasonable to me. Please test.	4 years ago
Kavitha Natarajan	6df97c56ea	Debug support for global alias variable Starting with (future) Clang 15 (since https://reviews.llvm.org/D120989), Clang emits the DWARF information of global alias variables as DW_TAG_imported_declaration. However, GDB does not handle it. It incorrectly always reads this tag as C++/Fortran imported declaration (type alias, namespace alias and Fortran module). This commit adds support to handle this tag as an alias variable. This change fixes the failures in the gdb.base/symbol-alias.exp testcase with current git Clang. This testcase is also updated to test nested (recursive) aliases.	4 years ago
Alan Modra	d712f2768a	BFD_RELOC_MIPS_16 MIPS should not be using BFD_RELOC_16 for its R_MIPS_16 relocation, since R_MIPS_16 specifies a 16-bit field in a 32-bit word. BFD_RELOC_16, emitted by generic code to handle fixups on 16-bit data directives, expects fixups to operate on the whole of a 16-bit word. This patch corrects the problem by using BFD_RELOC_MIPS_16, a new bfd reloc that is used to generate R_MIPS_16. BFD_RELOC_16 is handled in md_apply_fix for cases where the fixup can be applied at assembly time. Like BFD_RELOC_8, BFD_RELOC_16 now has no corresponding object file relocation, and thus .half, .hword, .short and .dc.w must be resolved at assembly time. BFD_RELOC_MIPS_REL16 is removed by this patch since it isn't used. PR 3243 PR 26542 * reloc.c (BFD_RELOC_MIPS_16): Rename from BFD_RELOC_MIPS_REL16. * elf32-mips.c (mips_reloc_map): Map BFD_RELOC_MIPS_16 to R_MIPS_16. * elf64-mips.c (mips_reloc_map): Likewise, delete BFD_RELOC_MIPS_REL16. * elfn32-mips.c (mips_reloc_map): Likewise. * libbfd.h: Regenerate. * bfd-in2.h: Regenerate. gas/ * config/tc-mips.c (append_insn): Handle BFD_RELOC_MIPS_16. (macro_build): Likewise. (mips_percent_op <%half>): Generate BFD_RELOC_MIPS_16. (md_apply_fix): Handle BFD_RELOC_16 and BFD_RELOC_MIPS_16 when fx_done. ld/ * testsuite/ld-mips-elf/reloc-local-overflow.d, * testsuite/ld-mips-elf/reloc-local-overflow.s: Rewrite.	4 years ago
Alan Modra	5f269b4620	Correct R_MIPS_16 n32 howto If the howto is actually used, an all-zero dst_mask will result in unchanged section contents on attempting to apply R_MIPS_16. * elfn32-mips.c (elf_mips_howto_table_rela <R_MIPS_16>): Correct dst_mask.	4 years ago
Alan Modra	22b8da0ae7	asan: applying zero offset to NULL pointer * dwarf.c (fetch_indexed_string): Move initialisation of "curr" and "end" after checking for missing section.	4 years ago
Alan Modra	82cb252432	gas dwarf2dbg.c tidy Make it a little more obvious that remap_debug_filename returns an allocated string (that should be freed) by returning a char * rather than const char . Free a few missed cases in dwarf2dbg.c, and free other memory allocated in dwarf2dbg.c. Also remove static initialisation of variables and initialise in dwarf2_init instead, in order to ensure gas state is saner for oss-fuzz. remap.c (remap_debug_filename): Remove const from return. * as.h (remap_debug_filename): Update prototype. * config/obj-elf.c (obj_elf_ident): Simplify free of remap_debug_filename output. * stabs.c (stabs_generate_asm_file): Likewise. * dwarf2dbg.c (dirs, dirs_in_use, dirs_allocated, current): Don't initialise statically.. (dwarf2_init): ..do so here, along with most other static vars. (assign_file_to_slot): Don't set files_allocated until we succeed in allocating memory. (purge_generated_debug): Add bool param, free more stuff if true. (dwarf2_directive_filename): Adjust purge_generated_debug call. (process_entries): Don't free line_entry here.. (dwarf2_cleanup): ..do so here instead, new function. (dwarf2_finish): Call dwarf2_cleanup. When chaining together subseg line entries, unhook entries from old subseg list. (dwarf2_directive_loc): Free remap_debug_filename string. (out_dir_and_file_list): Likewise. (out_debug_str): Likewise.	4 years ago
GDB Administrator	a2e7f81e38	Automatic date update in version.in	4 years ago
Tom de Vries	c2ac533e98	[gdb/testsuite] Fix gdb.reverse/test_ioctl_TCSETSW.exp with libc debuginfo When running test-case gdb.reverse/test_ioctl_TCSETSW.exp with glibc debuginfo installed, I run into: ... (gdb) PASS: gdb.reverse/test_ioctl_TCSETSW.exp: at TCSETSW call step^M __tcsetattr (fd=0, optional_actions=1, termios_p=0x7fffffffcf50) at \ ../sysdeps/unix/sysv/linux/tcsetattr.c:45^M 45 {^M (gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: handle TCSETSW ... The problem is that the step is expected to step over the call to tcsetattr, but due to glibc debuginfo being installed, we step into the call. Fix this by using next instead of step. Tested on x86_64-linux.	4 years ago
Tom de Vries	c722093960	[gdb] Avoid warnings in cooked_{read,write}_test for m68hc11 With --enable-targets=all we have: ... $ gdb -q -batch -ex "maint selftest" ... Running selftest regcache::cooked_read_test::m68hc11. warning: No frame soft register found in the symbol table. Stack backtrace will not work. Running selftest regcache::cooked_read_test::m68hc12. warning: No frame soft register found in the symbol table. Stack backtrace will not work. Running selftest regcache::cooked_read_test::m68hc12:HCS12. warning: No frame soft register found in the symbol table. Stack backtrace will not work. ... Likewise for regcache::cooked_write_test. The warning has no use in the selftest context. Fix this by skipping the specific selftests. Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29224	4 years ago
Tiezhu Yang	208b57e53e	gdb: LoongArch: Deal with atomic sequence We can't put a breakpoint in the middle of a ll/sc atomic sequence, so look for the end of the sequence and put the breakpoint there. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>	4 years ago
Sam James	c714aff10b	gdb: don't use bashism in configure test Results in configure output like: ``` checking for X... no /var/tmp/portage/sys-devel/gdb-12.1/work/gdb-12.1/gdb/configure: 18837: test: yes: unexpected operator checking whether to use babeltrace... auto ``` ... when /bin/sh is provided by a POSIX-compliant shell, like dash, instead of bash.	4 years ago
Jiangshuai Li	afd53c3c0a	gdb:csky add support target-descriptions for CSKY arch Registers in CSKY architecture included: 1. 32 gprs 2. 16 ars (alternative gprs used for quick interrupt) 3. hi, lo, pc 4. fr0~fr31, fcsr, fid, fesr 5. vr0~vr15 6. ((32 banks) * 32) cr regs (max 32 banks, 32 control regs a bank) For register names: Except over control registers, other registers, like gprs, hi, lo ... are fixed names. Among the 32*32 control registers, some used registers will have fixed names, others will have a default name "cpxcry". 'x' refers to bank, y refers index in the bank(a control register in bank 4 with index 14 will has a default name cp4cr14). For register numbers in GDB: We assign a fixed number to each register in GDB, like: r0~r31 with 0~31 hi, lo with 36, 37 fpu/vpu with 40~71 ... described in function csky_get_supported_register_by_index(). Function csky_get_supported_tdesc_registers_count(): To calculate the total number of registers that GDB can analyze, including those with fixed names and those with default register names. Function csky_get_supported_register_by_index(): To find a supported struct csky_supported_tdesc_register, return a struct include name with regnum via index. Arrays csky_supported_tdesc_feature_names[]: Include all supported feature names in tdesc-xmls. We use the information described above to load the register description file of the target from the stub. When loading, do a little check that whether the register description file contains SP, LR and PC.	4 years ago
Tom de Vries	f25123df34	[gdb/testsuite] Handle quotes in gdb_py_module_available On openSUSE Leap 42.3 with python 3.4, I run into: ... (gdb) python import pygments^M Traceback (most recent call last):^M File "<string>", line 1, in <module>^M ImportError: No module named 'pygments'^M Error while executing Python code.^M (gdb) FAIL: gdb.base/style.exp: python import pygments ERROR: unexpected output from python import ... because gdb_py_module_available doesn't handle the single quotes around the module name in the ImportError. Fix this by allowing the single quotes. Tested on x86_64-linux.	4 years ago
Jan Beulich	8025a16428	x86: fix incorrect indirection Commit `384e201e5a` ("x86: properly initialize struct instr_info instance(s)") was based on an improperly refreshed patch. Correct the oversight.	4 years ago
Jan Beulich	95ff671834	x86: replace global scratch buffer With its movement to the stack, and with the subsequent desire to initialize the entire instr_info instances, this has become doubly inefficient. Individual users have better knowledge of how big a buffer they need, and in a number of cases going through an intermediate buffer can be avoided altogether. Having got confirmation that it wasn't intentional to print memory operand displacements with inconsistent style, print_displacement() is now using dis_style_address_offset consistently (eliminating the need for callers to pass in a style). While touching print_operand_value() also convert its "hex" parameter to bool. And while altering (and moving) oappend_immediate(), fold oappend_maybe_intel_with_style() into its only remaining caller. Finally where doing adjustments, use snprintf() in favor of sprintf().	4 years ago
Jan Beulich	32f06c69f2	x86: avoid string copy when swapping Vex.W controlled operands Now that op_out[] is an array of pointers, there's no need anymore to copy strings. Simply swap the pointers.	4 years ago
Jan Beulich	eebc56d682	x86: shrink prefix related disassembler state fields By changing the values used for "artificial" prefix values, all_prefixes[] can be shrunk to array of unsigned char. All that additionally needs adjusting is the printing of possible apparently standalone prefixes when recovering from longjmp(): Simply check whether any prefixes were successfully decoded, to avoid converting opcode bytes matching the "artificial" values to prefix mnemonics. Similarly by re-arranging the bits assigned to PREFIX_* mask values we can fit all segment register masks in a byte and hence shrink active_seg_prefix to unsigned char. Somewhat similarly with last_*_prefix representing offsets into the opcode being disassembled, signed char is sufficient to hold all possible values.	4 years ago
Jan Beulich	384e201e5a	x86: properly initialize struct instr_info instance(s) Commit `39fb369834` ("opcodes: Make i386-dis.c thread-safe") introduced a lot of uninitialized data. Alan has in particular observed ubsan taking issue with the loop inverting the order of operands, where op_riprel[] - an array of bool - can hold values other than 0 or 1. Move instantiation of struct instr_info into print_insn() (thus having just a single central point), and make use of C99 dedicated initializers to fill fields right in the initializer where possible. This way all fields not explicitly initialized will be zero-filled, which in turn allows dropping of some other explicit initialization later in the function or in ckprefix(). Additionally this removes a lot of indirection, as all "ins->info" uses can simply become "info". Make one further arrangement though, to limit the amount of data needing (zero)initializing on every invocation: Convert the op_out structure member to just an array of pointers, with the actual arrays living inside print_insn() (and, as befoe, having just their 1st char filled with nul). While there, instead of adjusting print_insn()'s forward declaration, arrange for no such declaration to be needed in the first place.	4 years ago
GDB Administrator	536595b712	Automatic date update in version.in	4 years ago
Tom Tromey	aa09537375	Fix self-test failure in addrmap Mark pointed out that my recent addrmap C++-ficiation changes caused a regression in the self-tests. This patch fixes the problem by updating this test not to allocate the mutable addrmap on an obstack.	4 years ago
Tom Tromey	32681b482a	Remove psymtab_addrmap While working on addrmaps, I noticed that psymtab_addrmap is no longer needed now. It was introduced in ancient times as an optimization for DWARF, but no other symbol reader was ever updated to use it. Now that DWARF does not use psymtabs, it can be deleted.	4 years ago
Tom Tromey	93b527ef78	Use malloc for mutable addrmaps Mutable addrmaps currently require an obstack. This was probably done to avoid having to call splay_tree_delete, but examination of the code shows that all mutable obstacks have a limited lifetime -- now it's simple to treat them as ordinary C++ objects, in some cases stack-allocating them, and have a destructor to make the needed call. This patch implements this change.	4 years ago
Tom Tromey	d89120e949	Remove addrmap::create_fixed addrmap::create_fixed is just a simple wrapper for 'new', so remove it in favor of uses of 'new'.	4 years ago
Tom Tromey	10cce2c441	Remove addrmap_create_mutable This removes addrmap_create_mutable in favor of using 'new' at the spots where the addrmap is created.	4 years ago
Tom Tromey	769520b7e5	Remove addrmap wrapper functions This removes the various addrmap wrapper functions in favor of simple method calls on the objects themselves.	4 years ago
Tom Tromey	1b3261edfb	Move addrmap classes to addrmap.h This moves the addrmap class definitions to addrmap.h. This is safe to do now that the contents are private.	4 years ago
Tom Tromey	9d45ec63a5	Privacy for addrmap_mutable This changes addrmap_mutable so that its data members are private.	4 years ago
Tom Tromey	5427f03f9e	Privacy for addrmap_fixed This changes addrmap_fixed so that its data members are private. It also makes struct addrmap_transition private as well.	4 years ago
Tom Tromey	a692aa3f1d	Use inheritance for addrmap This is a simply C++-ification of the basics of addrmap: it uses virtual methods rather than a table of function pointers, and it changes the concrete implementations to be subclasses.	4 years ago
Jon Turney	9dad432e10	Trivial fixes to Cygwin build after `8fea1a81` * Remove a stray semicolon * Restore dropped nullptr program argument in use of create_process() under CYGWIN	4 years ago
Jon Turney	09d5a3fffc	Simplify __USEWIDE Prior to `c6ca3dab` dropping support for Cygwin 1.5, __USEWIDE was not defined for Cygwin 1.5. After that, it's always defined if __CYGWIN__ is, so remove __USEWIDE conditionals inside __CYGWIN__ conditionals.	4 years ago
Jon Turney	7d941aa3aa	Simplify cygwin_buf_t Prior to `c6ca3dab` dropping support for Cygwin 1.5, cygwin_buf_t was defined as char for Cygwin 1.5. After that, it's always wchar_t, so just use that.	4 years ago
GDB Administrator	18a7c0667f	Automatic date update in version.in	4 years ago
GDB Administrator	bc574253cb	Automatic date update in version.in	4 years ago
Tom Tromey	2cbde639ae	Fix warning-avoidance initialization in xcoffread.c With the registry rewrite series, on Fedora 34, I started seeing this error in xcoffread.c: ../../binutils-gdb/gdb/xcoffread.c: In function ‘void read_xcoff_symtab(objfile, legacy_psymtab)’: ../../binutils-gdb/gdb/xcoffread.c:948:25: error: ‘main_aux’ is used uninitialized [-Werror=uninitialized] 948 \| union internal_auxent fcn_aux_saved = main_aux; \| ^~~~~~~~~~~~~ ../../binutils-gdb/gdb/xcoffread.c:933:25: note: ‘main_aux’ declared here 933 \| union internal_auxent main_aux; \| ^~~~~~~~ I don't know why this error started suddenly... that seems weird, because it's not obviously related to the changes I made. Looking into it, it seems this line was intended to avoid a similar warning -- but since 'main_aux' is uninitialized at the point where it is used, this fix was incomplete. This patch avoids the warning by initializing using "{}". I'm checking this in.	4 years ago
Carl Love	cbc30d36ac	Fix comparison of unsigned long int to int in record_linux_system_call. The if statement in case gdb_sys_ioctl in function record_linux_system_call in file gdb/linux-record.c is as follows: if (tmpulongest == tdep->ioctl_FIOCLEX \|\| tmpulongest == tdep->ioctl_FIONCLEX .... \|\| tmpulongest == tdep->ioctl_TCSETSW ... } The PowerPC ioctl value for ioctl_TCSETW is 0x802c7415. The variable ioctl_TCSETW is defined in gdb/linux-record.h as an int. The TCSETW value has the MSB set to one so it is a negative integer. The comparison of the unsigned long value tmpulongest to a negative integer value for ioctl_TCSETSW fails. This patch changes the declarations for the ioctl_* values in struct linux_record_tdep to unsigned long to fix the comparisons between tmpulongest and the tdep->ioctl_* values. An additional test gdb.reverse/test_ioctl_TCSETSW.exp is added to verify the gdb record_linux_system_call() if statement for the ioctl TCSETSW succeeds. This patch has been tested on Power 10 and Intel with no test failures.	4 years ago
Carl Love	b69a68b93b	PowerPC, correct the gdb ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF. Some of the ioctl numbers are based on the size of kernel termios structure. Currently the PowerPC GDB definitions are "hard coded" into the ioctl number. The current PowerPC values for TCGETS, TCSETS, TCSETSW and TCSETSF are defined in gdb/ppc-linux-tdep.c as: record_tdep->ioctl_TCGETS = 0x403c7413; record_tdep->ioctl_TCSETS = 0x803c7414; record_tdep->ioctl_TCSETSW = 0x803c7415; record_tdep->ioctl_TCSETSF = 0x803c7416; Where the termios structure size is in hex digits [5:4] as 0x3c. The definition for the PowerPC termios structure is given in: arch/powerpc/include/uapi/asm/termbits.h The size of the termios data structure in this file is 0x2c not 0x3c. This patch changes the hex digits for the size of the PowerPC termios size in the ioctl values for TCGETS, TCSETS, TCSETSW and TCSETSF to 0x2c. This patch also changes the hard coding to generate the number based on a it easier to update the ioctl numbers.	4 years ago
Andrew Burgess	80c0a3bf1b	gdb/testsuite: remove definition of true/false from gdb_compiler_info Since pretty much forever the get_compiler_info function has included these lines: # Most compilers will evaluate comparisons and other boolean # operations to 0 or 1. uplevel \#0 { set true 1 } uplevel \#0 { set false 0 } These define global variables true (to 1) and false (to 0). It seems odd to me that these globals are defined in get_compiler_info, I guess maybe the original thinking was that if a compiler had different true/false values then we would detect it there and define true/false differently. I don't think we should be bundling this logic into get_compiler_info, it seems weird to me that in order to use $true/$false a user needs to first call get_compiler_info. It would be better I think if each test script that wants these variables just defined them itself, if in the future we did need different true/false values based on compiler version then we'd just do: if { [test_compiler_info "some_pattern"] } { # Defined true/false one way... } else { # Defined true/false another way... } But given the current true/false definitions have been in place since at least 1999, I suspect this will not be needed any time soon. Given that the definitions of true/false are so simple, right now my suggestion is just to define them in each test script that wants them (there's not that many). If we ever did need more complex logic then we can always add a function in gdb.exp that sets up these globals, but that seems overkill for now. There should be no change in what is tested after this commit.	4 years ago
Luis Machado	3abc1d8fe0	Document the ARM_CC_FOR_TARGET testsuite variable This variable is useful when exercising AArch64 multi-arch support (debugging 32-bit AArch32 executables). Unfortunately it isn't well documented. This patch adds information about it and explains how to use it.	4 years ago
Tom de Vries	6a72edd8e2	[gdb/testsuite] Fix XPASS with gcc-12 in gdb.base/vla-struct-fields.exp With gcc-12, I get for test-case gdb.base/vla-struct-fields.exp: ... (gdb) print inner_vla_struct_object_size == sizeof(inner_vla_struct_object)^M $7 = 1^M (gdb) XPASS: gdb.base/vla-struct-fields.exp: size of inner_vla_struct_object ... Fix this by limiting the xfailing to gcc-11 and earlier. Also, limit the xfailing to the equality test. Tested on x86_64-linux.	4 years ago

1 2 3 4 5 ...

110433 Commits (08328cfbafcebac5dac058e2d568d9b2fd3ee478) All Branches Search

110433 Commits (08328cfbafcebac5dac058e2d568d9b2fd3ee478)

All Branches