aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2018-04-26Fix setting breakpoints on ifunc functions after they're already resolvedPedro Alves5-21/+56
This fixes setting breakpoints on ifunc functions by name after the ifunc has already been resolved. In that case, if you have debug info for the ifunc resolver, without the fix, then gdb puts a breakpoint past the prologue of the resolver, instead of setting a breakpoint at the ifunc target: break gnu_ifunc Breakpoint 4 at 0x7ffff7bd36f2: file src/gdb/testsuite/gdb.base/gnu-ifunc-lib.c, line 34. (gdb) continue Continuing. [Inferior 1 (process 13300) exited normally] (gdb) above we should have stopped at "final", but didn't because we never resolved the ifunc to the final location. If you don't have debug info for the resolver, GDB manages to resolve the ifunc target, but, it should be setting a breakpoint after the prologue of the final function, and instead what you get is that GDB sets a breakpoint on the first address of the target function. With the gnu-ifunc.exp tests added by a later patch, we get, without the fix: (gdb) break gnu_ifunc Breakpoint 4 at 0x400753 (gdb) continue Continuing. Breakpoint 4, final (arg=1) at src/gdb/testsuite/gdb.base/gnu-ifunc-final.c:20 20 { vs, fixed: (gdb) break gnu_ifunc Breakpoint 4 at 0x40075a: file src/gdb/testsuite/gdb.base/gnu-ifunc-final.c, line 21. (gdb) continue Continuing. Breakpoint 4, final (arg=2) at src/gdb/testsuite/gdb.base/gnu-ifunc-final.c:21 21 return arg + 1; (gdb) Fix the problems above by moving the ifunc target resolving to linespec.c, before we skip a function's prologue. We need to save something in the sal, so that set_breakpoint_location_function knows that it needs to create a bp_gnu_ifunc_resolver bp_location. Might as well just save a pointer to the minsym. gdb/ChangeLog: 2018-04-26 Pedro Alves <palves@redhat.com> * breakpoint.c (set_breakpoint_location_function): Don't resolve ifunc targets here. Instead, if we have an ifunc minsym, use its address/name. (add_location_to_breakpoint): Store the minsym and the objfile in the breakpoint location. * breakpoint.h (bp_location) <msymbol, objfile>: New fields. * linespec.c (minsym_found): Resolve GNU ifunc targets here. Record the minsym in the sal. * symtab.h (symtab_and_line) <msymbol>: New field.
2018-04-26Fix elf_gnu_ifunc_resolve_by_got bugletPedro Alves2-3/+10
The next patch will add a call to elf_gnu_ifunc_resolve_by_got that trips on a latent buglet -- the function is writing to its output parameter even if the address wasn't found, confusing the caller. The function's intro comment says: /* Try to find the target resolved function entry address of a STT_GNU_IFUNC function NAME. If the address is found it is stored to *ADDR_P (if ADDR_P is not NULL) and the function returns 1. It returns 0 otherwise. So fix the function accordingly. gdb/ChangeLog: 2018-04-26 Pedro Alves <palves@redhat.com> * elfread.c (elf_gnu_ifunc_resolve_by_got): Don't write to *ADDR_P unless we actually resolved the ifunc.
2018-04-26Calling ifunc functions when resolver has debug info, user symbol same namePedro Alves7-8/+70
If the GNU ifunc resolver has the same name as the user visible symbol, and the resolver has debug info, then the DWARF info for the resolver masks the ifunc minsym. In that scenario, if you try calling the ifunc from GDB, you call the resolver instead. With the gnu-ifunc.exp testcase added in a following patch, you'd see: (gdb) p gnu_ifunc (3) $1 = (int (*)(int)) 0x400753 <final> (gdb) FAIL: gdb.base/gnu-ifunc.exp: resolver_attr=0: resolver_debug=1: resolved_debug=0: p gnu_ifunc (3) ^^^^^^^^^^^^^^^^ That is, we called the ifunc resolver manually, which returned a pointer to the ifunc target function ("final"). The "final" symbol is the function that GDB should have called automatically, ~~~~~~~~~~~~ int final (int arg) { return arg + 1; } ~~~~~~~~~ which is what happens if you don't have debug info for the resolver: (gdb) p gnu_ifunc (3) $1 = 4 (gdb) PASS: gdb.base/gnu-ifunc.exp: resolver_attr=0: resolver_debug=0: resolved_debug=1: p gnu_ifunc (3) ^^^^^^^^^^^^^^^^ or if the resolver's symbol has a different name from the ifunc (as is the case with modern uses of ifunc via __attribute__ ifunc, such as glibc uses): (gdb) p gnu_ifunc (3) $1 = 4 (gdb) PASS: gdb.base/gnu-ifunc.exp: resolver_attr=1: resolver_debug=1: resolved_debug=0: p gnu_ifunc (3) ^^^^^^^^^^^^^^^ in which case after this patch, you can still call the resolver directly if you want: (gdb) p gnu_ifunc_resolver (3) $1 = (int (*)(int)) 0x400753 <final> gdb/ChangeLog: 2018-04-26 Pedro Alves <palves@redhat.com> * c-exp.y (variable production): Prefer ifunc minsyms over regular function symbols. * symtab.c (find_gnu_ifunc): New function. * minsyms.h (lookup_msym_prefer): New enum. (lookup_minimal_symbol_by_pc_section): Replace 'want_trampoline' parameter by a lookup_msym_prefer parameter. * symtab.h (find_gnu_ifunc): New declaration.
2018-04-26Calling ifunc functions when target has no debug info but resolver hasPedro Alves9-51/+140
After the previous patch, on Fedora 27 (glibc 2.26), if you try calling strlen in the inferior, you now get: (top-gdb) p strlen ("hello") '__strlen_avx2' has unknown return type; cast the call to its declared return type This is correct, because __strlen_avx2 is written in assembly. We can improve on this though -- if the final ifunc resolved/target function has no debug info, but the ifunc _resolver_ does have debug info, we can try extracting the final function's type from the type that the resolver returns. E.g.,: typedef size_t (*strlen_t) (const char*); size_t my_strlen (const char *) { /* some implementation */ } strlen_t strlen_resolver (unsigned long hwcap) { return my_strlen; } extern size_t strlen (const char *s); __typeof (strlen) strlen __attribute__ ((ifunc ("strlen_resolver"))); In the strlen example above, the resolver returns strlen_t, which is a typedef for pointer to a function that returns size_t. "strlen_t" is the type of both the user-visible "strlen", and of the the target function that implements it. This patch teaches GDB to extract that type. This is done for actual inferior function calls (in infcall.c), and for ptype (in eval_call). By the time we get to either of these places, we've already lost the original symbol/minsym, and only have values and types to work with. Hence the changes to c-exp.y and evaluate_var_msym_value, to ensure that we propagate the ifunc minsymbol's info. The change to make ifunc symbols have no/unknown return type exposes a latent problem -- gdb.compile/compile-ifunc.exp calls a no-debug-info function, but we did not warn about it. The test is fixed by this commit too. gdb/ChangeLog: 2018-04-26 Pedro Alves <palves@redhat.com> * blockframe.c (find_gnu_ifunc_target_type): New function. (find_function_type): New. * eval.c (evaluate_var_msym_value): For GNU ifunc types, always return a value with a memory address. (eval_call): For calls to GNU ifunc functions, try to find the type of the target function from the type that the resolver returns. * gdbtypes.c (objfile_type): Don't install a return type for ifunc symbols. * infcall.c (find_function_return_type): Delete. (find_function_addr): Add 'function_type' parameter. For calls to GNU ifunc functions, try to find the type of the target function from the type that the resolver returns, and return it via FUNCTION_TYPE. (call_function_by_hand_dummy): Adjust to use the function type returned by find_function_addr. (find_function_addr): Add 'function_type' parameter and move description here. * symtab.h (find_function_type, find_gnu_ifunc_target_type): New declarations. gdb/testsuite/ChangeLog: 2018-04-26 Pedro Alves <palves@redhat.com> * gdb.compile/compile-ifunc.exp: Also expect "function has unknown return type" warnings.
2018-04-26Fix calling ifunc functions when resolver has debug info and different namePedro Alves2-1/+8
Currently, on Fedora 27 (glibc 2.26), if you try to call strlen in the inferior you get: (gdb) p strlen ("hello") $1 = (size_t (*)(const char *)) 0x7ffff554aac0 <__strlen_avx2> strlen is an ifunc function, and what we see above is the result of calling the ifunc resolver in the inferior. That returns a pointer to the actual target function that implements strlen on my machine. GDB should have turned around and called the resolver automatically without the user noticing. This is was caused by commit: commit bf223d3e808e6fec9ee165d3d48beb74837796de Date: Mon Aug 21 11:34:32 2017 +0100 Handle function aliases better (PR gdb/19487, errno printing) which added the find_function_alias_target call to c-exp.y, to try to find an alias with debug info for a minsym. For ifunc symbols, that finds the ifunc's resolver if it has debug info (in the example it's called "strlen_ifunc"), with the result that GDB calls that as a regular function. After this commit, we get now get: (top-gdb) p strlen ("hello") '__strlen_avx2' has unknown return type; cast the call to its declared return type Which is correct, because __strlen_avx2 is written in assembly. That'll be improved in a following patch, though. gdb/ChangeLog: 2018-04-26 Pedro Alves <palves@redhat.com> * c-exp.y (variable production): Skip finding an alias for ifunc symbols.
2018-04-26Fix breakpoints in ifunc after inferior resolved it (@got.plt symbol creation)Pedro Alves2-17/+44
Setting a breakpoint on an ifunc symbol after the ifunc has already been resolved by the inferior should result in creating a breakpoint location at the ifunc target. However, that's not what happens on current Fedora: (gdb) n 53 i = gnu_ifunc (1); /* break-at-call */ (gdb) 54 assert (i == 2); (gdb) b gnu_ifunc Breakpoint 2 at gnu-indirect-function resolver at 0x7ffff7bd36ee (gdb) info breakpoints Num Type Disp Enb Address What 2 STT_GNU_IFUNC resolver keep y 0x00007ffff7bd36ee <gnu_ifunc+4> The problem is that elf_gnu_ifunc_resolve_by_got never manages to resolve an ifunc target. The reason is that GDB never actually creates the internal got.plt symbols: (gdb) p 'gnu_ifunc@got.plt' No symbol "gnu_ifunc@got.plt" in current context. and this is because GDB expects that rela.plt has relocations for .plt, while it actually has relocations for .got.plt: Relocation section [10] '.rela.plt' for section [22] '.got.plt' at offset 0x570 contains 2 entries: Offset Type Value Addend Name 0x0000000000601018 X86_64_JUMP_SLOT 000000000000000000 +0 __assert_fail 0x0000000000601020 X86_64_JUMP_SLOT 000000000000000000 +0 gnu_ifunc Using an older system on the GCC compile farm (machine gcc15, an x86-64 running Debian 6.0.8, with GNU ld 2.20.1), we see that it used to be that we'd get a .rela.plt section for .plt: Relocation section [ 9] '.rela.plt' for section [11] '.plt' at offset 0x578 contains 3 entries: Offset Type Value Addend Name 0x0000000000600cc0 X86_64_JUMP_SLOT 000000000000000000 +0 __assert_fail 0x0000000000600cc8 X86_64_JUMP_SLOT 000000000000000000 +0 __libc_start_main 0x0000000000600cd0 X86_64_JUMP_SLOT 000000000000000000 +0 gnu_ifunc Those offsets did point into .got.plt, as seen with objdump -h: 20 .got.plt 00000030 0000000000600ca8 0000000000600ca8 00000ca8 2**3 CONTENTS, ALLOC, LOAD, DATA I also tested on gcc110 on the compile farm (PPC64 running CentOS 7.4.1708, with GNU ld 2.25.1), and there we see instead: Relocation section [ 9] '.rela.plt' for section [23] '.plt' at offset 0x5d0 contains 4 entries: Offset Type Value Addend Name 0x0000000010020148 PPC64_JMP_SLOT 000000000000000000 +0 __libc_start_main 0x0000000010020160 PPC64_JMP_SLOT 000000000000000000 +0 __gmon_start__ 0x0000000010020178 PPC64_JMP_SLOT 000000000000000000 +0 __assert_fail 0x0000000010020190 PPC64_JMP_SLOT 000000000000000000 +0 gnu_ifunc But note that those offsets point into .plt, not .got.plt, as seen with objdump -h: 22 .plt 00000078 0000000010020130 0000000010020130 00010130 2**3 ALLOC This commit makes us support all the different combinations above. With that addressed, we now get: (gdb) p 'gnu_ifunc@got.plt' $1 = (<text from jump slot in .got.plt, no debug info>) 0x400753 <final> And setting a breakpoint on the ifunc finds the ifunc target: (gdb) b gnu_ifunc Breakpoint 2 at 0x400753 (gdb) info breakpoints Num Type Disp Enb Address What 2 breakpoint keep y 0x0000000000400753 <final> gdb/ChangeLog: 2018-04-26 Pedro Alves <palves@redhat.com> * elfread.c (elf_rel_plt_read): Look for relocations for .got.plt too.
2018-04-25Fix new inferior events outputPedro Alves7-6/+26
Since f67c0c917150 ("Enable 'set print inferior-events' and improve detach/fork/kill/exit messages"), when detaching a remote process, we get, for detach against a remote target: (gdb) detach Detaching from program: ...., process 5388 Ending remote debugging. [Inferior 1 (Thread 5388.5388) detached] ^^^^^^^^^^^^^^^^ That is incorrect, for it is printing a thread id as string while we should be printing the process id instead. I.e., either one of: [Inferior 1 (process 5388) detached] [Inferior 1 (Remote target) detached] depending on remote stub support for the multi-process extensions. Similarly, after killing a process, we're printing thread ids while we should be printing process ids. E.g., on native GNU/Linux: (gdb) k Kill the program being debugged? (y or n) y [Inferior 1 (Thread 0x7ffff7faa8c0 (LWP 30721)) has been killed] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ while it should have been: Kill the program being debugged? (y or n) y [Inferior 1 (process 30721) has been killed] ^^^^^^^^^^^^^ There's a wording inconsistency between detach and kill: [Inferior 1 (process 30721) has been killed] [Inferior 1 (process 30721) detached] Given we were already saying "detached" instead of "has been detached", and we used to say just "exited", and given that the "has been" doesn't really add any information, this commit changes the message to just "killed": [Inferior 1 (process 30721) killed] gdb/ChangeLog: 2018-04-25 Pedro Alves <palves@redhat.com> * infcmd.c (kill_command): Print the pid as string, not the whole thread's ptid. Add comment. s/has been killed/killed/ in output message. * remote.c (remote_detach_1): Print the pid as string, not the whole thread's ptid. gdb/testsuite/ChangeLog: 2018-04-25 Pedro Alves <palves@redhat.com> * gdb.base/hook-stop.exp: Expect "killed" instead of "has been killed". * gdb.base/kill-after-signal.exp: Likewise. * gdb.threads/kill.exp: Likewise.
2018-04-24Enable 'set print inferior-events' and improve detach/fork/kill/exit messagesSergio Durigan Junior20-62/+266
This patch aims to turn 'set print inferior-events' always on, and do some cleanup on the messages printed by GDB when various inferior events happen (attach, detach, fork, kill, exit). To make sure that the patch is correct, I've tested it with a handful of combinations of 'set follow-fork-mode', 'set detach-on-fork' and 'set print inferior-events'. In the end, I decided to make my hand-made test into an official testcase. More on that below. Using the following program as an example: #include <unistd.h> int main () { fork (); return 0; } We see the following outputs from the patched GDB: - With 'set print inferior-events on': (gdb) r Starting program: a.out [Detaching after fork from child process 27749] [Inferior 1 (process 27745) exited normally] (gdb) - With 'set print inferior-events off': (gdb) r Starting program: a.out [Inferior 1 (process 27823) exited normally] (gdb) Comparing this against an unpatched GDB: - With 'set print inferior-events off' and 'set follow-fork-mode child': (gdb) r Starting program: a.out [Inferior 2 (process 5993) exited normally] (gdb) Compare this against an unpatched GDB: (unpatched-gdb) r Starting program: a.out [New process 5702] [Inferior 2 (process 5702) exited normally] (unpatched-gdb) It is possible to notice that, in this scenario, the patched GDB will lose the '[New process %d]' message. - With 'set print inferior-events on', 'set follow-fork-mode child' and 'set detach-on-fork on': (gdb) r Starting program: a.out [Attaching after process 27905 fork to child process 27909] [New inferior 2 (process 27909)] [Detaching after fork from parent process 27905] [Inferior 1 (process 27905) detached] [Inferior 2 (process 27909) exited normally] (gdb) Compare this output with an unpatched GDB, using the same settings: (unpatched-gdb) r Starting program: a.out [New inferior 28033] [Inferior 28029 detached] [New process 28033] [Inferior 2 (process 28033) exited normally] [Inferior 28033 exited] (unpatched-gdb) As can be seen above, I've also made a few modifications to messages that are printed when 'set print inferior-events' is on. For example, a few of the messages did not contain the '[' and ']' as prefix/suffix, which led to a few inconsistencies like: Attaching after process 22995 fork to child process 22999. [New inferior 22999] Detaching after fork from child process 22999. [Inferior 22995 detached] [Inferior 2 (process 22999) exited normally] So I took the opportunity and included the square brackets where applicable. I have also made the existing messages more uniform, by always printing "Inferior %d (process %d)..." where applicable. This makes it easier to identify the inferior number and the PID number from the messages. As suggested by Pedro, the "[Inferior %d exited]" message from 'exit_inferior' has been removed, because it got duplicated when 'inferior-events' is on. I'm also using the 'add_{thread,inferior}_silent' versions (instead of their verbose counterparts) on some locations, also to avoid duplicated messages. For example, a patched GDB with 'set print inferior-events on', 'set detach-on-fork on' and 'set follow-fork-mode child', but using 'add_thread', would print: (gdb) run Starting program: a.out [Attaching after process 25088 fork to child process 25092.] [New inferior 25092] <--- duplicated [Detaching after fork from child process 25092.] [Inferior 25088 detached] [New process 25092] <--- duplicated [Inferior 2 (process 25092) exited normally] But if we use 'add_thread_silent' (with the same configuration as before): (gdb) run Starting program: a.out [Attaching after process 31606 fork to child process 31610] [New inferior 2 (process 31610)] [Detaching after fork from parent process 31606] [Inferior 1 (process 31606) detached] [Inferior 2 (process 31610) exited normally] As for the tests, the configuration options being exercised are: - follow-fork-mode: child/parent - detach-on-fork: on/off - print inferior-events: on/off It was also necessary to perform adjustments on several testcases, because the expected messages changed considerably. Built and regtested on BuildBot, without regressions. gdb/ChangeLog: 2018-04-24 Jan Kratochvil <jan.kratochvil@redhat.com> Sergio Durigan Junior <sergiodj@redhat.com> Pedro Alves <palves@redhat.com> * infcmd.c (kill_command): Print message when inferior has been killed. * inferior.c (print_inferior_events): Remove 'static'. Set as '1'. (add_inferior): Improve message printed when 'print_inferior_events' is on. (exit_inferior): Remove message printed when 'print_inferior_events' is on. (detach_inferior): Improve message printed when 'print_inferior_events' is on. (initialize_inferiors): Use 'add_inferior_silent' to set 'current_inferior_'. * inferior.h (print_inferior_events): Declare here as 'extern'. * infrun.c (follow_fork_inferior): Print '[Attaching...]' or '[Detaching...]' messages when 'print_inferior_events' is on. Use 'add_thread_silent' instead of 'add_thread'. Add '[' and ']' as prefix/suffix for messages. Remove periods. Fix erroneous 'Detaching after fork from child...', replace it by '... from parent...'. (handle_vfork_child_exec_or_exit): Add '[' and ']' as prefix/suffix when printing 'Detaching...' messages. Print them when 'print_inferior_events' is on. * remote.c (remote_detach_1): Print message when detaching from inferior and '!is_fork_parent'. gdb/testsuite/ChangeLog: 2018-04-24 Jan Kratochvil <jan.kratochvil@redhat.com> Sergio Durigan Junior <sergiodj@redhat.com> Pedro Alves <palves@redhat.com> * gdb.base/attach-non-pgrp-leader.exp: Adjust 'Detaching...' regexps to expect for '[Inferior ... detached]' as well. * gdb.base/attach.exp: Likewise. * gdb.base/catch-syscall.exp (check_for_program_end): Adjust "gdb_continue_to_end". (test_catch_syscall_with_wrong_args): Likewise. * gdb.base/foll-fork.exp: Adjust regexps to match '[' and ']'. Don't set 'verbose' on. * gdb.base/foll-vfork.exp: Likewise. * gdb.base/fork-print-inferior-events.c: New file. * gdb.base/fork-print-inferior-events.exp: New file. * gdb.base/hook-stop.exp: Adjust regexps to expect for new '[Inferior ... has been killed]' message. * gdb.base/kill-after-signal.exp: Likewise. * gdb.base/solib-overlap.exp: Adjust regexps to expect for new detach message. * gdb.threads/kill.exp: Adjust regexps to expect for new kill message. * gdb.threads/clone-attach-detach.exp: Adjust 'Detaching...' regexps to expect for '[Inferior ... detached]' as well. * gdb.threads/process-dies-while-detaching.exp: Likewise.
2018-04-24info-shared.exp: Replace libs=-ldl with shlib_loadSimon Marchi2-1/+6
As reported in PR 23104, -ldl doesn't work on FreeBSD. Replace it with shlib_load, which adds the right flags for dynamic library loading based on the current target platform. The test still passes on Linux, and should now pass on FreeBSD, though I did not test personally. gdb/testsuite/ChangeLog: PR gdb/23104 * gdb.base/info-shared.exp: Replace libs=-ldl with shlib_load.
2018-04-24Reindent cli-out.hTom Tromey2-7/+13
I noticed that cli-out.h had incorrect indentation in some spots. This fixes it. ChangeLog 2018-04-24 Tom Tromey <tom@tromey.com> * cli-out.h: Reindent.
2018-04-24Remove cli_ui_out::out_field_fmtTom Tromey3-19/+7
I noticed that cli_ui_out::out_field_fmt is only used by a single caller, and it can easily be replaced by fputs_filtered. So, this patch removes it. ChangeLog 2018-04-24 Tom Tromey <tom@tromey.com> * cli-out.c (cli_ui_out::out_field_fmt): Remove. (cli_ui_out::do_field_string): Use fputs_filtered. * cli-out.h (class cli_ui_out) <out_field_fmt>: Remove.
2018-04-23Remove a cleanup from scm-frame.cTom Tromey2-29/+30
This removes a cleanup from scm-frame.c, replacing it with unique_xmalloc_ptr and a new scope. I believe this also fixes a latent bug involving calling do_cleanups twice for a single cleanup. Regression tested using the gdb.guile test suite on x86-64 Fedora 26. ChangeLog 2018-04-23 Tom Tromey <tom@tromey.com> * guile/scm-frame.c (gdbscm_frame_read_var): Use gdb::unique_xmalloc_ptr.
2018-04-23Regenerate gdb/configure and gdbserver/configureTom Tromey4-24/+39
Pedro pointed out that gdb/configure and gdbserver/configure weren't updated after some recent *.m4 changes. This patch rebuilds those files. Tested by rebuilding. Pedro approved this in the thread where he raised this issue, so I'm pushing it in. ChangeLog 2018-04-23 Tom Tromey <tom@tromey.com> * configure: Rebuild. gdbserver/ChangeLog 2018-04-23 Tom Tromey <tom@tromey.com> * configure: Rebuild.
2018-04-22Fixed test case to compile & run on FreeBSDRajendra SY2-2/+13
Problems: 1. linking -dl lib on FreeBSD platform 2. backtrace from ld-elf shows r_debug_state() instead of _dl_debug_state() Cause: 1. There is no dl library on FreeBSD platform test has to ignore linking "-ldl" 2. The stop due to a shared library event shows backtrace frame #0 function as r_debug_state() gdb/ChangeLog: PR gdb/23095 * gdb/testsuite/gdb.base/break-probes.exp: Pass shlib_load to prepare_for_testing. Set normal_bp to r_debug_state if target is bsd.
2018-04-21FreeBSD: Fix 'Couldn't get registers: Device busy' error (PR gdb/23077)Pedro Alves3-2/+15
As Rajendra SY reported at <https://sourceware.org/ml/gdb-patches/2018-04/msg00399.html>, several attach-related tests are failing on FreeBSD. The "attach" command errors with "Couldn't get registers: Device busy". When the "attach" command is executed, it calls target_attach -> inf_ptrace_attach, which just does the ptrace(PT_ATTACH), it does not wait for the child to stop with SIGSTOP. Afterwards, the command is complete and we go back to the event loop. The event loop wakes up and we end up in target_wait -> fbsd_wait, and handle the SIGSTOP stop. At the end of execute_command, though, before going back to the event loop, we check if the frame language changed via check_frame_language_change(). That reads the current PC, which is what leads to the registers read that fails. The problem is that we fail to mark the attached-to thread as executing between the initial attach, and the subsequent target_wait. Until we see the thread stop with SIGSTOP, we shouldn't try to read registers off of it. I guess there may a timing issue here - if you're "lucky", the thread may stop before gdb reads its registers, masking the problem. With that fixed, check_frame_language_change() becomes a nop until the thread is marked not-executing again, after target_wait is called and we go through handle_inferior_event -> normal_stop. We haven't seen the problem on Linux because there, the target_attach implementation waits for the thread to stop before returning. Still, that's supposedly hidden from the core, since the Linux target, like most targets, is a '!to_attach_no_wait' target. This fixes: FAIL: gdb.base/attach.exp: attach1, after setting file FAIL: gdb.base/attach.exp: attach2, with no file FAIL: gdb.base/attach.exp: load file manually, after attach2 (re-read) (got interactive prompt) FAIL: gdb.base/attach.exp: attach when process' a.out not in cwd FAIL: gdb.base/dprintf-detach.exp: bai=on ds=gdb dd=on: re-attach to inferior FAIL: gdb.base/dprintf-detach.exp: bai=on ds=gdb dd=off: re-attach to inferior FAIL: gdb.base/dprintf-detach.exp: bai=on ds=call dd=on: re-attach to inferior FAIL: gdb.base/dprintf-detach.exp: bai=on ds=call dd=off: re-attach to inferior FAIL: gdb.base/dprintf-detach.exp: bai=on ds=agent dd=on: re-attach to inferior FAIL: gdb.base/dprintf-detach.exp: bai=on ds=agent dd=off: re-attach to inferior FAIL: gdb.base/dprintf-detach.exp: bai=off ds=gdb dd=on: re-attach to inferior FAIL: gdb.base/dprintf-detach.exp: bai=off ds=gdb dd=off: re-attach to inferior FAIL: gdb.base/dprintf-detach.exp: bai=off ds=call dd=on: re-attach to inferior FAIL: gdb.base/dprintf-detach.exp: bai=off ds=call dd=off: re-attach to inferior FAIL: gdb.base/dprintf-detach.exp: bai=off ds=agent dd=on: re-attach to inferior FAIL: gdb.base/dprintf-detach.exp: bai=off ds=agent dd=off: re-attach to inferior gdb/ChangeLog: 2018-04-21 Pedro Alves <palves@redhat.com> Rajendra SY <rajendra.sy@gmail.com> * inf-ptrace.c (inf_ptrace_attach): Mark the thread as executing. * remote.c (extended_remote_attach): In all-stop mode, mark the thread as executing.
2018-04-20Improve on-line help for thread_apply_command and thread_apply_all_command.Philippe Waroquiers1-3/+5
Add a Usage: line for thread_apply_command, in particular to mention the thread ID list. In thread_apply_command and thread_apply_all_command help, use uppercase for arg names, as this style seems to be more standard. 2018-04-20 Philippe Waroquiers <philippe.waroquiers@skynet.be> * thread.c (_initialize_thread): improve on-line help for thread_apply_command and thread_apply_all_command.
2018-04-19Add test case for a known hang in infrunRichard Bunt3-0/+188
The hang occurs when GDB tries to call inferior functions on two different threads with scheduler-locking turned on. The first call works fine, with the call to infrun_async(1) causing the signal_handler to be marked and the event to be handled, but then the event loop resets the "ready" member to zero, while leaving infrun_is_async set to 1. As a result, GDB hangs if the user switches to another thread and calls a second function because calling infrun_async(1) a second time has no effect, meaning the inferior call events are never handled. The added test case provokes the above issue. gdb/testsuite/ChangeLog: * gdb.threads/multiple-successive-infcall.c: New test. * gdb.threads/multiple-successive-infcall.exp: New file.
2018-04-19[OB PATCH] Fix some comments in thread.cPhilippe Waroquiers2-5/+9
Fix some typos. Remove obsolete comment about dispatch to thread_apply_command, rather tell that thread_command either switches to a thread, or prints the current thread. 2018-04-19 Philippe Waroquiers <philippe.waroquiers@skynet.be> * thread.c (thread_apply_all_command): Fix comment. (thread_command): Fix comment.
2018-04-19Fix dependency tracking in gdbserver subdirectoriesSimon Marchi2-2/+11
The dependency tracking (the thing that knows which source file included which other source file during last build to know what to rebuild when an included file changes) is broken for gdbserver subdirectories (arch and common). The dependency tracking files are created in the form arch/.deps/i386.Po but we try to include .deps/arch/i386.Po An easy smoke test is too "touch" the gdb/features/i386/32bit-core.c file in the source directory and try to rebuild gdbserver. This file is included by gdb/arch/i386.c, so it should cause gdb/gdbserver/arch/i386.o in the build directory to be rebuilt. It currently isn't rebuilt, but is with this patch applied. This patch copies the technique used in GDB to transform the dep file paths to the proper form. Also, while testing using the depcomp method of dependency tracking (by just hacking the condition), I noticed that depcomp was not found. The path to depcomp seems to be missing a "..". gdb/gdbserver/ChangeLog: * Makefile.in (depcomp): Add "..". (all_deps_files): New and use it.
2018-04-18Remove xml files from gdbserverAlan Hayward2-28/+14
For ports which use new target descriptions, remove the xml files from being built into gdbserver. gdbserver/ * configure.srv (aarch64*-*-linux*): Don't include xml. (i[34567]86-*-cygwin*): Likewise. (i[34567]86-*-linux*): Likewise. (i[34567]86-*-lynxos*): Likewise. (i[34567]86-*-mingw32ce*): Likewise. (i[34567]86-*-mingw*): Likewise. (i[34567]86-*-nto*): Likewise. (tic6x-*-uclinux): Likewise. (x86_64-*-linux*): Likewise. (x86_64-*-mingw*): Likewise. (x86_64-*-cygwin*): Likewise.
2018-04-18Remove xml file references from target descriptionsAlan Hayward26-32/+77
gdb/ * common/tdesc.h (tdesc_create_feature): Remove xml filename parameter. * features/aarch64-core.c (create_feature_aarch64_core): Regenerate. * features/aarch64-fpu.c (create_feature_aarch64_fpu): Likewise. * features/i386/32bit-avx.c (create_feature_i386_32bit_avx): Likewise. * features/i386/32bit-avx512.c (create_feature_i386_32bit_avx512): Likewise. * features/i386/32bit-core.c (create_feature_i386_32bit_core): Likewise. * features/i386/32bit-linux.c (create_feature_i386_32bit_linux): Likewise. * features/i386/32bit-mpx.c (create_feature_i386_32bit_mpx): Likewise. * features/i386/32bit-pkeys.c (create_feature_i386_32bit_pkeys): Likewise. * features/i386/32bit-sse.c (create_feature_i386_32bit_sse): Likewise. * features/i386/64bit-avx.c (create_feature_i386_64bit_avx): Likewise. * features/i386/64bit-avx512.c (create_feature_i386_64bit_avx512): Likewise. * features/i386/64bit-core.c (create_feature_i386_64bit_core): Likewise. * features/i386/64bit-linux.c (create_feature_i386_64bit_linux): Likewise. * features/i386/64bit-mpx.c (create_feature_i386_64bit_mpx): Likewise. * features/i386/64bit-pkeys.c (create_feature_i386_64bit_pkeys): Likewise. * features/i386/64bit-segments.c (create_feature_i386_64bit_segments): Likewise. * features/i386/64bit-sse.c (create_feature_i386_64bit_sse): Likewise. * features/i386/x32-core.c (create_feature_i386_x32_core): Likewise. * features/tic6x-c6xp.c (create_feature_tic6x_c6xp): Likewise. * features/tic6x-core.c (create_feature_tic6x_core): Likewise. * features/tic6x-gp.c (create_feature_tic6x_gp): Likewise. * target-descriptions.c: In generated code, don't pass xml filename. gdbserver/ * tdesc.c: Remove xml parameter.
2018-04-18Create xml from target descriptionsAlan Hayward11-38/+260
Add a print_xml_feature visitor class which turns a target description into xml. Both gdb and gdbserver can do this. gdb/ * common/tdesc.c (print_xml_feature::visit_pre): Add xml parsing. (print_xml_feature::visit_post): Likewise. (print_xml_feature::visit): Likewise. * common/tdesc.h (tdesc_get_features_xml): Use const tdesc. (print_xml_feature): Add new class. * regformats/regdat.sh: Null xmltarget on feature targets. * target-descriptions.c (struct target_desc): Add xmltarget. (maintenance_check_tdesc_xml_convert): Add unittest function. (tdesc_get_features_xml): Add function to get xml. (maintenance_check_xml_descriptions): Test xml generation. * xml-tdesc.c (string_read_description_xml): Add function. * xml-tdesc.h (string_read_description_xml): Add declaration. gdbserver/ * gdb/gdbserver/server.c (get_features_xml): Remove cast. * tdesc.c (void target_desc::accept): Fill in function. (tdesc_get_features_xml): Remove old xml creation. (print_xml_feature::visit_pre): Add xml vistor. * tdesc.h (struct target_desc): Make xmltarget mutable. (tdesc_get_features_xml): Remove declaration.
2018-04-18Add feature reference in .dat filesAlan Hayward25-0/+60
For all targets which use the newer style target descriptions, add a "feature" marker in the dat files. Update regdat.sh to parse feature, but do not use it (yet). gdb/ * features/Makefile: Add feature marker to targets with new style target descriptions. * regformats/aarch64.dat: Regenerate. * regformats/i386/amd64-avx-avx512-linux.dat: Likewise. * regformats/i386/amd64-avx-linux.dat: Likewise. * regformats/i386/amd64-avx-mpx-avx512-pku-linux.dat: Likewise. * regformats/i386/amd64-avx-mpx-linux.dat: Likewise. * regformats/i386/amd64-linux.dat: Likewise. * regformats/i386/amd64-mpx-linux.dat: Likewise. * regformats/i386/amd64.dat: Likewise. * regformats/i386/i386-avx-avx512-linux.dat: Likewise. * regformats/i386/i386-avx-linux.dat: Likewise. * regformats/i386/i386-avx-mpx-avx512-pku-linux.dat: Likewise. * regformats/i386/i386-avx-mpx-linux.dat: Likewise. * regformats/i386/i386-linux.dat: Likewise. * regformats/i386/i386-mmx-linux.dat: Likewise. * regformats/i386/i386-mpx-linux.dat: Likewise. * regformats/i386/i386.dat: Likewise. * regformats/i386/x32-avx-avx512-linux.dat: Likewise. * regformats/i386/x32-avx-linux.dat: Likewise. * regformats/i386/x32-linux.dat: Likewise. * regformats/tic6x-c62x-linux.dat: Likewise. * regformats/tic6x-c64x-linux.dat: Likewise. * regformats/tic6x-c64xp-linux.dat: Likewise. * regformats/regdat.sh: Parse feature marker.
2018-04-18Add tdesc osabi and architecture functionsAlan Hayward5-4/+60
gdb/ * common/tdesc.h (tdesc_architecture_name): Add new declaration. (tdesc_osabi_name): Likewise. * target-descriptions.c (tdesc_architecture_name): Add new function. (tdesc_osabi_name): Likewise. gdbserver/ * tdesc.c (tdesc_architecture_name): Add new function. (tdesc_osabi_name): Likewise. (tdesc_get_features_xml): Use new functions.
2018-04-18Commonise tdesc types and makes use of them in gdbserver tdescAlan Hayward7-334/+336
gdb/ * common/tdesc.c (tdesc_predefined_type): Move to here. (tdesc_named_type): Likewise. (tdesc_create_vector): Likewise. (tdesc_create_struct): Likewise. (tdesc_set_struct_size): Likewise. (tdesc_create_union): Likewise. (tdesc_create_flags): Likewise. (tdesc_create_enum): Likewise. (tdesc_add_field): Likewise. (tdesc_add_typed_bitfield): Likewise. (tdesc_add_bitfield): Likewise. (tdesc_add_flag): Likewise. (tdesc_add_enum_value): Likewise. * common/tdesc.h (struct tdesc_type_builtin): Likewise. (struct tdesc_type_vector): Likewise. (struct tdesc_type_field): Likewise. (struct tdesc_type_with_fields): Likewise. (tdesc_create_enum): Add declaration. (tdesc_add_typed_bitfield): Likewise. (tdesc_add_enum_value): Likewise. * target-descriptions.c (tdesc_type_field): Move from here. (tdesc_type_builtin): Likewise. (tdesc_type_vector): Likewise. (tdesc_type_with_fields): Likewise. (tdesc_predefined_types): Likewise. (tdesc_named_type): Likewise. (tdesc_create_vector): Likewise. (tdesc_create_struct): Likewise. (tdesc_set_struct_size): Likewise. (tdesc_create_union): Likewise. (tdesc_create_flags): Likewise. (tdesc_create_enum): Likewise. (tdesc_add_field): Likewise. (tdesc_add_typed_bitfield): Likewise. (tdesc_add_bitfield): Likewise. (tdesc_add_flag): Likewise. (tdesc_add_enum_value): Likewise. * gdb/target-descriptions.h (tdesc_create_enum): Likewise. (tdesc_add_typed_bitfield): Likewise. (tdesc_add_enum_value): Likewise. gdbserver/ * tdesc.c (tdesc_create_flags): Remove. (tdesc_add_flag): Likewise. (tdesc_named_type): Likewise. (tdesc_create_union): Likewise. (tdesc_create_struct): Likewise. (tdesc_create_vector): Likewise. (tdesc_add_bitfield): Likewise. (tdesc_add_field): Likewise. (tdesc_set_struct_size): Likewise.
2018-04-18Commonise tdesc_feature and makes use of it in gdbserver tdescAlan Hayward8-197/+199
gdb/ * common/tdesc.c (tdesc_feature::accept): Move to here. (tdesc_feature::operator==): Likewise. (tdesc_create_reg): Likewise. * common/tdesc.h (tdesc_type_kind): Likewise. (struct tdesc_type): Likewise. (struct tdesc_feature): Likewise. * regformats/regdat.sh: Create a feature. * target-descriptions.c (tdesc_type_kind): Move from here. (tdesc_type): Likewise. (tdesc_type_up): Likewise. (tdesc_feature): Likewise. (tdesc_create_reg): Likewise. gdbserver/ * tdesc.c (~target_desc): Remove implictly deleted items. (init_target_desc): Iterate all features. (tdesc_get_features_xml): Use vector. (tdesc_create_feature): Create feature. * tdesc.h (tdesc_feature) Remove (target_desc): Add features.
2018-04-18Commonise tdesc_reg and makes use of it in gdbserver tdescAlan Hayward10-129/+190
gdb/ * Makefile.in: Add arch/tdesc.c * common/tdesc.c: New file. * common/tdesc.h (tdesc_element_visitor): Move to here. (tdesc_element): Likewise. (tdesc_reg): Likewise. (tdesc_reg_up): Likewise. * regformats/regdef.h (reg): Add offset to constructors. * target-descriptions.c (tdesc_element_visitor): Move from here. (tdesc_element): Likewise. (tdesc_reg): Likewise. (tdesc_reg_up): Likewise. gdbserver/ * Makefile.in: Add common/tdesc.c * tdesc.c (init_target_desc): init all reg_defs from register vector. (tdesc_create_reg): Create tdesc_reg. * tdesc.h (tdesc_feature): Add register vector.
2018-04-17Conditionally drop the discriminant field in quirk_rust_enumTom Tromey2-3/+11
While debugging the crash that Jan reported, I noticed that in some situations we could end up with a situation where one branch of a Rust enum type ended up with a field count of -1. The fix is simple: only conditionally drop the discriminant field when rewriting the enum variants. I couldn't find a way to test this; I only noticed it while debugging the DWARF reader. 2018-04-17 Tom Tromey <tom@tromey.com> * dwarf2read.c (quirk_rust_enum): Conditionally drop the discriminant field.
2018-04-17Fix crash in quirk_rust_enumTom Tromey5-1/+25
I noticed that quirk_rust_enum can crash when presented with a union whose fields are all scalar types. This patch adds a new test case and fixes the bug. Regression tested on Fedora 26 x86-64. 2018-04-17 Tom Tromey <tom@tromey.com> * dwarf2read.c (quirk_rust_enum): Handle unions correctly. 2018-04-17 Tom Tromey <tom@tromey.com> * gdb.rust/simple.rs (Union): New type. (main): New local "u". * gdb.rust/simple.exp (test_one_slice): Add new test case.
2018-04-17Don't print symbol declaration's line number in rbreak outputAndreas Arnez2-16/+28
This commit: b744723f57 -- Show line numbers in output for "info var/func/type" adds the symbol declaration's line number to the output of certain GDB commands. It also (inadvertently) changes the `rbreak' command's output, like this: (gdb) rbreak foo Breakpoint 1 at 0x40049b: file rbreak.c, line 6. 4: static int foo1(void); Breakpoint 2 at 0x4004b1: file rbreak.c, line 12. 10: static int foo2(void); (gdb) where the function declaration is now prefixed by its source line number, followed by a colon. But without showing the declaration's file name, the line number is useless and can possibly cause severe confusion. No declaration line number was shown before. Instead, the function declaration started at the first column: (gdb) rbreak foo Breakpoint 1 at 0x40049b: file rbreak.c, line 6. static int foo1(void); Breakpoint 2 at 0x4004b1: file rbreak.c, line 12. static int foo2(void); (gdb) This old behavior is restored, fixing some FAILs in fullpath-expand.exp, realname-expand.exp, and pr10179.exp. In order to distinguish when to print location information, the meaning of print_symbol_info()'s parameter `last' is changed. Now NULL means to skip any filename or line number information. Previously NULL meant to always print the filename. gdb/ChangeLog: * symtab.c (print_symbol_info): Skip printing filename and line number when `last' is NULL. (symtab_symbol_info): Use empty string instead of NULL for first invocation of print_symbol_info. (rbreak_command): Pass NULL to `last' parameter of print_symbol_info.
2018-04-16linux_spu_make_corefile_notes: return note_data instead of nullptrSimon Marchi2-1/+6
Since commit 9018be2 ("Make target_read_alloc & al return vectors") the test gdb.threads/gcore-stale-thread.exp test results in UNSUPPORTED: UNSUPPORTED: gdb.threads/gcore-stale-thread.exp: save a corefile The problem is that the linux_spu_make_corefile_notes started returning nullptr when reading TARGET_OBJECT_SPU fails. The previous (and proper) behaviour is to return the note_data received as a parameter, so that other functions may continue to append to this buffer. With this patch, the test goes back to PASS. gdb/ChangeLog: * linux-tdep.c (linux_spu_make_corefile_notes): Return note_data instead of nullptr.
2018-04-16Adjust more test cases to changed output of info var/func/typeAndreas Arnez3-2/+8
After this commit: b744723f57 -- Show line numbers in output for "info var/func/type" the test cases dbx.exp and info-fun.exp yield new FAILs because two regular expressions have not been adjusted to the changed output yet. This is fixed. gdb/testsuite/ChangeLog: * gdb.base/dbx.exp (test_whereis): Adjust regexp to added line number information in output of "whereis" command. * gdb.base/info-fun.exp: Likewise, for "info fun" command.
2018-04-16gdb: Remove support for SH-5/SH64Pedro Alves10-2499/+32
Since bfd dropped support for SH-5, there's no point in keeping it in GDB either. This restores --enable-targets=all builds. gdb/ChangeLog: 2018-04-16 Pedro Alves <palves@redhat.com> * MAINTAINERS (sh): Remove. * Makefile.in (ALL_TARGET_OBS): Remove sh64-tdep.o. (HFILES_NO_SRCDIR): Remove sh64-tdep.h. (ALLDEPFILES): Remove sh64-tdep.c. * NEWS: Mentions that support for SH-5/SH64 is removed. * configure.tgt (sh*-*-linux*): Remove reference to sh64-tdep.o. (sh*-*-openbsd*): Ditto. (sh64-*-elf*): Remove. (sh*): Remove. * regcache.c (cooked_write_test): Remove bfd_mach_sh5 case. * sh-linux-tdep.c: Remove reference to bfd_mach_sh5. * sh-tdep.c: No longer include "sh64-tdep.h". (sh_gdbarch_init): Remove reference to bfd_mach_sh5. * sh64-tdep.c, sh64-tdep.h: Remove files.
2018-04-16gdb: Remove OpenBSD/m88k supportPedro Alves10-1038/+16
Support for m88k was fully removed from bfd, which broke gdb --enable-targets=all builds: > gdb/m88k-tdep.c: In function void _initialize_m88k_tdep(): > gdb/m88k-tdep.c:867:21: error: bfd_arch_m88k was not declared in this scope > gdbarch_register (bfd_arch_m88k, m88k_gdbarch_init, NULL); There's no point in keeping GDB support for OpenBSD/m88k with no bfd support, so this commit simply removes the port. gdb/ChangeLog: 2018-04-16 Pedro Alves <palves@redhat.com> * MAINTAINERS: Remove m88k. * Makefile.in (ALL_TARGET_OBS): Remove m88k-tdep.o. (HFILES_NO_SRCDIR): Remove m88k-tdep.h. (ALLDEPFILES): Remove m88k-bsd-nat.c and m88k-tdep.c. * NEWS: Mention that support for OpenBSD/m88k was removed. * configure.host (m88*-*-*): Remove support. * configure.nat (m88k-*-*): Remove support. * configure.tgt (m88*-*-openbsd*): Remove. * m88k-bsd-nat.c, m88k-tdep.c, m88k-tdep.h: Delete.
2018-04-15Add x86-tdep.o to i386/amd64 target buildSimon Marchi2-2/+8
We get this error when doing a build with a single amd64 target (the default when doing just ./configure on x86-64 GNU/Linux): /home/simark/src/binutils-gdb/gdb/i386-tdep.c:4431: error: undefined reference to 'x86_in_indirect_branch_thunk(unsigned long, char const**, int, int)' /home/simark/src/binutils-gdb/gdb/amd64-tdep.c:3045: error: undefined reference to 'x86_in_indirect_branch_thunk(unsigned long, char const**, int, int)' The problem is that commit 1d509aa625f8 ("infrun: step through indirect branch thunks") missed adding x86-tdep.o to the list of object file included in an amd64 or i386 build. The problem is not seen with --enable-targets=all because that file is included in ALL_TARGET_OBS. Built-tested using: * --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu * --host=armv7-rpi2-linux-gnueabihf --target=x86_64-pc-linux-gnu gdb/ChangeLog: * configure.tgt (x86_tobjs): New variable. (amd64_tobjs, i386_tobjs): Use it.
2018-04-13Show line numbers in output for "info var/func/type"Andreas Arnez13-18/+53
The GDB commands "info variables", "info functions", and "info types" show the appropriate list of definitions matching the given pattern. They also group them by source files. But no line numbers within these source files are shown. The line number information is particularly useful to the user when a simple "grep" doesn't readily point to a definition. This is often the case when the definition involves a macro, occurs within a namespace, or when the identifier appears very frequently in the source file. This patch enriches the printout of these commands by the line numbers and adjusts affected test cases to the changed output where necessary. The new output looks like this: (gdb) i variables All defined variables: File foo.c: 3: const char * const foo; 1: int x; The line number is followed by a colon and a tab character, which is then followed by the symbol definition. If no line number is available, the tab is printed out anyhow, so definitions line up. gdb/ChangeLog: * symtab.c (print_symbol_info): Precede the symbol definition by the line number when available. * NEWS: Advertise this enhancement. gdb/doc/ChangeLog: * gdb.texinfo (Symbols): Mention the fact that "info variables/functions/types" show source files and line numbers. gdb/testsuite/ChangeLog: * gdb.ada/info_types.exp: Adjust expected output to the line numbers now printed by "info var/func/type". * gdb.base/completion.exp: Likewise. * gdb.base/included.exp: Likewise. * gdb.cp/cp-relocate.exp: Likewise. * gdb.cp/cplusfuncs.exp: Likewise. * gdb.cp/namespace.exp: Likewise. * gdb.dwarf2/dw2-case-insensitive.exp: Likewise.
2018-04-13btrace: set/show record btrace cpuMarkus Metzger11-33/+416
Add new set/show commands to set the processor that is used for enabling errata workarounds when decoding branch trace. The general format is "<vendor>:<identifier>" but we also allow two special values "auto" and "none". The default is "auto", which is the current behaviour of having GDB determine the processor on which the trace was recorded. If that cpu is not known to the trace decoder, e.g. when using an old decoder on a new system, decode may fail with "unknown cpu". In most cases it should suffice to 'downgrade' decode to assume an older cpu. Unfortunately, we can't do this automatically. The other special value, "none", disables errata workarounds. gdb/ * NEWS (New options): announce set/show record btrace cpu. * btrace.c: Include record-btrace.h. (btrace_compute_ftrace_pt): Skip enabling errata workarounds if the vendor is unknown. (btrace_compute_ftrace_1): Add cpu parameter. Update callers. Maybe overwrite the btrace configuration's cpu. (btrace_compute_ftrace): Add cpu parameter. Update callers. (btrace_fetch): Add cpu parameter. Update callers. (btrace_maint_update_pt_packets): Call record_btrace_get_cpu. Maybe overwrite the btrace configuration's cpu. Skip enabling errata workarounds if the vendor is unknown. * python/py-record-btrace.c: Include record-btrace.h. (recpy_bt_begin, recpy_bt_end, recpy_bt_instruction_history) (recpy_bt_function_call_history): Call record_btrace_get_cpu. * record-btrace.c (record_btrace_cpu_state_kind): New. (record_btrace_cpu): New. (set_record_btrace_cpu_cmdlist): New. (record_btrace_get_cpu): New. (require_btrace_thread, record_btrace_info) (record_btrace_resume_thread): Call record_btrace_get_cpu. (cmd_set_record_btrace_cpu_none): New. (cmd_set_record_btrace_cpu_auto): New. (cmd_set_record_btrace_cpu): New. (cmd_show_record_btrace_cpu): New. (_initialize_record_btrace): Initialize set/show record btrace cpu commands. * record-btrace.h (record_btrace_get_cpu): New. testsuite/ * gdb.btrace/cpu.exp: New. doc/ * gdb.texinfo: Document set/show record btrace cpu.
2018-04-13record: fix typo in "set record" outputMarkus Metzger2-1/+5
Alan Hayward pointed out a typo in the output of "set record btrace" that I took from "set record". Fix the original. gdb/ * record.c (set_record_command): Fix typo in message.
2018-04-13btrace: fix output of "set record btrace"Markus Metzger2-1/+8
Instead of giving a message that "set record btrace" needs a sub-command, GDB crashed. Fix it. A regression test comes with the next patch. gdb/ * record-btrace.c (cmd_set_record_btrace): Print sub-commands.
2018-04-13infrun: step through indirect branch thunksMarkus Metzger17-1/+473
With version 7.3 GCC supports new options -mindirect-branch=<choice> -mfunction-return=<choice> The choices are: keep behaves as before thunk jumps through a thunk thunk-external jumps through an external thunk thunk-inline jumps through an inlined thunk For thunk and thunk-external, GDB would, on a call to the thunk, step into the thunk and then resume to its caller assuming that this is an undebuggable function. On a return thunk, GDB would stop inside the thunk. Make GDB step through such thunks instead. Before: Temporary breakpoint 1, main () at gdb.base/step-indirect-call-thunk.c:37 37 x = apply (inc, 41); (gdb) s apply (op=0x80483e6 <inc>, x=41) at gdb.base/step-indirect-call-thunk.c:29 29 return op (x); (gdb) 30 } After: Temporary breakpoint 1, main () at gdb.base/step-indirect-call-thunk.c:37 37 x = apply (inc, 41); (gdb) s apply (op=0x80483e6 <inc>, x=41) at gdb.base/step-indirect-call-thunk.c:29 29 return op (x); (gdb) inc (x=41) at gdb.base/step-indirect-call-thunk.c:23 23 return x + 1; This is independent of the step-mode. In order to step into the thunk, you would need to use stepi. When stepping over an indirect call thunk, GDB would first step through the thunk, then recognize that it stepped into a sub-routine and resume to the caller (of the thunk). Not sure whether this is worth optimizing. Thunk detection is implemented via gdbarch. I implemented the methods for IA. Other architectures may run into unexpected fails. The tests assume a fixed number of instruction steps to reach a thunk. This depends on the compiler as well as the architecture. They may need adjustments when we add support for more architectures. Or we can simply drop those tests that cover being able to step into thunks using instruction stepping. When using an older GCC, the tests will fail to build and will be reported as untested: Running .../gdb.base/step-indirect-call-thunk.exp ... gdb compile failed, \ gcc: error: unrecognized command line option '-mindirect-branch=thunk' gcc: error: unrecognized command line option '-mfunction-return=thunk' === gdb Summary === # of untested testcases 1 gdb/ * infrun.c (process_event_stop_test): Call gdbarch_in_indirect_branch_thunk. * gdbarch.sh (in_indirect_branch_thunk): New. * gdbarch.c: Regenerated. * gdbarch.h: Regenerated. * x86-tdep.h: New. * x86-tdep.c: New. * Makefile.in (ALL_TARGET_OBS): Add x86-tdep.o. (HFILES_NO_SRCDIR): Add x86-tdep.h. (ALLDEPFILES): Add x86-tdep.c. * arch-utils.h (default_in_indirect_branch_thunk): New. * arch-utils.c (default_in_indirect_branch_thunk): New. * i386-tdep: Include x86-tdep.h. (i386_in_indirect_branch_thunk): New. (i386_elf_init_abi): Set in_indirect_branch_thunk gdbarch function. * amd64-tdep: Include x86-tdep.h. (amd64_in_indirect_branch_thunk): New. (amd64_init_abi): Set in_indirect_branch_thunk gdbarch function. testsuite/ * gdb.base/step-indirect-call-thunk.exp: New. * gdb.base/step-indirect-call-thunk.c: New. * gdb.reverse/step-indirect-call-thunk.exp: New. * gdb.reverse/step-indirect-call-thunk.c: New.
2018-04-12Fix -D_GLIBCXX_DEBUG gdb-add-index regressionJan Kratochvil2-9/+21
Fedora Rawhide started to use -D_GLIBCXX_DEBUG which made gdb-add-index failing: gdb: Out-of-bounds vector access while running gdb-add-index https://bugzilla.redhat.com/show_bug.cgi?id=1540559 /usr/include/c++/7/debug/safe_iterator.h:270: Error: attempt to dereference a past-the-end iterator. Objects involved in the operation: iterator "this" @ 0x0x7fffffffcb90 { type = __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<unsigned char*, std::__cxx1998::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > > >, std::__debug::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > > > (mutable iterator); state = past-the-end; references sequence with type 'std::__debug::vector<unsigned char, gdb::default_init_allocator<unsigned char, std::allocator<unsigned char> > >' @ 0x0x7fffffffcc50 } /usr/include/c++/7/debug/vector:417: Error: attempt to subscript container with out-of-bounds index 556, but container only holds 556 elements. Objects involved in the operation: sequence "this" @ 0x0x2e87af8 { type = std::__debug::vector<partial_symbol*, std::allocator<partial_symbol*> >; } The two -D_GLIBCXX_DEBUG regressions were made by: commit bc8f2430e08cc2a520db49a42686e0529be4a3bc Author: Jan Kratochvil <jan.kratochvil@redhat.com> Date: Mon Jun 12 16:29:53 2017 +0100 Code cleanup: C++ify .gdb_index producer commit af5bf4ada48ff65b6658be1fab8f9c8f8ab5f319 Author: Simon Marchi <simon.marchi@ericsson.com> Date: Sat Oct 14 08:06:29 2017 -0400 Replace psymbol_allocation_list with std::vector gdb/ChangeLog 2018-04-12 Jan Kratochvil <jan.kratochvil@redhat.com> PR gdb/23053 * dwarf-index-write.c (data_buf::grow) (write_one_signatured_type) (recursively_write_psymbols) (debug_names::recursively_write_psymbols) (debug_names::write_one_signatured_type): Fix -D_GLIBCXX_DEBUG regression.
2018-04-12Remove old univariant code from rust-lang.cTom Tromey2-23/+7
Since moving Rust enum handling into dwarf2read.c, some old code for handling univariant enums in rust-lang.c has been obsolete. This patch removes this code. Tested on x86-64 Fedora 26, using rustc 1.23 (1.24 emits incorrect DWARF for enums and so can't be used for this test). 2018-04-12 Tom Tromey <tom@tromey.com> * rust-lang.c (rust_print_struct_def): Remove univariant code. (rust_evaluate_subexp): Likewise.
2018-04-12Fix Solaris buildPedro Alves2-5/+8
This commit fixes a bit of rot in procfs.c caused by recent changes. Specifically, the target_ops::to_detach change to pass down 'inferior *' missed updating a forward declation, and the change to use scoped_fd in more places missed removing one do_cleanups call. src/gdb/procfs.c: In function ‘target_ops* procfs_target()’: src/gdb/procfs.c:167:16: error: invalid conversion from ‘void (*)(target_ops*, const char*, int)’ to ‘void (*)(target_ops*, inferior*, int)’ [-fpermissive] t->to_detach = procfs_detach; ^ src/gdb/procfs.c: In function ‘ssd* proc_get_LDT_entry(procinfo*, int)’: src/gdb/procfs.c:1624:17: error: ‘old_chain’ was not declared in this scope do_cleanups (old_chain); ^ src/gdb/procfs.c: At global scope: src/gdb/procfs.c:90:13: error: ‘void procfs_detach(target_ops*, const char*, int)’ declared ‘static’ but never defined [-Werror=unused-function] static void procfs_detach (struct target_ops *, const char *, int); ^ src/gdb/procfs.c:1923:1: error: ‘void procfs_detach(target_ops*, inferior*, int)’ defined but not used [-Werror=unused-function] procfs_detach (struct target_ops *ops, inferior *inf, int from_tty) ^ gdb/ChangeLog: 2018-04-12 Pedro Alves <palves@redhat.com> * procfs.c (procfs_detach): Make forward declaration's prototype match definition's protototype. (proc_get_LDT_entry): Remove stale do_cleanups call.
2018-04-12Eliminate target_has_exitedPedro Alves3-46/+6
Nothing uses this. gdb/ChangeLog: 2018-04-12 Pedro Alves <palves@redhat.com> * target.h (target_ops::to_has_exited): Delete. (target_has_exited): Delete. * target-delegates.c: Regenerate.
2018-04-11Add test for following fork on position-independent executablesSimon Marchi3-0/+104
Commit b2e586e ("Defer breakpoint reset when cloning progspace for fork child") fixed following fork childs when the executable is position-independent. This patch adds a little test for it. gdb/testsuite/ChangeLog: * gdb.base/pie-fork.c: New file. * gdb.base/pie-fork.exp: New file.
2018-04-11Add Rust test case for ".." struct initializerTom Tromey2-0/+7
Building with --coverage pointed out that there was no Rust test for initializing a structure using the ".." initializer. This patch adds such a test. Regression tested on x86-64 Fedora 26. 2018-04-11 Tom Tromey <tom@tromey.com> * gdb.rust/simple.exp: Add test for ".." struct initializer.
2018-04-11File I/O file handles after target closesPedro Alves3-5/+40
A future patch will propose making the remote target's target_ops be heap-allocated (to make it possible to have multiple instances of remote targets, for multiple simultaneous connections), and will delete/destroy the remote target at target_close time. That change trips on a latent problem, though. File I/O handles remain open even after the target is gone, with a dangling pointer to a target that no longer exists. This results in GDB crashing when it calls the target_ops backend associated with the file handle: (gdb) Disconnect Ending remote debugging. * GDB crashes deferencing a dangling pointer Backtrace: #0 0x00007f79338570a0 in main_arena () at /lib64/libc.so.6 #1 0x0000000000858bfe in target_fileio_close(int, int*) (fd=1, target_errno=0x7ffe0499a4c8) at src/gdb/target.c:2980 #2 0x00000000007088bd in gdb_bfd_iovec_fileio_close(bfd*, void*) (abfd=0x1a631b0, stream=0x223c9d0) at src/gdb/gdb_bfd.c:353 #3 0x0000000000930906 in opncls_bclose (abfd=0x1a631b0) at src/bfd/opncls.c:528 #4 0x0000000000930cf9 in bfd_close_all_done (abfd=0x1a631b0) at src/bfd/opncls.c:768 #5 0x0000000000930cb3 in bfd_close (abfd=0x1a631b0) at src/bfd/opncls.c:735 #6 0x0000000000708dc5 in gdb_bfd_close_or_warn(bfd*) (abfd=0x1a631b0) at src/gdb/gdb_bfd.c:511 #7 0x00000000007091a2 in gdb_bfd_unref(bfd*) (abfd=0x1a631b0) at src/gdb/gdb_bfd.c:615 #8 0x000000000079ed8e in objfile::~objfile() (this=0x2154730, __in_chrg=<optimized out>) at src/gdb/objfiles.c:682 #9 0x000000000079fd1a in objfile_purge_solibs() () at src/gdb/objfiles.c:1065 #10 0x00000000008162ca in no_shared_libraries(char const*, int) (ignored=0x0, from_tty=1) at src/gdb/solib.c:1251 #11 0x000000000073b89b in disconnect_command(char const*, int) (args=0x0, from_tty=1) at src/gdb/infcmd.c:3035 This goes unnoticed in current master, because the current remote target's target_ops is never destroyed nowadays, so we end up calling: remote_hostio_close -> remote_hostio_send_command which gracefully fails with FILEIO_ENOSYS if remote_desc is NULL (because the target is closed). Fix this by invalidating a target's file I/O handles when the target is closed. With this change, remote_hostio_send_command no longer needs to handle the case of being called with a closed remote target, originally added here: <https://sourceware.org/ml/gdb-patches/2008-08/msg00359.html>. gdb/ChangeLog: 2018-04-11 Pedro Alves <palves@redhat.com> * target.c (fileio_fh_t::t): Add comment. (target_fileio_pwrite, target_fileio_pread, target_fileio_fstat) (target_fileio_close): Handle a NULL target. (invalidate_fileio_fh): New. (target_close): Call it. * remote.c (remote_hostio_send_command): No longer check whether remote_desc is open.
2018-04-11C++ify fileio_fh_t, replace VEC with std::vectorPedro Alves2-38/+56
Preparation for the next patch. - Replace VEC with std::vector. - Rewrite a couple macros as methods/functions. - While at it, rename fileio_fh_t::fd as fileio_fh_t::target_fd to avoid confusion between target and host file descriptors. gdb/ChangeLog: 2018-04-11 Pedro Alves <palves@redhat.com> * target.c (fileio_fh_t): Make it a named struct instead of a typedef. (fileio_fh_t::is_closed): New method. (DEF_VEC_O (fileio_fh_t)): Remove. (fileio_fhandles): Now a std::vector. (is_closed_fileio_fh): Delete. (acquire_fileio_fd): Adjust. Rename parameters. (release_fileio_fd): Adjust. (fileio_fd_to_fh): Reimplement as a function instead of a macro. (target_fileio_pwrite, target_fileio_pread, target_fileio_fstat) (target_fileio_close): Adjust.
2018-04-10Iterate by index in auto_load_safe_path_vec_updateSimon Marchi2-4/+8
As reported by Jan, we get this error when building with -D_GLIBCXX_DEBUG: /usr/include/c++/7/debug/safe_iterator.h:297: Error: attempt to increment a singular iterator. Objects involved in the operation: iterator "this" @ 0x0x7fffffffd140 { type = __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<std::unique_ptr<char, gdb::xfree_deleter<char> >*, std::__cxx1998::vector<std::unique_ptr<char, gdb::xfree_deleter<char> >, std::allocator<std::unique_ptr<char, gdb::xfree_deleter<char> > > > >, std::__debug::vector<std::unique_ptr<char, gdb::xfree_deleter<char> >, std::allocator<std::unique_ptr<char, gdb::xfree_deleter<char> > > > > (mutable iterator); state = singular; references sequence with type 'std::__debug::vector<std::unique_ptr<char, gdb::xfree_deleter<char> >, std::allocator<std::unique_ptr<char, gdb::xfree_deleter<char> > > >' @ 0x0x265db40 } The bug was introduced by commit commit e80aaf6183c6692ecc167bf26cbdc53f8f1a55f0 Author: Simon Marchi <simon.marchi@polymtl.ca> Date: Fri Mar 2 23:22:06 2018 -0500 Make delim_string_to_char_ptr_vec return an std::vector The problem is that we iterate using a range-based for on a vector to which we push in the loop. Pushing to the vector invalidates the iterator used in the loop. Instead, change the code to iterate by index as was done in the previous code. gdb/ChangeLog: * auto-load.c (auto_load_safe_path_vec_update): Iterate by index.
2018-04-10Fix gdb.base/fork-running-state.exp racePedro Alves2-16/+10
On my multi-target branch I was occasionaly seeing a FAIL like this: (gdb) PASS: gdb.base/fork-running-state.exp: detach-on-fork=off: follow-fork=parent: non-stop: kill parent [Inferior 2 (process 32672) exited normally] kill inferior 2 warning: Inferior ID 2 is not running. (gdb) FAIL: gdb.base/fork-running-state.exp: detach-on-fork=off: follow-fork=parent: non-stop: kill child (the program exited) ... other similar fails ... Turns out to be a testcase bug/race. A tweak like this increases the changes of hitting the race substancially: --- a/gdb/testsuite/gdb.base/fork-running-state.c +++ b/gdb/testsuite/gdb.base/fork-running-state.c @@ -29,7 +29,7 @@ fork_child (void) { while (1) { - sleep (1); + usleep (100); The testcase has two processes, parent and child fork. The problem is that the child exits itself if it notices the parent is gone, but the testcase .exp does not expect that. I first wrote a patch that handled the different combinations of non-stop/detach-on-fork/follow-fork/schedule-multiple, making the .exp file know when to expect the child to exit itself vs when to kill it explicitly, but the result was that the code to kill the parent and child was getting about as large as the test code that is the actual point of the testcase, above the kills. So I scratched that approach and came up with a simpler patch -- simply make the child not exit itself when the parent exits. The .exp file is going to kill both parent and child explicitly, and, main() already calls alarm() as a safeguard. I don't think we lose anything. gdb/testsuite/ChangeLog: 2018-04-10 Pedro Alves <palves@redhat.com> * gdb.base/fork-running-state.c (fork_child): Don't exit if parent exits. Instead loop running forever. (fork_parent): Run forever too.