aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-01-25Automatic date update in version.inGDB Administrator1-1/+1
2020-01-24gdb: Better frame tracking for inline framesAndrew Burgess6-15/+579
This commit improves GDB's handling of inline functions when there are more than one inline function in a stack, so for example if we have a stack like: main -> aaa -> bbb -> ccc -> ddd And aaa, bbb, and ccc are all inline within main GDB should (when given sufficient debug information) be able to step from main through aaa, bbb, and ccc. Unfortunately, this currently doesn't work, here's an example session: (gdb) start Temporary breakpoint 1 at 0x4003b0: file test.c, line 38. Starting program: /project/gdb/tests/inline/test Temporary breakpoint 1, main () at test.c:38 38 global_var = 0; (gdb) step 39 return aaa () + 1; (gdb) step aaa () at test.c:39 39 return aaa () + 1; (gdb) step bbb () at test.c:39 39 return aaa () + 1; (gdb) step ccc () at test.c:39 39 return aaa () + 1; (gdb) step ddd () at test.c:32 32 return global_var; (gdb) bt #0 ddd () at test.c:32 #1 0x00000000004003c1 in ccc () at test.c:39 #2 bbb () at test.c:26 #3 aaa () at test.c:14 #4 main () at test.c:39 Notice that once we get to line 39 in main, GDB keeps reporting line 39 in main as the location despite understanding that the inferior is stepping through the nested inline functions with each use of step. The problem is that as soon as the inferior stops we call skip_inline_frames (from inline-frame.c) which calculates the inferiors current state in relation to inline functions - it figures out if we're in an inline function, and if we are counts how many inline frames there are at the current location. So, in our example above, when we step from line 38 in main to line 39 we stop at a location that is simultaneously in all of main, aaa, bbb, and ccc. The block structure reflects the order in which the functions would be called, with ccc being the most inner block and main being the most outer block. When we stop GDB naturally finds the block for ccc, however within skip_inline_frames we spot that bbb, aaa, and main are super-blocks of the current location and that each layer represents an inline function. The skip_inline_frames then records the depth of inline functions (3 in this case for aaa, bbb, and ccc) and also the symbol of the outermost inline function (in this case 'aaa' as main isn't an inline function, it just has things inline within it). Now GDB understands the stack to be main -> aaa -> bbb -> ccc, however, the state initialised in skip_inline_frames starts off indicating that we should hide 3 frames from the user, so we report that we're in main at line 39. The location of main, line 39 is derived by asking the inline function state for the last symbol in the stack (aaa in this case), and then asking for it's location - the location of an inlined function symbol is its call site, so main, line 39 in this case. If the user then asks GDB to step we don't actually move the inferior at all, instead we spot that we are in an inline function stack, lookup the inline state data, and reduce the skip depth by 1. We then report to the user that GDB has stopped. GDB now understands that we are in 'aaa'. In order to get the precise location we again ask GDB for the last symbol from the inline data structure, and we are again told 'aaa', we then get the location from 'aaa', and report that we are in main, line 39. Hopefully it's clear what the mistake here is, once we've reduced the inline skip depth we should not be using 'aaa' to compute the precise location, instead we should be using 'bbb'. That is what this patch does. Now, when we call skip_inline_frames instead of just recording the last skipped symbol we now record all symbols in the inline frame stack. When we ask GDB for the last skipped symbol we return a symbol based on how many frames we are skipping, not just the last know symbol. With this fix in place, the same session as above now looks much better: (gdb) start Temporary breakpoint 1 at 0x4003b0: file test.c, line 38. Starting program: /project/gdb/tests/inline/test Temporary breakpoint 1, main () at test.c:38 38 global_var = 0; (gdb) s 39 return aaa () + 1; (gdb) s aaa () at test.c:14 14 return bbb () + 1; (gdb) s bbb () at test.c:26 26 return ccc () + 1; (gdb) s ccc () at test.c:20 20 return ddd () + 1; (gdb) s ddd () at test.c:32 32 return global_var; (gdb) bt #0 ddd () at test.c:32 #1 0x00000000004003c1 in ccc () at test.c:20 #2 bbb () at test.c:26 #3 aaa () at test.c:14 #4 main () at test.c:39 gdb/ChangeLog: * frame.c (find_frame_sal): Move call to get_next_frame into more inner scope. * inline-frame.c (inilne_state) <inline_state>: Update argument types. (inilne_state) <skipped_symbol>: Rename to... (inilne_state) <skipped_symbols>: ...this, and change to a vector. (skip_inline_frames): Build vector of skipped symbols and use this to reate the inline_state. (inline_skipped_symbol): Add a comment and some assertions, fetch skipped symbol from the list. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-many-frames.c: New file. * gdb.dwarf2/dw2-inline-many-frames.exp: New file. Change-Id: I99def5ffb44eb9e58cda4b449bf3d91ab0386c62
2020-01-24gdb: Don't reorder line table entries too much when sorting.Andrew Burgess6-25/+227
Don't reorder line table entries for the same address when sorting the line table, maintain the compiler given line order. Usually this will reflect the order in which lines are conceptually encountered at a given address. Consider this example: /* 1 */ volatile int global_var; /* 2 */ int __attribute__ ((noinline)) /* 3 */ bar () /* 4 */ { /* 5 */ return global_var; /* 6 */ } /* 7 */ static inline int __attribute__ ((always_inline)) /* 8 */ foo () /* 9 */ { /* 10 */ return bar (); /* 11 */ } /* 12 */ int /* 13 */ main () /* 14 */ { /* 15 */ global_var = 0; /* 16 */ return foo (); /* 17 */ } GCC 10 currently generates a line table like this (as shown by objdump): CU: ./test.c: File name Line number Starting address test.c 4 0x4004b0 test.c 5 0x4004b0 test.c 6 0x4004b6 test.c 6 0x4004b7 test.c 14 0x4003b0 test.c 15 0x4003b0 test.c 16 0x4003ba test.c 10 0x4003ba test.c 10 0x4003c1 The interesting entries are those for lines 16 and 10 at address 0x4003ba, these represent the call to foo and the inlined body of foo. With the current line table sorting GDB builds the line table like this (as shown by 'maintenance info line-table'): INDEX LINE ADDRESS 0 14 0x00000000004003b0 1 15 0x00000000004003b0 2 10 0x00000000004003ba 3 16 0x00000000004003ba 4 END 0x00000000004003c1 5 4 0x00000000004004b0 6 5 0x00000000004004b0 7 END 0x00000000004004b7 Notice that entries 2 and 3 for lines 10 and 16 are now in a different order to the line table as given by the compiler. With this patch applied the order is now: INDEX LINE ADDRESS 0 14 0x00000000004003b0 1 15 0x00000000004003b0 2 16 0x00000000004003ba 3 10 0x00000000004003ba 4 END 0x00000000004003c1 5 4 0x00000000004004b0 6 5 0x00000000004004b0 7 END 0x00000000004004b7 Notice that entries 2 and 3 are now in their original order again. The consequence of the incorrect ordering is that when stepping through inlined functions GDB will display the wrong line for the inner most frame. Here's a GDB session before this patch is applied: Starting program: /home/andrew/tmp/inline/test Temporary breakpoint 1, main () at test.c:15 15 /* 15 */ global_var = 0; (gdb) step 16 /* 16 */ return foo (); (gdb) step foo () at test.c:16 16 /* 16 */ return foo (); (gdb) step bar () at test.c:5 5 /* 5 */ return global_var; The step from line 15 to 16 was fine, but the next step should have taken us to line 10, instead we are left at line 16. The final step to line 5 is as expected. With this patch applied the session goes better: Starting program: /home/andrew/tmp/inline/test Temporary breakpoint 1, main () at test.c:15 15 /* 15 */ global_var = 0; (gdb) step 16 /* 16 */ return foo (); (gdb) step foo () at test.c:10 10 /* 10 */ return bar (); (gdb) step bar () at test.c:5 5 /* 5 */ return global_var; We now visit the lines as 15, 16, 10, 5 as we would like. The reason for this issue is that the inline frame unwinder is detecting that foo is inlined in main. When we stop at the shared address 0x4003ba the inline frame unwinder first shows us the outer frame, this information is extracted from the DWARF's DW_TAG_inlined_subroutine entries and passed via GDB's block data. When we step again the inlined frame unwinder moves us up the call stack to the inner most frame at which point the frame is displayed as normal, with the location for the address being looked up in the line table. As GDB uses the last line table entry for an address as "the" line to report for that address it is critical that GDB maintain the order of the line table entries. In the first case, by reordering the line table we report the wrong location. I had to make a small adjustment in find_pc_sect_line in order to correctly find the previous line in the line table. In some line tables I was seeing an actual line entry and an end of sequence marker at the same address, before this commit these would reorder to move the end of sequence marker before the line entry (end of sequence has line number 0). Now the end of sequence marker remains in its correct location, and in order to find a previous line we should step backward over any end of sequence markers. As an example, the binary: gdb/testsuite/outputs/gdb.dwarf2/dw2-ranges-func/dw2-ranges-func-lo-cold Has this line table before the patch: INDEX LINE ADDRESS 0 48 0x0000000000400487 1 END 0x000000000040048e 2 52 0x000000000040048e 3 54 0x0000000000400492 4 56 0x0000000000400497 5 END 0x000000000040049a 6 62 0x000000000040049a 7 END 0x00000000004004a1 8 66 0x00000000004004a1 9 68 0x00000000004004a5 10 70 0x00000000004004aa 11 72 0x00000000004004b9 12 END 0x00000000004004bc 13 76 0x00000000004004bc 14 78 0x00000000004004c0 15 80 0x00000000004004c5 16 END 0x00000000004004cc And after this patch: INDEX LINE ADDRESS 0 48 0x0000000000400487 1 52 0x000000000040048e 2 END 0x000000000040048e 3 54 0x0000000000400492 4 56 0x0000000000400497 5 END 0x000000000040049a 6 62 0x000000000040049a 7 66 0x00000000004004a1 8 END 0x00000000004004a1 9 68 0x00000000004004a5 10 70 0x00000000004004aa 11 72 0x00000000004004b9 12 END 0x00000000004004bc 13 76 0x00000000004004bc 14 78 0x00000000004004c0 15 80 0x00000000004004c5 16 END 0x00000000004004cc When calling find_pc_sect_line with the address 0x000000000040048e, in both cases we find entry #3, we then try to find the previous entry, which originally found this entry '2 52 0x000000000040048e', after the patch it finds '2 END 0x000000000040048e', which cases the lookup to fail. By skipping the END marker after this patch we get back to the correct entry, which is now #1: '1 52 0x000000000040048e', and everything works again. gdb/ChangeLog: * buildsym.c (lte_is_less_than): Delete. (buildsym_compunit::end_symtab_with_blockvector): Create local lambda function to sort line table entries, and use std::stable_sort instead of std::sort. * symtab.c (find_pc_sect_line): Skip backward over end of sequence markers when looking for a previous line. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-inline-stepping.c: New file. * gdb.dwarf2/dw2-inline-stepping.exp: New file. Change-Id: Ia0309494be4cfd9dcc554f30209477f5f040b21b
2020-01-24gdb: Include end of sequence markers in the line tableAndrew Burgess6-11/+61
In this commit: commit d9b3de22f33e400f7f409cce3acf6c7dab07dd79 Date: Wed May 27 14:44:29 2015 -0700 Add struct to record dwarf line number state machine. I believe an unintended change was made to how we store the DWARF line table, the end of sequence markers between sequences of lines were lost from the line table. This commit fixes this small oversight and restores the end of sequence markers. Given that we've survived this long without noticing is clearly an indication that this isn't that serious, however, a later patch that I am developing would benefit from having the markers in place, so I'd like to restore them. Having the markers also means that the output of 'maintenance info line-table' now more closely reflects the DWARF line table. I've taken this opportunity to improve how 'maintenance info line-table' displays the end of sequence markers - it now uses the END keyword, rather than just printing an entry with line number 0. So we see this: INDEX LINE ADDRESS 0 12 0x00000000004003b0 1 17 0x00000000004003b0 2 18 0x00000000004003b0 3 END 0x00000000004003b7 4 5 0x00000000004004a0 5 6 0x00000000004004a0 6 END 0x00000000004004a7 Instead of what we would have seen, which was this: INDEX LINE ADDRESS 0 12 0x00000000004003b0 1 17 0x00000000004003b0 2 18 0x00000000004003b0 3 0 0x00000000004003b7 4 5 0x00000000004004a0 5 6 0x00000000004004a0 6 0 0x00000000004004a7 I've added a small test that uses 'maintenance info line-table' to ensure that we don't regress this again. gdb/ChangeLog: * dwarf2read.c (lnp_state_machine::record_line): Include end_sequence parameter in debug print out. Record the line if we are at an end_sequence marker even if it's not the start of a statement. * symmisc.c (maintenance_print_one_line_table): Print end of sequence markers with 'END' not '0'. gdb/testsuite/ChangeLog: * gdb.base/maint.exp: Update line table parsing test. * gdb.dwarf2/dw2-ranges-base.exp: Add new line table parsing test. Change-Id: I002f872248db82a1d4fefdc6b51ff5dbf932d8a8
2020-01-24RISC-V: Minor cleanup for s extension support.Jim Wilson2-5/+9
Looking at older versions of the patch, I confirmed that the odd comment I referred to earlier was indeed from the removal of the sx support. It also explains an oddly formatted switch statement. This patch fixes both minor problems. bfd/ * elfxx-riscv.c (riscv_get_prefix_class): Format s case like others. (riscv_parse_prefixed_ext): Fix s extension comment and reword to avoid over long line. Change-Id: I1cb62e4a16188270f029b6376e4b1684000d6c7a
2020-01-24Fix re-runs of a second inferior (PR gdb/25410)Pedro Alves8-18/+265
This fixes a latent bug exposed by the multi-target patch (5b6d1e4fa "Multi-target support), and then fixes two other latent bugs exposed by fixing that first latent bug. The symptom described in the bug report is that starting a first inferior, then trying to run a second (multi-threaded) inferior twice, causes libthread_db to fail to load, along with other erratic behavior: (gdb) run Starting program: /tmp/foo warning: td_ta_new failed: generic error Going a bit deeply, I found that if the two inferiors have different symbols, we can see that just after inferior 2 exits, we are left with inferior 2 selected, which is correct, but the symbols in scope belong to inferior 1, which is obviously incorrect... This problem is that there's a path in scoped_restore_current_thread::restore() that switches to no thread selected, and switches the current inferior, but leaves the current program space as is, resulting in leaving the program space pointing to the wrong program space (the one of the other inferior). This was happening after handling TARGET_WAITKIND_NO_RESUMED, which is an event that triggers after TARGET_WAITKIND_EXITED for the previous inferior exit. Subsequent symbol lookups find the symbols of the wrong inferior. The fix is to use switch_to_inferior_no_thread in that problem spot. This function was recently added along with the multi-target work exactly for these situations. As for testing, this patch adds a new testcase that tests symbol printing just after inferior exit, which exercises the root cause of the problem more directly. And then, to cover the use case described in the bug too, it also exercises the lithread_db.so mis-loading, by using TLS printing as a proxy for being sure that threaded debugging was activated sucessfully. The testcase fails without the fix like this, for the "print symbol just after exit" bits: ... [Inferior 1 (process 8719) exited normally] (gdb) PASS: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: continue until exit print re_run_var_1 No symbol "re_run_var_1" in current context. (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=1: print re_run_var_1 ... And like this for the "libthread_db.so loading" bits: (gdb) run Starting program: /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run warning: td_ta_new failed: generic error [New LWP 27001] Thread 1.1 "multi-re-run" hit Breakpoint 3, all_started () at /home/pedro/gdb/binutils-gdb/build/../src/gdb/testsuite/gdb.multi/multi-re-run.c:44 44 } (gdb) PASS: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=2: running to all_started in runto print tls_var Cannot find thread-local storage for LWP 27000, executable file /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.multi/multi-re-run/multi-re-run: Cannot find thread-local variables on this target (gdb) FAIL: gdb.multi/multi-re-run.exp: re_run_inf=1: iter=2: print tls_var As mentioned, that fix above goes on to expose a couple other latent bugs. This commit fixes those as well. The first latent bug exposed is in infrun.c:handle_vfork_child_exec_or_exit. The current code is leaving inf->pspace == NULL while calling clone_program_space. The idea was to make it so that the breakpoints module doesn't use this inferior's pspace to set breakpoints. With that, any scoped_restore_current_thread use from within clone_program_space tries to restore a NULL program space, which hits an assertion: Attaching after Thread 0x7ffff74b8700 (LWP 27276) vfork to child process 27277] [New inferior 2 (process 27277)] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". /home/pedro/gdb/binutils-gdb/build/../src/gdb/progspace.c:243: internal-error: void set_current_program_space(program_space*): Assertion `pspace != NULL' faile d. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.threads/vfork-follow-child-exit.exp: detach-on-fork=off: continue (GDB internal error) That NULL pspace idea was legitimate, but it's no longer necessary, since commit b2e586e850db ("Defer breakpoint reset when cloning progspace for fork child"). So the fix is to just set the inferior's program space earlier. The other latent bug exposed is in exec.c. When exec_close is called from the program_space destructor, it is purposedly called with a current program space that is not the current inferior's program space. The problem is that the multi-target work added some code to remove_target_sections that loops over all inferiors, and uses scoped_restore_current_thread to save/restore the previous thread/inferior/frame state. This makes it so that exec_close returns with the current program space set to the current inferior's program space, which is exactly what we did not want. Then the program_space destructor continues into free_all_objfiles, but it is now running that method on the wrong program space, resulting in: Reading symbols from /home/pedro/gdb/binutils-gdb/build/gdb/testsuite/outputs/gdb.threads/fork-plus-threads/fork-plus-threads... Reading symbols from /usr/lib/debug/usr/lib64/libpthread-2.26.so.debug... Reading symbols from /usr/lib/debug/usr/lib64/libm-2.26.so.debug... Reading symbols from /usr/lib/debug/usr/lib64/libc-2.26.so.debug... Reading symbols from /usr/lib/debug/usr/lib64/ld-2.26.so.debug... [Inferior 3 (process 9583) exited normally] /home/pedro/gdb/binutils-gdb/build/../src/gdb/progspace.c:170: internal-error: void program_space::free_all_objfiles(): Assertion `so->objfile == NULL' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.threads/fork-plus-threads.exp: detach-on-fork=off: inferior 1 exited (GDB internal error) The fix is to use scoped_restore_current_pspace_and_thread instead of scoped_restore_current_thread. gdb/ChangeLog: 2020-01-24 Pedro Alves <palves@redhat.com> PR gdb/25410 * thread.c (scoped_restore_current_thread::restore): Use switch_to_inferior_no_thread. * exec.c: Include "progspace-and-thread.h". (add_target_sections, remove_target_sections): scoped_restore_current_pspace_and_thread instead of scoped_restore_current_thread. * infrun.c (handle_vfork_child_exec_or_exit): Assign the pspace and aspace to the inferior before calling clone_program_space. Remove stale comment. gdb/testsuite/ChangeLog: 2020-01-24 Pedro Alves <palves@redhat.com> PR gdb/25410 * gdb.multi/multi-re-run-1.c: New. * gdb.multi/multi-re-run-2.c: New. * gdb.multi/multi-re-run.exp: New.
2020-01-24Add install-strip target to gdbserverHannes Domani5-1/+236
So far this was only possible indirectly when invoked from the gdb directory. This makes the install-strip target independent from gdb. 2020-01-24 Hannes Domani <ssbssa@yahoo.de> * Makefile.in (install-strip): New target. (install_sh, INSTALL_STRIP_PROGRAM, STRIP): New variables. * aclocal.m4: Regenerate. * configure: Regenerate. * configure.ac: Add AM_PROG_INSTALL_STRIP.
2020-01-24Make the class name in the definition match the declarationChristian Biesinger2-2/+9
Fixes a compile error because the class is actually called arm_netbsd_nat_target. gdb/ChangeLog: 2020-01-24 Christian Biesinger <cbiesinger@google.com> * arm-nbsd-nat.c (arm_nbsd_nat_target::fetch_registers): Rename to... (arm_netbsd_nat_target::fetch_registers): ...this. (arm_nbsd_nat_target::store_registers): Rename to... (arm_netbsd_nat_target::store_registers): ...this. Change-Id: Ibebfab9edeff48f54c32d0745afda1d74d31de92
2020-01-24Define _KERNTYPES in arm-nbsd-nat.cChristian Biesinger2-0/+7
Fixes the below compile error on ARM NetBSD 9.0_RC1 (the only version I tested). types.h does not define register_t by default. We already use this define elsewhere, notably in bsd-kvm.c. In file included from ../../gdb/arm-nbsd-nat.c:28: /usr/include/machine/frame.h:54:2: error: unknown type name 'register_t'; did you mean '__register_t'? register_t tf_spsr; ^ /usr/include/machine/types.h:77:14: note: '__register_t' declared here typedef int __register_t; ^ There are other compile errors that this does not fix. gdb/ChangeLog: 2020-01-24 Christian Biesinger <cbiesinger@google.com> * arm-nbsd-nat.c: Define _KERNTYPES to get the declaration of register_t. Change-Id: I82c21d38189ee59ea0af2538ba84b771d268722e
2020-01-24Support the NetBSD version of pthread_setname_npChristian Biesinger2-2/+15
On NetBSD, pthread_setname_np takes a printf-style format string plus one argument: https://netbsd.gw.com/cgi-bin/man-cgi?pthread_setname_np++NetBSD-current This patch makes thread-pool.c handle that. gdbsupport/ChangeLog: 2020-01-24 Christian Biesinger <cbiesinger@google.com> * thread-pool.c (set_thread_name): Add an overload for the NetBSD version of pthread_setname_np. Change-Id: I61e664a813eaa7f52b6811b1a43e08ac3082d8ef
2020-01-24Fix an illegal call to free() when copying a PE format file.Nick Clifton2-2/+11
PR 25447 * coffgen.c (_bfd_coff_close_and_cleanup): Do not clear the keep syms and keep strings flags as these may have been set in order to prevent a bogus call to free.
2020-01-24gdbserver: Make `make TAGS' actually workMaciej W. Rozycki5-38/+65
Fix a: make: *** No rule to make target '.../gdb/gdbserver/arch/arm.c', needed by 'TAGS'. Stop. error produced by `make TAGS' by making the list of sources processed match actual file locations and by moving host-specific object files listed in DEPFILES to nat/ or target/ subdirectories as appropriate so that the location of the corresponding source file can be mechanically determined. gdb/gdbserver/ * Makefile.in (SFILES): Adjust paths to point to real files. (OBS): Move waitstatus.o to target/waitstatus.o. (TAGS): Transform paths appropriately. (%.o): Rename to... (nat/%.o): ... this pattern rule. (%.o): Rename to... (target/%.o): ... this pattern rule. * configure.srv: Adjust paths throughout to include nat/ prefix with the revant files. * configure.ac: Add `nat' and `target' to CONFIG_SRC_SUBDIR. * configure: Regenerate.
2020-01-24gdbserver: Remove a stale TAGS recipe for config filesMaciej W. Rozycki2-3/+5
Complement commit 7ea814144a31 ("Fully disentangle gdb and gdbserver"), <https://sourceware.org/ml/gdb-patches/2002-02/msg00692.html> (from 2002!), and remove a recipe to include config files in `make TAGS', which are no longer used by `gdbserver' as from that commit. gdb/gdbserver/ * Makefile.in (TAGS): Remove config files from the recipe.
2020-01-24Fix issue with warning messages about corrupt debuginfod notes.Nick Clifton2-2/+7
* readelf.c (get_build_id): Fix warning messages about corrupt notes.
2020-01-24Update comments about removed functionChristian Biesinger6-6/+17
regset_from_core_section doesn't exist anymore; it has been replaced by the iterate_over_regset_sections gdbarch method. Update comments accordingly to not confuse readers. gdb/ChangeLog: 2020-01-24 Christian Biesinger <cbiesinger@google.com> * aarch64-fbsd-tdep.c (aarch64_fbsd_iterate_over_regset_sections): Update comment. * aarch64-linux-tdep.c (aarch64_linux_iterate_over_regset_sections): Likewise. * arm-fbsd-tdep.c (arm_fbsd_iterate_over_regset_sections): Likewise. * gdbcore.h (deprecated_add_core_fns): Update comment to point to the correct replacement (iterate_over_regset_sections). * riscv-fbsd-tdep.c (riscv_fbsd_iterate_over_regset_sections): Update comment. Change-Id: I5eea4d18e15edae5d6dfd5d0d6241e5b2ae40daa
2020-01-24gdb: Enable stdin on exception in execute_gdb_commandAndrew Burgess4-0/+105
This is an update of this patch: https://sourceware.org/ml/gdb-patches/2018-09/msg00884.html This patch attempts to address PR gdb/23718 by re-enabling stdin whenever an exception is caught during gdb.execute(). When Python gdb.execute() is called, an exception could occur (e.g. the target disappearing), which is then converted into a Python exception. If stdin was disabled before the exception is caught, it is not re-enabled, because the exception doesn't propagate to the top level of the event loop, whose catch block would otherwise enable it. The result is that when execution of a Python script completes, GDB does not prompt or accept input, and is effectively hung. This change rectifies the issue by re-enabling stdin in the catch block of execute_gdb_command, prior to converting the exception to a Python exception. Since this patch was originally posted I've added a test, and also I converted the code to re-enable stdin from this: SWITCH_THRU_ALL_UIS () { async_enable_stdin (); } to simply this: async_enable_stdin (); My reasoning is that we only need the SWITCH_THRU_ALL_UIS if, at the time the exception is caught, the current_ui might be different than at the time we called async_disable_stdin. Within python's execute_gdb_command I think it should be impossible to switch current_ui, so the SWITCH_THRU_ALL_UIS isn't needed. gdb/ChangeLog: PR gdb/23718 * gdb/python/python.c (execute_gdb_command): Call async_enable_stdin in catch block. gdb/testsuite/ChangeLog: PR gdb/23718 * gdb.server/server-kill-python.exp: New file. Change-Id: I1cfc36ee9f8484cc1ed82be9be338353db6bc080
2020-01-24gdb: Re-enable stdin for all UIs from start_event_loopAndrew Burgess5-1/+153
If we catch an exception in start_event_loop's call to gdb_do_one_event, then it is possible that the current_ui has changed since we called async_disable_stdin. If that's the case then calling async_enable_stdin will be called on the wrong UI. To solve this problem we wrap the call to async_enable_stdin with SWITCH_THRU_ALL_UIS, this causes us to try and re-enable stdin for all UIs, which will catch any for which we called async_disable_stdin. gdb/ChangeLog: * event-loop.c (start_event_loop): Wrap async_enable_stdin with SWITCH_THRU_ALL_UIS. gdb/testsuite/ChangeLog: * gdb.server/multi-ui-errors.c: New file. * gdb.server/multi-ui-errors.exp: New file. Change-Id: I1e18deff2e6f4e17f7a13adce3553eb001cad93b
2020-01-24gdb/tui: asm window handles invalid memory and scrolls betterAndrew Burgess6-78/+288
This started as a patch to enable the asm window to handle attempts to disassemble invalid memory, but it ended up expanding into a significant rewrite of how the asm window handles scrolling. These two things ended up being tied together as it was impossible to correctly test scrolling into invalid memory when the asm window would randomly behave weirdly while scrolling. Things that should work nicely now; scrolling to the bottom or top of the listing with PageUp, PageDown, Up Arrow, Down Arrow and we should be able to scroll past small areas of memory that don't have symbols associated with them. It should also be possible to scroll to the start of a section even if there's no symbol at the start of the section. Adding tests for this scrolling was a little bit of a problem. First I would have liked to add tests for PageUp / PageDown, but the tuiterm library we use doesn't support these commands right now due to only emulating a basic ascii terminal. Changing this to emulate a more complex terminal would require adding support for more escape sequence control codes, so I've not tried to tackle that in this patch. Next, I would have liked to test scrolling to the start or end of the assembler listing and then trying to scroll even more, however, this is a problem because in a well behaving GDB a scroll at the start/end has no effect. What we need to do is: - Move to start of assembler listing, - Send scroll up command, - Wait for all curses output, - Ensure the assembler listing is unchanged, we're still at the start of the listing. The problem is that there is no curses output, so how long do we wait at step 3? The same problem exists for scrolling to the bottom of the assembler listing. However, when scrolling down you can at least see the end coming, so I added a test for this case, however, this feels like an area of code that is massively under tested. gdb/ChangeLog: PR tui/9765 * minsyms.c (lookup_minimal_symbol_by_pc_section): Update header comment, add extra parameter, and update to store previous symbol when appropriate. * minsyms.h (lookup_minimal_symbol_by_pc_section): Update comment, add extra parameter. * tui/tui-disasm.c (tui_disassemble): Update header comment, remove unneeded parameter, add try/catch around gdb_print_insn, rewrite to add items to asm_lines vector. (tui_find_backward_disassembly_start_address): New function. (tui_find_disassembly_address): Updated throughout. (tui_disasm_window::set_contents): Update for changes to tui_disassemble. (tui_disasm_window::do_scroll_vertical): No need to adjust the number of lines to scroll. gdb/testsuite/ChangeLog: PR tui/9765 * gdb.tui/tui-layout-asm.exp: Add scrolling test for asm window. Change-Id: I323987c8fd316962c937e73c17d952ccd3cfa66c
2020-01-24gdb/tui: Prevent exceptions from trying to cross readlinePedro Alves1-3/+28
This is triggered by simply scrolling off the end of the dissasembly window. This commit doesn't fix the actual exception that is being thrown, which will still need to be fixed, but makes sure that we don't ever throw an exception out to readline. gdb/ChangeLog: yyyy-mm-dd Pedro Alves <palves@redhat.com> PR tui/9765 * tui/tui-io.c (tui_getc): Rename to ... (tui_getc_1): ... this. (tui_get): New, reimplent as try/catch wrapper around tui_getc_1. Change-Id: I2e32a401ab34404b2132ec82a3e1c17b9b723e41
2020-01-24Automatic date update in version.inGDB Administrator1-1/+1
2020-01-23gdb: introduce objfile text_section_offset and data_section_offset methodsSimon Marchi17-82/+135
The pattern objfile->section_offsets[SECT_OFF_TEXT (objfile)] ... appears very often, to get the offset of the text section of an objfile. I thought it would be more readable to write it as: objfile->text_section_offset () ... so I added this method and used it where possible. I also added data_section_offset, although it is not used as much. gdb/ChangeLog: * objfiles.h (ALL_OBJFILE_OSECTIONS): Move up. (SECT_OFF_DATA): Likewise. (SECT_OFF_RODATA): Likewise. (SECT_OFF_TEXT): Likewise. (SECT_OFF_BSS): Likewise. (struct objfile) <text_section_offset, data_section_offset>: New methods. * amd64-windows-tdep.c (amd64_windows_find_unwind_info): Use objfile::text_section_offset. * coff-pe-read.c (add_pe_forwarded_sym): Likewise. * coffread.c (coff_symtab_read): Likewise. (enter_linenos): Likewise. (process_coff_symbol): Likewise. * ctfread.c (get_objfile_text_range): Likewise. * dtrace-probe.c (dtrace_probe::get_relocated_address): Use objfile::data_section_offset. * dwarf2-frame.c (execute_cfa_program): Use objfile::text_section_offset. (dwarf2_frame_find_fde): Likewise. * dwarf2read.c (create_addrmap_from_index): Likewise. (create_addrmap_from_aranges): Likewise. (dw2_find_pc_sect_compunit_symtab): Likewise. (process_psymtab_comp_unit_reader): Likewise. (add_partial_symbol): Likewise. (add_partial_subprogram): Likewise. (process_full_comp_unit): Likewise. (read_file_scope): Likewise. (read_func_scope): Likewise. (read_lexical_block_scope): Likewise. (read_call_site_scope): Likewise. (dwarf2_rnglists_process): Likewise. (dwarf2_ranges_process): Likewise. (dwarf2_ranges_read): Likewise. (dwarf_decode_lines_1): Likewise. (new_symbol): Likewise. (dwarf2_fetch_die_loc_sect_off): Likewise. (dwarf2_per_cu_text_offset): Likewise. * hppa-bsd-tdep.c (hppabsd_find_global_pointer): Likewise. * hppa-tdep.c (read_unwind_info): Likewise. * ia64-tdep.c (ia64_find_unwind_table): Likewise. * psympriv.h (struct partial_symtab): Likewise. * psymtab.c (find_pc_sect_psymtab): Likewise. * solib-svr4.c (enable_break): Likewise. * stap-probe.c (relocate_address): Use objfile::data_section_offset. * xcoffread.c (enter_line_range): Use objfile::text_section_offset. (read_xcoff_symtab): Likewise.
2020-01-23gdb: fix variable shadowing error in darwin-nat.cSimon Marchi2-2/+8
We encounter this error when building on macOS with GCC. CXX darwin-nat.o /src-local/binutils-gdb/gdb/darwin-nat.c: In member function 'ptid_t darwin_nat_target::wait_1(ptid_t, target_waitstatus*)': /src-local/binutils-gdb/gdb/darwin-nat.c:1264:18: error: declaration of 'inf' shadows a previous local [-Werror=shadow=compatible-local] for (inferior *inf : all_inferiors (this)) ^~~ /src-local/binutils-gdb/gdb/darwin-nat.c:1205:20: note: shadowed declaration is here struct inferior *inf; ^~~ Fix it by moving the declaration of `inf` in the specific scopes that need it. I think it's clearer this way anyway, as it shows that it's not the same `inf` that is used in these different scopes. Thanks to Iain Sandoe for reporting this. I did not see this error at first, because I compile with the default system compiler on macOS, which is clang. The compiler flag we try to enable for this is `-Wshadow=local`, which is not one recognized by clang. I checked to see if there would a version of the -Wshadow* warnings [1] we could enable for clang, that would catch this, but the only one that would is `-Wshadow` itself, and this is too invasive for us (which is why we enabled just -Wshadow=local in the first place). [1] https://clang.llvm.org/docs/DiagnosticsReference.html#wshadow gdb/ChangeLog: * darwin-nat.c (darwin_nat_target::wait_1): Move `inf` declaration to narrower scopes.
2020-01-23gdb: fix darwin-nat.c build / adapt to multi-targetSimon Marchi5-109/+160
The darwin-nat.c file doesn't build since the multi-target changes (5b6d1e4f, "Multi-target support"). This patch makes it build. I have access to a macOS vm, so I am able to build it, but I wasn't able to successfully codesign it and try to actually debug something, so I don't know if it works. I don't have much more time to put on this to figure it out, so I thought I'd sent the patch anyway, as it's at least a step in the right direction. The bulk of the patch is to change a bunch of functions to be methods of the darwin_nat_target object, so that this can pass `this` to find_inferior_ptid and other functions that now require a process_stratum_target pointer. The darwin_ptrace_him function (renamed to darwin_nat_target::ptrace_him in this patch) is passed to fork_inferior as the `init_trace_fun` parameter. Since the method can't be passed as a plain function pointer (we need the `this` pointer), I changed the `init_trace_fun` parameter of fork_inferior to be a gdb::function_view, so we can pass a lambda and capture `this`. The changes in darwin-nat.h are only to move definition higher in the file, so that forward declarations are not needed. gdb/ChangeLog: * darwin-nat.h (struct darwin_exception_msg, enum darwin_msg_state, struct darwin_thread_info, darwin_thread_t): Move up. (class darwin_nat_target) <wait_1, check_new_threads, decode_exception_message, decode_message, stop_inferior, init_thread_list, ptrace_him, cancel_breakpoint>: Declare. * darwin-nat.c (darwin_check_new_threads): Rename to... (darwin_nat_target::check_new_threads): ... this. (darwin_suspend_inferior_it): Remove. (darwin_decode_exception_message): Rename to... (darwin_nat_target::decode_exception_message): ... this. (darwin_nat_target::resume): Pass target to find_inferior_ptid. (darwin_decode_message): Rename to... (darwin_nat_target::decode_message): ... this. (cancel_breakpoint): Rename to... (darwin_nat_target::cancel_breakpoint): ... this. (darwin_wait): Rename to... (darwin_nat_target::wait_1): ... this. Use range-based for loop instead of iterate_over_inferiors. (darwin_nat_target::wait): Call wait_1 instead of darwin_wait. (darwin_stop_inferior): Rename to... (darwin_nat_target::stop_inferior): ... this. (darwin_nat_target::kill): Call wait_1 instead of darwin_wait. (darwin_init_thread_list): Rename to... (darwin_nat_target::init_thread_list): ... this. (darwin_ptrace_him): Rename to... (darwin_nat_target::ptrace_him): ... this. (darwin_nat_target::create_inferior): Pass lambda function to fork_inferior. (darwin_nat_target::detach): Call stop_inferior instead of darwin_stop_inferior. * fork-inferior.h (fork_inferior): Change init_trace_fun parameter to gdb::function_view. * fork-inferior.c (fork_inferior): Likewise.
2020-01-23Cache the text section offset of shared librariesHannes Domani5-7/+27
Each time a dll is loaded, update_solib_list is called. This in turn calls deep down xfer_partial -> windows_xfer_shared_libraries, which calls windows_xfer_shared_library for each loaded dll, and pe_text_section_offset reads the dll for the text section offset. Also if the data provided by xfer_partial is bigger than 4K, then all of this is done for each 4K chunk (see target_read_alloc_1). Caching of the text section offset improves the startup time of an application with >300 dynamically loaded plugins from 2m10s to 10s. And the shutdown time improves from 2m to 2s. gdb/ChangeLog: 2020-01-23 Hannes Domani <ssbssa@yahoo.de> * i386-cygwin-tdep.c (core_process_module_section): Update. * windows-nat.c (struct lm_info_windows): Add text_offset. (windows_xfer_shared_libraries): Update. * windows-tdep.c (windows_xfer_shared_library): Add text_offset_cached argument. * windows-tdep.h (windows_xfer_shared_library): Update.
2020-01-23Updated translations for various binutils sub-directories.Nick Clifton7-3702/+4293
2020-01-23PR25444, Floating point exception in _bfd_elf_compute_section_file_positionsAlan Modra2-5/+17
PR 25444 * elf.c (assign_file_positions_for_load_sections): Avoid divide by zero when p_align is zero.
2020-01-22RISC-V: Change -march parsing.Jim Wilson12-105/+324
bfd/ 2020-01-22 Maxim Blinov <maxim.blinov@embecosm.com> * bfd/elfnn-riscv.c (riscv_skip_prefix): New. (riscv_prefix_cmp): Likewise. (riscv_non_std_ext_p): Deleted. (riscv_std_sv_ext_p): Likewise. (riscv_non_std_sv_ext_p): Likewise. (riscv_merge_non_std_and_sv_ext): Rename to... (riscv_merge_multi_letter_ext): and modified to use riscv_prefix_cmp. (riscv_merge_arch_attr_info): Replace 3 calls to riscv_merge_non_std_and_sv_ext with single call to riscv_merge_multi_letter_ext. * bfd/elfxx-riscv.c (riscv_parse_std_ext): Break if we encounter a 'z' prefix. (riscv_get_prefix_class): New function, return prefix class based on first few characters of input string. (riscv_parse_config): New structure to factor out minor differences in extension class parsing behaviour. (riscv_parse_sv_or_non_std_ext): Rename to... (riscv_parse_prefixed_ext): and parameterise with riscv_parse_config. (riscv_std_z_ext_strtab, riscv_std_s_ext_strtab): New. (riscv_multi_letter_ext_valid_p): New. (riscv_ext_x_valid_p, riscv_ext_z_valid_p, riscv_ext_s_valid_p): New. (riscv_parse_subset): Delegate all non-single-letter parsing work to riscv_parse_prefixed_ext. * bfd/elfxx-riscv.h (riscv_isa_ext_class): New type. (riscv_get_prefix_class): Declare. gas/ 2020-01-22 Maxim Blinov <maxim.blinov@embecosm.com> * testsuite/gas/riscv/march-ok-s.d: sx is no longer valid and s exts must be known, so rename *ok* to *fail*. * testsuite/gas/riscv/march-ok-sx.d: Likewise. * testsuite/gas/riscv/march-ok-s-with-version: Likewise. * testsuite/gas/riscv/march-fail-s.l: Expected error messages for above change. * testsuite/gas/riscv/march-fail-sx.l: Likewise. * testsuite/gas/riscv/march-fail-sx-with-version.l: Likewise. Change-Id: Ic4d91a13d055a10d30ab28752a380a669b59f29c
2020-01-23Automatic date update in version.inGDB Administrator1-1/+1
2020-01-22MSP430: Fix simulator execution of RRUX instructionJozef Lawrynowicz4-2/+27
The MSP430X RRUX instruction (unsigned right shift) is synthesized as the RRC (rotate right through carry) instruction, but with the ZC (zero carry) bit of the opcode extention word set. Ensure the carry flag is ignored when the ZC bit is set. sim/msp430/ChangeLog: 2020-01-22 Jozef Lawrynowicz <jozef.l@mittosystems.com> * msp430-sim.c (msp430_step_once): Ignore the carry flag when executing an RRC instruction, if the ZC bit of the extension word is set. sim/testsuite/sim/msp430/ChangeLog: 2020-01-22 Jozef Lawrynowicz <jozef.l@mittosystems.com> * rrux.s: New test.
2020-01-22x86: Always disallow double word suffix with word general registerH.J. Lu6-30/+35
In 64-bit mode, double word suffix in mnemonic with word general register is disallowed. Otherwise, assembler gives a warning: $ cat /tmp/x.s movl %ax, %bx movl %ds, %ax movl %ax, %cs $ gcc -c /tmp/x.s /tmp/x.s: Assembler messages: /tmp/x.s:1: Error: incorrect register `%bx' used with `l' suffix /tmp/x.s:2: Error: incorrect register `%ax' used with `l' suffix /tmp/x.s:3: Error: incorrect register `%ax' used with `l' suffix $ gcc -c /tmp/x.s -m32 /tmp/x.s: Assembler messages: /tmp/x.s: Assembler messages: /tmp/x.s:1: Warning: using `%ebx' instead of `%bx' due to `l' suffix /tmp/x.s:1: Warning: using `%eax' instead of `%ax' due to `l' suffix /tmp/x.s:2: Warning: using `%eax' instead of `%ax' due to `l' suffix /tmp/x.s:3: Warning: using `%eax' instead of `%ax' due to `l' suffix This patch makes it a hard error in all modes. Now we get: $ gcc -c /tmp/x.s -m32 /tmp/x.s: Assembler messages: /tmp/x.s:1: Error: incorrect register `%bx' used with `l' suffix /tmp/x.s:2: Error: incorrect register `%ax' used with `l' suffix /tmp/x.s:3: Error: incorrect register `%ax' used with `l' suffix PR gas/25438 * config/tc-i386.c (check_long_reg): Always disallow double word suffix in mnemonic with word general register. * testsuite/gas/i386/general.s: Replace word general register with double word general register for movl. * testsuite/gas/i386/inval.s: Add tests for movl with word general register. * testsuite/gas/i386/general.l: Updated. * testsuite/gas/i386/inval.l: Likewise.
2020-01-22x86-64: Skip GNU2 TLS tests only without compiler supportH.J. Lu2-2/+8
After fixing: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93319 https://sourceware.org/bugzilla/show_bug.cgi?id=25416 -mtls-dialect=gnu2 is working for x32 with GCC 10. Skip GNU2 TLS tests only if compiler doesn't support it. PR ld/25416 * testsuite/ld-x86-64/tls.exp: Skip GNU2 TLS tests only without compiler support.
2020-01-22PowerPC64 tls_get_addr_desc static supportAlan Modra9-1/+357
This provides a linker generated __tls_get_addr_desc wrapper function preserving registers around a __tls_get_addr call. The idea being to support __tls_get_addr_desc without requiring a glibc update. bfd/ * elf64-ppc.c (struct ppc_link_hash_table): Add tga_group. (ppc64_elf_archive_symbol_lookup): Extract __tls_get_addr_opt for __tls_get_addr_desc. (ppc64_elf_size_stubs): Add section for linker generated __tls_get_addr_desc wrapper function. Loop at least once if generating this function. (emit_tga_desc, emit_tga_desc_eh_frame): New functions. (ppc64_elf_build_stubs): Generate __tls_get_addr_desc. ld/ * testsuite/ld-powerpc/tlsdesc3.d, * testsuite/ld-powerpc/tlsdesc3.wf, * testsuite/ld-powerpc/tlsdesc4.d, * testsuite/ld-powerpc/tlsdesc4.s, * testsuite/ld-powerpc/tlsdesc4.wf: New tests. * testsuite/ld-powerpc/powerpc.exp: Run them.
2020-01-22PowerPC64 __tls_get_addr_descAlan Modra23-98/+1572
This implements register saving and restoring in the __tls_get_addr call stub, so that when glibc supports the optimized tls call stub gcc can generate code that assumes only r0, r12 and of course r3 are changed on a __tls_get_addr call. When gcc expects __tls_get_addr calls to preserve registers the call will be to __tls_get_addr_desc, which will be translated by the linker to a call to __tls_get_addr_opt. bfd/ * elf64-ppc.h (struct ppc64_elf_params): Add no_tls_get_addr_regsave. * elf64-ppc.c (struct ppc_link_hash_table): Add tga_desc and tga_desc_fd. (is_tls_get_addr): Match tga_desc and tga_desc_df too. (STDU_R1_0R1, ADDI_R1_R1): Define. (tls_get_addr_prologue, tls_get_addr_epilogue): New functions. (ppc64_elf_tls_setup): Set up tga_desc and tga_desc_fd. Indirect tga_desc_fd to opt_fd, and tga_desc to opt. Set no_tls_get_addr_regsave. (branch_reloc_hash_match): Add hash3 and hash4. (ppc64_elf_tls_optimize): Handle tga_desc_fd and tga_desc too. (ppc64_elf_size_dynamic_sections): Likewise. (ppc64_elf_relocate_section): Likewise. (plt_stub_size, build_plt_stub): Likewise. Size regsave __tls_get_addr stub. (build_tls_get_addr_stub): Build regsave __tls_get_addr stub and eh_frame. (ppc_size_one_stub): Handle tga_desc_fd and tga_desc too. Size eh_frame for regsave __tls_get_addr. gas/ * config/tc-ppc.c (parse_tls_arg): Handle tls arg for __tls_get_addr_desc and __tls_get_addr_opt. ld/ * emultempl/ppc64elf.em (ppc64_opt, PARSE_AND_LIST_LONGOPTS), (PARSE_AND_LIST_OPTIONS, PARSE_AND_LIST_ARGS_CASES): Support --tls-get-addr-regsave and --no-tls-get-addr-regsave. (params): Init new field. * ld.texi (--tls-get-addr-regsave, --no-tls-get-addr-regsave): Document. * testsuite/ld-powerpc/tlsdesc.s, * testsuite/ld-powerpc/tlsdesc.d, * testsuite/ld-powerpc/tlsdesc.wf, * testsuite/ld-powerpc/tlsdesc2.d, * testsuite/ld-powerpc/tlsdesc2.wf, * testsuite/ld-powerpc/tlsexenors.d, * testsuite/ld-powerpc/tlsexenors.r, * testsuite/ld-powerpc/tlsexers.d, * testsuite/ld-powerpc/tlsexers.r, * testsuite/ld-powerpc/tlsexetocnors.d, * testsuite/ld-powerpc/tlsexetocrs.d, * testsuite/ld-powerpc/tlsexetocrs.r, * testsuite/ld-powerpc/tlsopt6.d, * testsuite/ld-powerpc/tlsopt6.wf: New. * testsuite/ld-powerpc/powerpc.exp: Run new tests.
2020-01-22PowerPC64 TLS optimization fixAlan Modra2-1/+7
When linking with --no-tls-optimize the linker doesn't generate a call or long branch stub to __tls_get_addr in some circumstances, giving: relocation truncated to fit: R_PPC64_REL24 against symbol `__tls_get_addr' * elf64-ppc.c (ppc64_elf_size_stubs): Correct condition under which __tls_get_addr calls will be eliminated.
2020-01-22PR25417, Fix minor typosYuri Chornoivan5-3/+14
PR 25417 binutils/ * readelf.c (get_alpha_symbol_other): Fix error message typo. ld/ * ldlang.c (ldlang_open_ctf): Fix error message typo. * emultempl/z80elf.em (z80_elf_after_open): Likewise.
2020-01-21pr23900-1.d: AdjustedH.J. Lu2-1/+5
Linux program headers may look like Section to Segment mapping: Segment Sections... 00 .note.gnu.property .text 01 .note.gnu.property 02 .note.gnu.property or Section to Segment mapping: Segment Sections... 00 .note.gnu.property 01 .text 02 .note.gnu.property 03 .note.gnu.property Update pr23900-1.d to accept both. * testsuite/ld-elf/pr23900-1.d: Adjusted.
2020-01-22Automatic date update in version.inGDB Administrator1-1/+1
2020-01-21gdb: add declaration for _initialize_gdbarch in gdbarch.shSimon Marchi2-1/+6
In commit gdb: add back declarations for _initialize functions 6c2659886f7018fcca26ee0fc813bc9748fb8513 I wrongfully edited gdbarch.c, instead of editing gdbarch.sh and re-generating gdbarch.c. This patch fixes gdbarch.sh to add a declaration for _initialize_gdbarch. gdbarch.c is not changed, as the output of gdbarch.sh now matches the current state of gdbarch.c. gdb/ChangeLog: * gdbarch.sh: Add declaration for _initialize_gdbarch.
2020-01-21gdb: remove uses of iterate_over_inferiors in remote-sim.cSimon Marchi2-50/+38
This removes the two uses of iterate_over_inferiors, in favor of range-based loops. gdb/ChangeLog: * remote-sim.c (check_for_duplicate_sim_descriptor): Remove. (get_sim_inferior_data): Remove use of iterate_over_inferiors, replace with range-based for. (gdbsim_interrupt_inferior): Remove. (gdbsim_target::interrupt): Replace iterate_over_inferiors use with a range-based for. Inline code from gdbsim_interrupt_inferior.
2020-01-21gdb: fix indentation in infrun.cSimon Marchi2-37/+41
I noticed the indentation there was off, this patch fixes it. gdb/ChangeLog: * infrun.c (proceed): Fix indentation.
2020-01-21Allow use of Pygments to colorize source codeTom Tromey8-4/+150
While GNU Source Highlight is good, it's also difficult to build and distribute. For one thing, it needs Boost. For another, it has an unusual configuration and installation setup. Pygments, a Python library, doesn't suffer from these issues, and so I thought it would be a reasonable fallback. This patch implements this idea. GNU Source Highlight is preferred, but if it is unavailable (or fails), the extension languages are tried. This patch also implements support for Pygments. Something similar could be done for Guile, using: https://dthompson.us/projects/guile-syntax-highlight.html However, I don't know enough about Guile internals to make this happen, so I have not done it here. gdb/ChangeLog 2020-01-21 Tom Tromey <tromey@adacore.com> * source-cache.c (source_cache::ensure): Call ext_lang_colorize. * python/python.c (python_extension_ops): Update. (gdbpy_colorize): New function. * python/lib/gdb/__init__.py (colorize): New function. * extension.h (ext_lang_colorize): Declare. * extension.c (ext_lang_colorize): New function. * extension-priv.h (struct extension_language_ops) <colorize>: New member. * cli/cli-style.c (_initialize_cli_style): Update help text. Change-Id: I5e21623ee05f1f66baaa6deaeca78b578c031bf4
2020-01-21pr23900-1.d: Also check PT_GNU_PROPERTY program headerH.J. Lu2-1/+13
Also pass -l to readelf to check PT_GNU_PROPERTY program header. PR ld/23900 * testsuite/ld-elf/pr23900-1.d: Also pass -l to readelf.
2020-01-21x86: testsuite adjustments after commit 1a0351246a5cJan Beulich5-0/+15
The odd behavior of certain COFF/PE targets makes necessary some mechanical adjustments.
2020-01-21Convert an int flag variable to boolLuis Machado2-4/+12
As suggested, the cond variable is really supposed to be a bool. So, make it so. gdb/ChangeLog: 2020-01-21 Luis Machado <luis.machado@linaro.org> * aarch64-tdep.c (struct aarch64_displaced_step_closure) <cond>: Change type to bool. (aarch64_displaced_step_b_cond): Update cond to use bool type. (aarch64_displaced_step_cb): Likewise. (aarch64_displaced_step_tb): Likewise.
2020-01-21Add more debugging output to aarch64_displaced_step_fixupLuis Machado2-2/+30
While debugging the step-over-syscall problem, i wanted to see a bit more debugging output to try to determine the root cause. This patch does this. gdb/ChangeLog: 2020-01-21 Luis Machado <luis.machado@linaro.org> * aarch64-tdep.c (aarch64_displaced_step_fixup): Add more debugging output.
2020-01-21Fix step-over-syscall.exp failureLuis Machado2-4/+20
In particular, this one: FAIL: gdb.base/step-over-syscall.exp: fork: displaced=on: check_pc_after_cross_syscall: single step over fork final pc When ptrace fork event reporting is enabled, GDB gets a PTRACE_EVENT_FORK event whenever the inferior executes the fork syscall. Then the logic is that GDB needs to step the inferior yet again in order to receive a predetermined SIGTRAP, but no execution takes place because the signal was already queued for delivery. That means the PC should stay the same. I noticed the aarch64 code is currently adjusting the PC in this situation, making the inferior skip an instruction without executing it. The following change checks if we did not execute the instruction (pc - to == 0), making proper adjustments for such case. Regression tested on aarch64-linux-gnu on the tryserver. gdb/ChangeLog: 2020-01-21 Luis Machado <luis.machado@linaro.org> * aarch64-tdep.c (struct aarch64_displaced_step_closure ) <pc_adjust>: Adjust the documentation. (aarch64_displaced_step_fixup): Check if PC really moved before adjusting it.
2020-01-21x86: replace adhoc ambiguous operand checking for CRC32Jan Beulich13-50/+60
There's no need (anymore?) to heavily special case this - just make generic logic consider only its first operand, and deal with the case of an 'l' suffix not being allowed in a pattern.
2020-01-21x86: improve handling of insns with ambiguous operand sizesJan Beulich49-130/+1075
Commit b76bc5d54e ("x86: don't default variable shift count insns to 8-bit operand size") pointed out a very bad case, but the underlying problem is, as mentioned on various occasions, much larger: Silently selecting a (nowhere documented afaict) certain default operand size when there's no "sizing" suffix and no suitable register operand(s) is simply dangerous (for the programmer to make mistakes). While in Intel syntax mode such mistakes already lead to an error (which is going to remain that way), AT&T syntax mode now gains warnings in such cases by default, which can be suppressed or promoted to an error if so desired by the programmer. Furthermore at least general purpose insns now consistently have a default applied (alongside the warning emission), rather than accepting some and refusing others. No warnings are (as before) to be generated for "DefaultSize" insns as well as ones acting on selector and other fixed-width values. For SYSRET, however, the DefaultSize needs to be dropped - it had been wrongly put there in the first place, as it's unrelated to .code16gcc (no stack accesses involved). As set forth as a prereq when I first mentioned this intended change a few years back, Linux as well as gcc have meanwhile been patched to avoid (emission of) ambiguous operands (and hence triggering of the new warning). Note that I think that in 64-bit mode IRET and far RET would better get a diagnostic too, as it's reasonably likely that a suffix-less instance really is meant to be a 64-bit one. But I guess I better make this a separate follow-on patch. Note further that floating point operations with integer operands are an exception for now: They continue to use short (16-bit) operands by default even in 32- and 64-bit modes. Finally note that while {,V}PCMPESTR{I,M} would, strictly speaking, also need to be diagnosed, with their 64-bit forms not being very useful I think it is better to continue to avoid warning about them (by way of them carrying IgnoreSize attributes).
2020-01-21x86: VCVTNEPS2BF16{X,Y} should permit broadcastingJan Beulich8-8/+40
Just like other VCVT*{X,Y} templates do, and to allow the programmer flexibility (might be relevant in particular when heavily macro-izing code), the two templates should also have Broadcast set, just like their X/Y-suffix-less counterparts. This in turn requires them to also have * Dword set on their memory operands, to cover the logic added to i386gen by 4a1b91eabbe7 ("x86: Expand Broadcast to 3 bits"), * RegXMM/RegYMM set on their source operands, to satisfy broadcast sizing logic in gas itself. Otherwise ATTSyntax templates wouldn't need such operand size attributes. While extending the test cases, also add Intel syntax broadcast forms without explicit size specifiers.
2020-01-21Automatic date update in version.inGDB Administrator1-1/+1