binutils-gdb

Commit Graph

Author	SHA1	Message	Date
Andrew Burgess	76b43c9b5c	gdb: improve error reporting from the disassembler If the libopcodes disassembler returns a negative value then this indicates that the disassembly failed for some reason. In disas.c, in the function gdb_disassembler::print_insn we can see how this is handled; when we get a negative value back, we call the memory_error function, which throws an exception. The problem here is that the address used in the memory_error call is gdb_disassembler::m_err_memaddr, which is set in gdb_disassembler::dis_asm_memory_error, which is called from within the libopcodes disassembler through the disassembler_info::memory_error_func callback. However, for this to work correctly, every time the libopcodes disassembler returns a negative value, the libopcodes disassembler must have first called the memory_error_func callback. My first plan was to make m_err_memaddr a gdb::optional, and assert that it always had a value prior to calling memory_error, however, a quick look in opcodes/*-dis.c shows that there _are_ cases where a negative value is returned without first calling the memory_error_func callback, for example in arc-dis.c and cris-dis.c. Now, I think that a good argument can be made that these disassemblers must therefore be broken, except for the case where we can't read memory, we should always be able to disassemble the memory contents to _something_, even if it's just '.word 0x....'. However, I certainly don't plan to go and fix all of the disassemblers. What I do propose to do then, is make m_err_memaddr a gdb::optional, but now, instead of always calling memory_error, I add a new path which just calls error complaining about an unknown error. This new path is only used if m_err_memaddr doesn't have a value (indicating that the memory_error_func callback was not called). To test this I just augmented one of the disassemblers to always return -1, before this patch I see this: Dump of assembler code for function main: 0x000101aa <+0>: Cannot access memory at address 0x0 And after this commit I now see: Dump of assembler code for function main: 0x000101aa <+0>: unknown disassembler error (error = -1) This doesn't really help much, but that's because there's no way to report non memory errors out of the disasembler, because, it was not expected that the disassembler would ever report non memory errors.	5 years ago
Tom de Vries	38b03d23c7	[gdb/testsuite] Fix gdb.fortran/call-no-debug.exp with native-gdbserver When running test-case gdb.fortran/call-no-debug.exp with target board native-gdbserver, I run into: ... (gdb) PASS: gdb.fortran/call-no-debug.exp: print string_func_ (&'abcdefg', 3) call (integer) string_func_ (&'abcdefg', 3)^M $2 = 0^M (gdb) FAIL: gdb.fortran/call-no-debug.exp: call (integer) string_func_ (&'abcdefg', 3) ... The problem is that gdb_test is used to match inferior output. Fix this by using gdb_test_stdio. Tested on x86_64-linux.	5 years ago
Tom de Vries	2786ef85fa	[gdb/testsuite] Require use_gdb_stub == 0 where appropriate When running with target board native-gdbserver, we run into a number of FAILs due to use of the start command (and similar), which is not supported when use_gdb_stub == 1. Fix this by: - requiring use_gdb_stub == 0 for the entire test-case, or - guarding some tests in the test-case with use_gdb_stub == 0. Tested on x86_64-linux.	5 years ago
Tom de Vries	36170420e3	[gdb/testsuite] Fix test name in gdb.python/python.exp When running test-case gdb.python/python.exp, we have: ... PASS: gdb.python/python.exp: starti via gdb.execute, not from tty PASS: gdb.python/python.exp: starti via interactive input ... The two tests are instances of the same test, with different values for starti command argument from_tty, so it's strange that the test names are so different. This is due to using a gdb_test nested in a gdb_test_multiple, with the inner one using a different test name than the outer one. [ That could still make sense if both produced passes, but that's not the case here. ] Fix this by using $gdb_test_name, such that we have: ... PASS: gdb.python/python.exp: starti via gdb.execute, not from tty PASS: gdb.python/python.exp: starti via gdb.execute, from tty ... Also make this more readable by using variables. Tested on x86_64-linux.	5 years ago
Tom de Vries	746723ba6c	[gdb/testsuite] Fix gdb.base/batch-exit-status.exp with native-gdbserver When running test-case gdb.base/batch-exit-status.exp with target board native-gdbserver, I run into (added missing double quotes for clarity): ... builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \ -data-directory $build/gdb/testsuite/../data-directory \ -iex "set height 0" -iex "set width 0" \ -ex "set auto-connect-native-target off" \ -iex "set sysroot" -batch ""^M : No such file or directory.^M PASS: gdb.base/batch-exit-status.exp: 1x: \ No such file or directory: [lindex $result 2] == 0 FAIL: gdb.base/batch-exit-status.exp: 1x: \ No such file or directory: [lindex $result 3] == $expect_status ... As in commit `a02a90c114` "[gdb/testsuite] Set sysroot earlier in local-board.exp", the problem is the use of -ex for "set auto-connect-native-target off", which makes that the last command to be executed, and consequently determines the return status. Fix this by using -iex instead. Tested on x86_64-linux.	5 years ago
Tom de Vries	7110a5d8e8	[gdb/testsuite] Remove quit in gdb.arch/i386-mpx.exp When running test-case gdb.arch/i386-mpx.exp with target board native-gdbserver, I run into: ... (gdb) PASS: gdb.arch/i386-mpx.exp: verify size for bnd0 Remote debugging from host ::1, port 42328^M quit^M A debugging session is active.^M ^M Inferior 1 [process 19679] will be killed.^M ^M Quit anyway? (y or n) monitor exit^M Please answer y or n.^M A debugging session is active.^M ^M Inferior 1 [process 19679] will be killed.^M ^M Quit anyway? (y or n) WARNING: Timed out waiting for EOF in server after monitor exit ... The problem is that the test-case sends a quit at the end (without verifying the result of this in any way): ... send_gdb "quit\n" ... Fix this by removing the quit. Tested on x86_64-linux.	5 years ago
GDB Administrator	777b054cf9	Automatic date update in version.in	5 years ago
GDB Administrator	255a531196	Automatic date update in version.in	5 years ago
Srinath Parvathaneni	ae66a8f19e	[ARM] Add support for M-profile MVE extension This patch adds support for the M-profile MVE extension, which includes the following: - New M-profile XML feature m-profile-mve - MVE vector predication status and control register (VPR) - p0 pseudo register (contained in the VPR) - q0 ~ q7 pseudo vector registers - New feature bits - Documentation update Pseudo register p0 is the least significant bits of vpr and can be accessed as $p0 or displayed through $vpr. For more information about the register layout, please refer to [1]. The q0 ~ q7 registers map back to the d0 ~ d15 registers, two d registers per q register. The register dump looks like this: (gdb) info reg all r0 0x0 0 r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 sp 0x0 0x0 <__Vectors> lr 0xffffffff -1 pc 0xd0c 0xd0c <Reset_Handler> xpsr 0x1000000 16777216 d0 0 (raw 0x0000000000000000) d1 0 (raw 0x0000000000000000) d2 0 (raw 0x0000000000000000) d3 0 (raw 0x0000000000000000) d4 0 (raw 0x0000000000000000) d5 0 (raw 0x0000000000000000) d6 0 (raw 0x0000000000000000) d7 0 (raw 0x0000000000000000) d8 0 (raw 0x0000000000000000) d9 0 (raw 0x0000000000000000) d10 0 (raw 0x0000000000000000) d11 0 (raw 0x0000000000000000) d12 0 (raw 0x0000000000000000) d13 0 (raw 0x0000000000000000) d14 0 (raw 0x0000000000000000) d15 0 (raw 0x0000000000000000) fpscr 0x0 0 vpr 0x0 [ P0=0 MASK01=0 MASK23=0 ] s0 0 (raw 0x00000000) s1 0 (raw 0x00000000) s2 0 (raw 0x00000000) s3 0 (raw 0x00000000) s4 0 (raw 0x00000000) s5 0 (raw 0x00000000) s6 0 (raw 0x00000000) s7 0 (raw 0x00000000) s8 0 (raw 0x00000000) s9 0 (raw 0x00000000) s10 0 (raw 0x00000000) s11 0 (raw 0x00000000) s12 0 (raw 0x00000000) s13 0 (raw 0x00000000) s14 0 (raw 0x00000000) s15 0 (raw 0x00000000) s16 0 (raw 0x00000000) s17 0 (raw 0x00000000) s18 0 (raw 0x00000000) s19 0 (raw 0x00000000) s20 0 (raw 0x00000000) s21 0 (raw 0x00000000) s22 0 (raw 0x00000000) s23 0 (raw 0x00000000) s24 0 (raw 0x00000000) s25 0 (raw 0x00000000) s26 0 (raw 0x00000000) s27 0 (raw 0x00000000) s28 0 (raw 0x00000000) s29 0 (raw 0x00000000) s30 0 (raw 0x00000000) s31 0 (raw 0x00000000) q0 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q1 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q2 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q3 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q4 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q5 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q6 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q7 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} p0 0x0 0 Built and regtested with a simulator. [1] https://developer.arm.com/documentation/ddi0553/bn Co-Authored-By: Luis Machado <luis.machado@linaro.org>	5 years ago
Luis Machado	ecbf5d4f9b	[ARM] Refactor pseudo register numbering The pseudo register handling for ARM uses some hardcoded constants to determine types and names. In preparation to the upcoming MVE support patch (that will add another pseudo register), this patch refactors and reorganizes things in order to simplify handling of future pseudo registers. We keep track of the first pseudo register number in a group and the number of pseudo registers in that group. Right now we only have the S and Q pseudo registers.	5 years ago
Luis Machado	dc22c61a16	[ARM] Small refactoring of arm gdbarch initialization This is in preparation to MVE support, where we will define another pseudo register. We need to define the pseudo register numbers after accounting for all the registers in the XML description, so move the call to tdesc_use_registers up. If we don't do it, GDB's register count won't consider registers contained in the XML but ignored by GDB, throwing the register numbering off.	5 years ago
Luis Machado	4d224f4a58	[ARM] Refactor some constants In preparation for the MVE extension patch, this one refactors some of the register-related constants we have for ARM. Basically I'm separating counting constants from numbering constants. For example, ARM_A1_REGNUM is a numbering constant, whereas ARM_NUM_ARG_REGS is a counting constant.	5 years ago
Tom de Vries	c8ed8c8ac3	[gdb/testsuite] Fix FAIL in gdb.mi/mi-var-child-f.exp When running test-case gdb.mi/mi-var-child-f.exp on openSUSE Tumbleweed (with glibc 2.34) I run into: ... (gdb) ^M PASS: gdb.mi/mi-var-child-f.exp: mi runto prog_array Expecting: ^(-var-create array \* array[^M ]+)?(\^done,name="array",numchild="[0-9]+",value=".",type=.,has_more="0"[^M ]+[(]gdb[)] ^M [ ]) -var-create array array^M &"Attempt to use a type name as an expression.\n"^M ^error,msg="-var-create: unable to create variable object"^M (gdb) ^M FAIL: gdb.mi/mi-var-child-f.exp: create local variable array (unexpected output) ... The problem is that the name array is used both: - as the name for a local variable - as the name of a type in glibc, in file malloc/dynarray-skeleton.c, as included by nss/nss_files/files-hosts.c. Fix this by ignoring the shared lib symbols. Likewise in a couple of other fortran tests. Tested on x86_64-linux.	5 years ago
Andrew Burgess	3a480f1e35	z80/disassembler: call memory_error_func when appropriate If a call to the read_memory_func fails then we should call the memory_error_func to notify the user of the disassembler of the address that was a problem. Without this GDB will report all memory errors as being at address 0x0. opcodes/ChangeLog: * z80-dis.c (fetch_data): Call memory_error_func if the read_memory_func call fails.	5 years ago
Andrew Burgess	ba7c18a484	s12z/disassembler: call memory_error_func when appropriate If a call to the read_memory_func fails then we should call the memory_error_func to notify the user of the disassembler of the address that was a problem. Without this GDB will report all memory errors as being at address 0x0. opcodes/ChangeLog: * s12z-disc.c (abstract_read_memory): Call memory_error_func if the read_memory_func call fails.	5 years ago
Tom de Vries	c2c8a42788	[gdb/testsuite] Fix double debug info in gdb.dwarf2/dw2-ref-missing-frame.exp A mistake slipped in in commit `a5ea23036d` "[gdb/testsuite] Use function_range in gdb.dwarf2/dw2-ref-missing-frame.exp". Before the commit the main file was compiled with debug info, and the two others not: ... if {[prepare_for_testing_full "failed to prepare" \ [list $testfile {} $srcfile {} $srcfuncfile {} \ $srcmainfile debug]]} { ... After the commit, all were compiled with debug info, and consequently, there are two versions of debug info for $srcfuncfile. This shows up as a FAIL when running the test-case with target boards readnow and cc-with-debug-names. Fix this by using prepare_for_testing_full, as before. Tested on x86_64-linux. Fixes: `a5ea23036d` ("[gdb/testsuite] Use function_range in gdb.dwarf2/dw2-ref-missing-frame.exp")	5 years ago
Tom de Vries	19abf6c542	[gdb/testsuite] Use require for ensure_gdb_index Replace: ... if { [ensure_gdb_index $binfile] == -1 } { return -1 } ... with: ... require {ensure_gdb_index $binfile} != -1 ... and consequently, add a missing UNTESTED message. Tested on x86_64-linux, both with native and target board readnow.	5 years ago
Tom de Vries	dbfc69bef9	[gdb/testsuite] Handle readnow in ensure_gdb_index When running test-case gdb.base/with-mf.exp with target board readnow, I run into: ... FAIL: gdb.base/with-mf.exp: check if index present ... This is since commit `6010fb0c49` "[gdb/testsuite] Fix full buffer in gdb.rust/dwindex.exp". Before that commit, the proc ensure_gdb_index would treat the line: ... .gdb_index: faked for "readnow"^M ... as proof that an index is already present (which is incorrect). Now, instead it generates aforementioned FAIL and continues to generate an index. Fix this by explicitly handling the readnow case in proc ensure_gdb_index, such that we bail out instead. Tested on x86_64-linux.	5 years ago
Tom de Vries	47265957ad	[gdb/testsuite] Fix gdb.dwarf2/gdb-add-index-symlink.exp The test-case gdb.dwarf2/gdb-add-index-symlink.exp interpretes a failure to add an index as a failure to add an index for a symlink: ... if { [ensure_gdb_index $symlink] == -1 } { fail "Unable to call gdb-add-index with a symlink to a symfile" return -1 } ... However, it's possible that the gdb-add-index also fails with a regular file. Add a check for that situation. Tested on x86_64-linux.	5 years ago
Tom de Vries	4f69f0a21e	[gdb/testsuite] Add proc require in lib/gdb.exp Add a new proc require in lib/gdb.exp, and use it to shorten: ... if { [gdb_skip_xml_test] } { # Valgrind gdbserver requires gdb with xml support. untested "missing xml support" return 0 } ... into: ... require gdb_skip_xml_test 0 ... Tested on x86_64-linux, both with and without a trigger patch that forces gdb_skip_xml_test to return 1.	5 years ago
Michael Forney	b6fca8a3d5	bfd: Remove use of void pointer arithmetic This is not valid in ISO C. Instead, use a pointer to bfd_byte. * peicode.h (pe_bfd_object_p): Remove use of void pointer arithmetic.	5 years ago
GDB Administrator	88b3223704	Automatic date update in version.in	5 years ago
GDB Administrator	902ad3d703	Automatic date update in version.in	5 years ago
Tom de Vries	84a6adfd4c	[gdb] Make execute_command_to_string return string on throw The pattern for using execute_command_to_string is: ... std::string output; output = execute_fn_to_string (fn, term_out); ... This results in a problem when using it in a try/catch: ... try { output = execute_fn_to_string (fn, term_out) } catch (const gdb_exception &e) { /* Use output. */ } ... If an expection was thrown during execute_fn_to_string, then the output remains unassigned, while it could be worthwhile to known what output was generated by gdb before the expection was thrown. Fix this by returning the string using a parameter instead: ... execute_fn_to_string (output, fn, term_out) ... Also add a variant without string parameter, to support places where the function is used while ignoring the result: ... execute_fn_to_string (fn, term_out) ... Tested on x86_64-linux.	5 years ago
Tom de Vries	fa9ce2c143	[gdb/testsuite] Add check-readmore Consider the gdb output: ... 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);^M (gdb) ^M Thread 2 "run-attach-whil" stopped.^M ... When trying to match the gdb prompt using gdb_test which uses '$gdb_prompt $', it may pass or fail. This sort of thing needs to be fixed (see commit `b0e2f96b56`), but there's currently no way to reliably find this type of FAILs. We have check-read1, but that one actually make the test pass reliably. We need something like the opposite of check-read1: something that makes expect read a bit slower, or more exhaustively. Add a new test target check-readmore that implements this. There are two methods of implementing this in read1.c: - the first method waits a bit before doing a read - the second method does a read and then decides whether to return or to wait a bit and do another read, and so on. The second method is potentially faster, has less risc of timeout and could potentially detect more problems. The first method has a simpler implementation. The second method is enabled by default. The default waiting period is 10 miliseconds. The first method can be enabled using: ... $ export READMORE_METHOD=1 ... and the waiting period can be specified in miliseconds using: ... $ export READMORE_SLEEP=9 ... Also a log file can be specified using: ... $ export READMORE_LOG=$(pwd -P)/LOG ... Tested on x86_64-linux. Testing with check-readmore showed these regressions: ... FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: run: stop with control-c (continue) FAIL: gdb.base/bp-cmds-continue-ctrl-c.exp: attach: stop with control-c (continue) ... I have not been able to find a problem in the test-case, and I think it's the nature of both the test-case and readmore that makes it run longer. Make these pass by increasing the alarm timeout from 60 to 120 seconds. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27957	5 years ago
Tom de Vries	f9edf60830	[gdb/testsuite] Fix fortran module tests with stressed cpu When running these test-cases: - gdb.fortran/info-modules.exp - gdb.fortran/module.exp - gdb.mi/mi-fortran-modules.exp in conjunction with: ... $ stress -c $(($(cat /proc/cpuinfo \| grep -c "^processor") + 1)) ... I run into timeouts. Fix this by using: - "set auto-solib-add off" to avoid symbols of shared libs (which doesn't work for libc, now that libpthread_name_p has been updated to match libc) - "nosharedlibrary" to avoid symbols of libc Tested on x86_64-linux. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28133	5 years ago
Guillermo E. Martinez	0161bdd47c	PR28415, invalid read in xtensa_read_table_entries PR 28415 PR 28416 * elf32-xtensa.c (xtensa_read_table_entries): Handle error return from retrieve_contents.	5 years ago
GDB Administrator	851a4f24d7	Automatic date update in version.in	5 years ago
Tom de Vries	b886031bd2	[gdb/testsuite] Fix gdb.base/info-types-c++.exp with stressed cpu When running test-case gdb.base/info-types-c++.exp in conjunction with: ... $ stress -c $(($(cat /proc/cpuinfo \| grep -c "^processor") + 1)) ... we get: ... FAIL: gdb.base/info-types-c++.exp: info types (timeout) ... Fix this by setting auto-solib-add to off. Tested on x86_64-linux.	5 years ago
Tom de Vries	048cb8b466	[gdb/testsuite] Fix gdb.base/info_sources_2.exp with check-read1 When running test-case gdb.base/info_sources_2.exp with check-read1, I run into: ... FAIL: gdb.base/info_sources_2.exp: args: : info sources (timeout) ... Fix this by consuming a "$src1, $src2, ..., $srcn: line bit by bit rather than as one whole line. Also add the missing handling of "Objfile has no debug information". Tested on x86_64-linux.	5 years ago
Tom de Vries	2550e478ad	[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1 When running test-case gdb.mi/gdb2549.exp with check-read1, I run into: ... FAIL: gdb.mi/gdb2549.exp: register values x (timeout) ... Fix this by applying the same fix as for "register values t" in commit `478e490a4d` "[gdb/testsuite] Fix gdb.mi/gdb2549.exp with check-read1". Tested on x86_64-linux.	5 years ago
Tom de Vries	8320b04230	[gdb/testsuite] Fix gdb.base/bt-on-error-and-warning.exp with check-read1 When running test-case gdb.base/bt-on-error-and-warning.exp with check-read1, I run into: ... (gdb) maint internal-error foobar^M src/gdb/maint.c:82: internal-error: foobar^M A problem internal to GDB has been detectedFAIL: \ gdb.base/bt-on-error-and-warning.exp: problem=internal-error, mode=on: \ scan for backtrace (GDB internal error) Resyncing due to internal error. ,^M ... The corresponding gdb_test_multiple in the test-case contains: ... -early -re "^A problem internal to GDB has been detected,\r\n" { incr header_lines exp_continue } ... but instead this one triggers in gdb_test_multiple: ... -re ".*A problem internal to GDB has been detected" { fail "$message (GDB internal error)" gdb_internal_error_resync set result -1 } ... Fix this by likewise shortening the regexp to before the comma. Tested on x86_64-linux.	5 years ago
Tom de Vries	b80e6295f6	[gdb/testsuite] Add nopie in two test-cases When running test-case gdb.dwarf2/dw2-restrict.exp on openSUSE Leap 15.2 with gcc-PIE installed (switching compiler default to -fPIE/-pie), I get: ... gdb compile failed, ld: outputs/gdb.dwarf2/dw2-restrict/dw2-restrict0.o: \ warning: relocation in read-only section `.text' ld: warning: creating DT_TEXTREL in a PIE UNTESTED: gdb.dwarf2/dw2-restrict.exp: failed to prepare ... This is due to using a hardcoded .S file that was generated with -fno-PIE. Fix this by adding the missing nopie. Likewise in gdb.arch/amd64-tailcall-noret.exp. Tested on x86_64-linux.	5 years ago
GDB Administrator	fc6e66cd18	Automatic date update in version.in	5 years ago
Tom de Vries	d7a6aa74c8	[gdb/testsuite] Fix gdb.threads/check-libthread-db.exp with glibc 2.34 When running test-case gdb.threads/check-libthread-db.exp on openSUSE Tumbleweed (with glibc 2.34) I get: ... (gdb) continue^M Continuing.^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M Stopped due to shared library event:^M Inferior loaded /lib64/libm.so.6^M /lib64/libc.so.6^M (gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: continue ... The check expect the inferior to load libpthread, but since glibc 2.34 libpthread has been integrated into glibc, and consequently it's no longer a dependency: ... $ ldd outputs/gdb.threads/check-libthread-db/check-libthread-db linux-vdso.so.1 (0x00007ffe4cae4000) libm.so.6 => /lib64/libm.so.6 (0x00007f167c77c000) libc.so.6 => /lib64/libc.so.6 (0x00007f167c572000) /lib64/ld-linux-x86-64.so.2 (0x00007f167c86e000) ... Fix this by updating the regexp to expect libpthread or libc. Tested on x86_64-linux.	5 years ago
Tom de Vries	22589c4996	[gdb/testsuite] Fix gdb.guile/scm-type.exp with gcc 4.8 With gcc 7.5.0, I get: ... (gdb) guile (print (type-range (field-type (type-field (value-type \ (value-dereference f)) "items"))))^M = (0 0)^M (gdb) PASS: gdb.guile/scm-type.exp: lang_cpp: test_range: \ on flexible array member: $cmd ... but with gcc 4.8.5, I get instead: ... (gdb) guile (print (type-range (field-type (type-field (value-type \ (value-dereference f)) "items"))))^M = (0 -1)^M (gdb) FAIL: gdb.guile/scm-type.exp: lang_cpp: test_range: \ on flexible array member: $cmd ... There's a difference in debug info. With gcc 4.8.5, we have: ... <2><224>: Abbrev Number: 15 (DW_TAG_member) <225> DW_AT_name : items <22b> DW_AT_type : <0x231> <1><231>: Abbrev Number: 4 (DW_TAG_array_type) <232> DW_AT_type : <0x105> <2><23a>: Abbrev Number: 16 (DW_TAG_subrange_type) <23b> DW_AT_type : <0x11a> <23f> DW_AT_upper_bound : 0xffffffffffffffff ... and with gcc 7.5.0, we have instead: ... <2><89f>: Abbrev Number: 12 (DW_TAG_member) <8a0> DW_AT_name : items <8a6> DW_AT_type : <0x8ac> <1><8ac>: Abbrev Number: 17 (DW_TAG_array_type) <8ad> DW_AT_type : <0x29d> <2><8b5>: Abbrev Number: 41 (DW_TAG_subrange_type) <2><8b6>: Abbrev Number: 0 ... As mentioned in commit `858c8f2c1b` "gdb/testsuite: adjust gdb.python/flexible-array-member.exp expected pattern": ... Ideally, GDB would present a consistent and documented value for an array member declared with size 0, regardless of how the debug info looks like. ... As in gdb.python/flexible-array-member.exp, change the test to accept the two values. Tested on x86_64-linux.	5 years ago
Simon Marchi	cd3f655cc7	gdb: add accessors for field (and call site) location Add accessors for the various location values in struct field. This lets us assert that when we get a location value of a certain kind (say, bitpos), the field's location indeed contains a value of that kind. Remove the SET_FIELD_* macros, instead use the new setters directly. Update the FIELD_* macros used to access field locations to go through the getters. They will be removed in a subsequent patch. There are places where the FIELD_* macros are used on call_site_target structures, because it contains members of the same name (loc_kind and loc). For now, I have replicated the getters/setters in call_site_target. But we could perhaps eventually factor them in a "location" structure that can be used at both places. Note that the field structure, being zero-initialized, defaults to a bitpos location with value 0. While writing this patch, I tried to make it default to an "unset" location, to catch places where we would miss setting a field's location. However, I found that some places relied on the default being "bitpos 0", so I left it as-is. This change could always be done as follow-up work, making these places explicitly set the "bitpos 0" location. I found two issues to fix: - I got some failures in the gdb.base/infcall-nested-structs-c++.exp test. They were caused by two functions in amd64-tdep.c using TYPE_FIELD_BITPOS before checking if the location is of the bitpos kind, which they do indirectly through `field_is_static`. Simply move getting the bitpos below the field_is_static call. - I got a failure in gdb.xml/tdesc-regs.exp. It turns out that in make_gdb_type_enum, we set enum field values using SET_FIELD_BITPOS, and later access them through FIELD_ENUMVAL. Fix that by using set_loc_enumval to set the value. Change-Id: I53d3734916c46457576ba11dd77df4049d2fc1e8	5 years ago
Philipp Tomsich	8baf3d0756	RISC-V: Support aliases for Zbs instructions Add aliases for the non-immediate mnemonics of b{set,clr,inv,ext} to yencode the respective immediate insn b{set,clr,inv,ext}i when the second source operand is an immediate. 2021-01-11 Philipp Tomsich <philipp.tomsich@vrull.eu> gas/ * testsuite/gas/riscv/b-ext.d: Add tests. * testsuite/gas/riscv/b-ext.s: Likewise. * testsuite/gas/riscv/b-ext-64.d: Likewise. * testsuite/gas/riscv/b-ext-64.s: Likewise. opcodes/ * riscv-opc.c (riscv_opcodes): Add aliases for Zbs. Suggested-by: Jan Beulich <jbeulich@suse.com> Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>	5 years ago
Philipp Tomsich	9455c91957	RISC-V: Add support for Zbs instructions This change adds the Zbs instructions from the Zbs 1.0.0 specification. See https://github.com/riscv/riscv-bitmanip/releases/tag/1.0.0 for the frozen specification. 2021-01-09 Philipp Tomsich <philipp.tomsich@vrull.eu> bfd/ * elfxx-riscv.c (riscv_supported_std_z_ext): Added zbs. gas/ * config/tc-riscv.c (riscv_multi_subset_supports): Handle INSN_CLASS_ZBS. * testsuite/gas/riscv/b-ext.d: Test Zbs instructions. * testsuite/gas/riscv/b-ext.s: Likewise. * testsuite/gas/riscv/b-ext-64.d: Likewise. * testsuite/gas/riscv/b-ext-64.s: Likewise. include/ * opcode/riscv-opc.h: Added MASK/MATCH/DECLARE_INSN for Zbs. * opcode/riscv.h (riscv_insn_class): Added INSN_CLASS_ZBS. opcodes/ * riscv-opc.c (riscv_supported_std_z_ext): Add zbs. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>	5 years ago
Philipp Tomsich	586dcfc81e	RISC-V: Update extension version for Zb[abc] to 1.0.0 2021-10-06 Philipp Tomsich <philipp.tomsich@vrull.eu> bfd/ * elfxx-riscv.c (riscv_supported_std_z_ext): Update the version number for zba, zbb and zbc to 1.0.0 Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu> Version-changes: 3 - Updated version numbers for zba, zbb and zbc to 1.0.0	5 years ago
Philipp Tomsich	cda0561f9e	RISC-V: Split Zb[abc] into commented sections The Zb[abc] opcodes are bundled just below the Privileged opcodes in riscv_opcodes, possibly giving the appearance that they are part of the Privileged spec for an uninitiated reader. This separates them out and adds comments above each section to clearly identify them as Zba, Zbb or Zbc opcodes. 2021-10-04 Philipp Tomsich <philipp.tomsich@vrull.eu> opcodes/ * riscv-opc.c: Split of Zb[abc] instructions and add comments. Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>	5 years ago
Alan Modra	6646834337	PR28423, use-after-free in objdump XCOFF archives use a bi-directional linked list for file members. So one member points to both the previous member and the next member. Members may not be sequentially ordered in the file. This of course is over-engineered nonsense and an attractive target for fuzzers. (There is even a free list of members!) The testcase in PR28423 is an XCOFF archive with one member pointing to itself, which results in lots of bad behaviour. For example, "ar t" never terminates. The use-after-free with "objdump -r" happens like this: The first archive element is opened, its symbols are read and "canonicalized" for objdump, then relocations are read and printed. Those relocations use the canonicalized symbols, and also happen to be cached by the coff bfd backend support. objdump frees the symbols. The next archive element is then opened. This must be done before the first element is closed, because finding the next element uses data held in the currect element. Unfortunately the next element happens to be the original, so we aren't opening, we're reopening a bfd which has cached data. When the relocations are printed they use the cached copy containing references to the freed canonical symbols. This patch adds a little sanity checking to the XCOFF "open next archive file" support, so that it rejects archive members pointing at themselves. That is sufficient to cure this problem. Anything more is overkill. If someone deliberately fuzzes an XCOFF archive with an element loop then reports an "ar" bug when it runs forever, they will find their bug report closed WONTFIX. PR 28423 * coff-rs6000.c (_bfd_xcoff_read_ar_hdr): Save size occupied by member name in areltdata.extra_size. (_bfd_xcoff_openr_next_archived_file): Sanity check nextoff. * coff64-rs6000.c (xcoff64_openr_next_archived_file): Call _bfd_xcoff_openr_next_archived_file.	5 years ago
Alan Modra	6d661cdc5b	PR28422, build_id use-after-free This fixes a bug in commit `5d9bbb73c1`. All fields preserved from a bfd in struct bfd_preserve need to be cleared in bfd_reinit. PR 28422 * format.c (bfd_reinit): Clear build_id.	5 years ago
Alan Modra	89e62f7454	Change ridiculous section size error Rather than reporting "memory exhausted", report "file truncated". You can hit this error on small fuzzed object files, or on files that are actually truncated. In either case sizes can be such that an out of memory error is a little confusing. * compress.c (bfd_get_full_section_contents): Set bfd_error_file_truncated rather than bfd_error_no_memory when section size exceeds file size.	5 years ago
Tom de Vries	c0ae8ccdba	[gdb/testsuite] Fix FAIL in gdb.base/annota1.exp On openSUSE tumbleweed I run into: ... FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout) ... due to a message related to libthread_db: ... ^Z^Zstarting^M [Thread debugging using libthread_db enabled]^M Using host libthread_db library "/lib64/libthread_db.so.1".^M ^M ^Z^Zframes-invalid^M ... which is not matched by the regexp. Fix this by updating the regexp. Tested on x86_64-linux.	5 years ago
Tom de Vries	cf4505a7ec	[gdb/testsuite] Refactor regexp in gdb.base/annota1.exp Refactor regexp in gdb.base/annota1.exp to reduce indentation and repetition. Tested on x86_64-linux.	5 years ago
GDB Administrator	82f2f39d81	Automatic date update in version.in	5 years ago
Andrew Burgess	24616c1995	gdb/doc: improve 'show print elements' description The documentation for 'show print elements' contains the line: If the number is 0, then the printing is unlimited. However, this line is now out of date as can be seen by this GDB session: (gdb) set print elements 0 (gdb) show print elements Limit on string chars or array elements to print is unlimited. The value 0 does indeed mean unlimited, and this is described in the 'set print elements' section, however, for 'show print elements' the user will never see the value 0, so lets just remove that bit from the docs.	5 years ago
Tom de Vries	cf2ad3e662	[gdb/testsuite] Fix FAIL in gdb.tui/corefile-run.exp When running test-case gdb.tui/corefile-run.exp on openSUSE Tumbleweed, I run into: ... PASS: gdb.tui/corefile-run.exp: load corefile FAIL: gdb.tui/corefile-run.exp: run until the end ... What's going on is easier to see when also doing dump_screen if check_contents passes, and inspecting state at the preceding PASS: ... +-------------------------------------------------------------------------+ exec No process In: L?? PC: ?? [New LWP 16629] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/data/gdb_versions/devel/build/gdb/testsuite/output s/gdb.tui/corefile-run/corefi'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 main () --Type <RET> for more, q to quit, c to continue without paging-- ... The problem is that we're getting a pagination prompt, and the subsequent run command is interpreted as an answer to that prompt. Fix this by: - detecting the gdb prompt in response to "load corefile", such that we detect the failure earlier, and - doing a "set pagination off" in Term::clean_restart. Tested on x86_64-linux.	5 years ago
Alan Modra	1992e26ec4	PR28420, ecoff fuzzing failures PR 28420 * coff-mips.c (mips_adjust_reloc_in): Replace abort with error message and return. * ecoff.c (ecoff_slurp_reloc_table): Remove assertion and aborts, instead handle errors gracefully.	5 years ago

1 2 3 4 5 ...

107714 Commits (76b43c9b5c2b275cbf4f927bfc25984410cb5dd5) All Branches Search

107714 Commits (76b43c9b5c2b275cbf4f927bfc25984410cb5dd5)

All Branches