This Linuxism has made its way into infrun.c, in the follow-fork code:
inferior_ptid = ptid_build (child_pid, child_pid, 0);
The OS-specific code should fill in the LWPID, TID parts with the
appropriate values, if any, and the core code should not be peeking at
the components of the ptids.
gdb/
2015-03-04 Pedro Alves <palves@redhat.com>
* infrun.c (follow_fork_inferior): Use the whole of the
inferior_ptid and pending_follow.related_pid ptids instead of
building ptids from the process components. Adjust verbose output
to use target_pid_to_str.
* linux-nat.c (linux_child_follow_fork): Use the whole of the
inferior_ptid and pending_follow.related_pid ptids instead of
building ptids from the process components.
These systems (OpenBSD and HP-UX 10.x) already support follow-fork
including the events needed to for "catch fork". This just makes
the upper layers realize this.
gdb/
2015-03-04 Mark Kettenis <kettenis@gnu.org>
* inf-ptrace.c [PT_GET_PROCESS_STATE]
(inf_ptrace_insert_fork_catchpoint): New function.
(inf_ptrace_remove_fork_catchpoint): New function.
(inf_ptrace_target) [PT_GET_PROCESS_STATE]: Install them.
When adding vector register support to GDB, s390_register_name() was
added to suppress the right halves of the first 16 vector registers.
However, that function returned NULL instead of an empty string in such
a case. This leads to an incomplete list of registers returned by
"complete info registers ", because completion stops at the first NULL
return value from user_reg_map_regnum_to_name().
gdb/ChangeLog:
* s390-linux-tdep.c (s390_register_name): Return empty string
instead of NULL for registers that shouldn't be visible.
On some targets each of the assignments "i = 0" in the C source for
"breakpoint-in-ro-region.exp" are compiled to a single instruction.
Then each "si" stops at the beginning of the next source line. But on
some other targets (like s390) such an assignment compiles to multiple
instructions. Then "si" may stop in mid-line, and GDB displays the PC
address in addition to the source line number. This was not considered
by the regexp for this case.
gdb/testsuite/ChangeLog:
* gdb.base/breakpoint-in-ro-region.exp (test_single_step): In the
regexps for GDB's current line display, accept a hex address
preceding the line number.
For the "multiple targets" test in catch-syscall.exp, set the 'arch1'
variable to a valid string.
gdb/testsuite/ChangeLog:
* gdb.base/catch-syscall.exp (test_catch_syscall_multi_arch): Set
the 'arch1' variable for "s390*-linux*" targets.
This patch fixes a typo that caused the wrong syscall XML file to be
used for s390x targets.
gdb/ChangeLog:
* s390-linux-tdep.c (s390_gdbarch_init): Use the correct syscall
XML file for 64-bit targets.
This fixes:
> gdb compile failed, /gdb/testsuite/gdb.threads/clone-thread_db.c: In function 'main':
> /gdb/testsuite/gdb.threads/clone-thread_db.c:67:3: warning: implicit declaration of function 'alarm' [-Wimplicit-function-declaration]
> alarm (300);
> ^
> /gdb/testsuite/gdb.threads/clone-thread_db.c:69:3: warning: implicit declaration of function 'pthread_create' [-Wimplicit-function-declaration]
> pthread_create (&child, NULL, thread_fn, NULL);
> ^
> /gdb/testsuite/gdb.threads/clone-thread_db.c:70:3: warning: implicit declaration of function 'pthread_join' [-Wimplicit-function-declaration]
> pthread_join (child);
> ^
And then adding the missing headers revealed the pthread_join call was
incorrect. This probably fixes the crash we see on ppc64be, e.g., at
https://sourceware.org/ml/gdb-testers/2015-q1/msg04415.html
the logs there show:
...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x3fffb7ff54a0 (LWP 9275)]
0x00003fffb7f3ce74 in .pthread_join () from /lib64/libpthread.so.0
(gdb) FAIL: gdb.threads/clone-thread_db.exp: continue to end
...
Tested on x86_64 Fedora 20.
gdb/testsuite/
2015-03-04 Pedro Alves <palves@redhat.com>
* gdb.threads/clone-thread_db.c: Include unistd.h and pthread.h.
(main): Pass missing retval argument to pthread_join call.
find_default_create_inferior and find_default_attach were removed in b3ccfe11.
gdb/ChangeLog:
* target.h (find_default_create_inferior): Remove declaration.
(find_default_attach): Likewise.
In this case, we want to resume the entire process and not an
individual thread.
gdb/
2015-03-03 Pedro Alves <palves@redhat.com>
* inf-ptrace.c (inf_ptrace_resume): Remove spurious whitespace.
Use ptid_get_pid to get the overall process id when resuming all
threads.
Ref: https://sourceware.org/ml/gdb-patches/2015-03/msg00060.html
The record-btrace target can hit an assertion here:
Breakpoint 1, record_btrace_fetch_registers (ops=0x974bfc0 <record_btrace_ops>,
regcache=0x9a0a798, regno=8) at gdb/record-btrace.c:1202
1202 gdb_assert (tp != NULL);
(gdb) p regcache->ptid
$3 = {pid = 23856, lwp = 0, tid = 0}
The problem is that the linux-nat layer converts the ptid to a
single-process ptid before passing the request down to the inf-ptrace
layer, which loses information, and then record-btrace can't find the
corresponding thread in GDB's thread list:
(gdb) bt
#0 record_btrace_fetch_registers (ops=0x974bfc0 <record_btrace_ops>, regcache=0x9a0a798, regno=8)
at gdb/record-btrace.c:1202
#1 0x083f4ee2 in delegate_fetch_registers (self=0x974bfc0 <record_btrace_ops>, arg1=0x9a0a798,
arg2=8) at gdb/target-delegates.c:149
#2 0x08406562 in target_fetch_registers (regcache=0x9a0a798, regno=8)
at gdb/target.c:3279
#3 0x08355255 in regcache_raw_read (regcache=0x9a0a798, regnum=8,
buf=0xbfffe6c0 "¨\003\222\tÀ8kIøæÿ¿HO5\b\035]")
at gdb/regcache.c:643
#4 0x083558a7 in regcache_cooked_read (regcache=0x9a0a798, regnum=8,
buf=0xbfffe6c0 "¨\003\222\tÀ8kIøæÿ¿HO5\b\035]")
at gdb/regcache.c:734
#5 0x08355de3 in regcache_cooked_read_unsigned (regcache=0x9a0a798, regnum=8, val=0xbfffe738)
at gdb/regcache.c:838
#6 0x0827a106 in i386_linux_resume (ops=0x9737ca0 <linux_ops_saved>, ptid=..., step=1,
signal=GDB_SIGNAL_0) at gdb/i386-linux-nat.c:670
#7 0x08280c12 in linux_resume_one_lwp (lp=0x9a0a5b8, step=1, signo=GDB_SIGNAL_0)
at gdb/linux-nat.c:1529
#8 0x08281281 in linux_nat_resume (ops=0x98da608, ptid=..., step=1, signo=GDB_SIGNAL_0)
at gdb/linux-nat.c:1708
#9 0x0850738e in record_btrace_resume (ops=0x98da608, ptid=..., step=1, signal=GDB_SIGNAL_0)
at gdb/record-btrace.c:1760
...
The fix is just to not lose information, and let the intact ptid reach
record-btrace.c.
Tested on x86-64 Fedora 20, -m32.
gdb/ChangeLog:
2015-03-03 Pedro Alves <palves@redhat.com>
* i386-linux-nat.c (i386_linux_resume): Get the ptrace PID out of
the lwp field of ptid. Pass the full ptid to get_thread_regcache.
* inf-ptrace.c (get_ptrace_pid): New function.
(inf_ptrace_resume): Use it.
* linux-nat.c (linux_resume_one_lwp): Pass the LWP's ptid ummodified
to the lower layer.
The heuristic for filtering out kernel addressess in BTS trace checks the
most significant bit in each address. This works fine for 32-bit and 64-bit
mode.
For 32-bit compatibility mode, i.e. a 32-bit inferior running on 64-bit
host, we need to check bit 63 (or any bit bigger than 31), not bit 31.
Use the machine field in struct utsname provided by a uname call to
determine whether we are running on a 64-bit host.
Thanks to Jan Kratochvil for reporting the issue.
gdb/
* nat/linux-btrace.c: Include sys/utsname.h.
(linux_determine_kernel_ptr_bits): New.
(linux_enable_bts): Call linux_determine_kernel_ptr_bits.
* x86-linux-nat.c (x86_linux_enable_btrace): Do not overwrite non-zero
ptr_bits.
gdbserver/
* linux-low.c (linux_low_enable_btrace): Do not overwrite non-zero
ptr_bits.
On some systems, _dl_runtime_resolve returns to the resolved function
instead of jumping to it. Since btrace will not find the function in
the current stack back trace, it will start a new back trace on the
same level. It will look the same to the user via the backtrace
command but the frames will have different id's which confuses stepping.
This fixes a test fail with 32-bit inferior reported by Jan Kratochvil.
gdb/
* btrace.c (ftrace_update_function): Treat return as tailcall for
"_dl_runtime_resolve".
The "record function-call-history" command prints the range of source lines
for a function segment when given the /l modifier. This information is
computed for the entire execution history when processing the recorded branch
trace.
To speed up the initial trace processing, we compute the information when
we print a function segment and only if requested. The computation is fast
enough (due to the limited scope) that it is not worth storing the data in
struct btrace_function, anymore.
gdb/
* btrace.h (btrace_function) <lbegin, lend>: Remove.
* btrace.c (ftrace_debug): Do not print the line range.
(ftrace_skip_file, ftrace_update_lines): Remove.
(ftrace_new_function): Remove lbegin and lend initialization.
(btrace_compute_ftrace_bts): Remove call to ftrace_update_lines.
* record-btrace.c (btrace_compute_src_line_range): New.
(btrace_call_history_src_line): Call btrace_compute_src_line_range.
This fixes invalid reads Valgrind first caught when debugging against
a GDBserver patched with a series that adds exec events to the remote
protocol. Like these, using the gdb.threads/thread-execl.exp test:
$ valgrind ./gdb -data-directory=data-directory ./testsuite/gdb.threads/thread-execl -ex "tar extended-remote :9999" -ex "b thread_execler" -ex "c" -ex "set scheduler-locking on"
...
Breakpoint 1, thread_execler (arg=0x0) at src/gdb/testsuite/gdb.threads/thread-execl.c:29
29 if (execl (image, image, NULL) == -1)
(gdb) n
Thread 32509.32509 is executing new program: build/gdb/testsuite/gdb.threads/thread-execl
[New Thread 32509.32532]
==32510== Invalid read of size 4
==32510== at 0x5AA7D8: delete_breakpoint (breakpoint.c:13989)
==32510== by 0x6285D3: delete_thread_breakpoint (thread.c:100)
==32510== by 0x628603: delete_step_resume_breakpoint (thread.c:109)
==32510== by 0x61622B: delete_thread_infrun_breakpoints (infrun.c:2928)
==32510== by 0x6162EF: for_each_just_stopped_thread (infrun.c:2958)
==32510== by 0x616311: delete_just_stopped_threads_infrun_breakpoints (infrun.c:2969)
==32510== by 0x616C96: fetch_inferior_event (infrun.c:3267)
==32510== by 0x63A2DE: inferior_event_handler (inf-loop.c:57)
==32510== by 0x4E0E56: remote_async_serial_handler (remote.c:11877)
==32510== by 0x4AF620: run_async_handler_and_reschedule (ser-base.c:137)
==32510== by 0x4AF6F0: fd_event (ser-base.c:182)
==32510== by 0x63806D: handle_file_event (event-loop.c:762)
==32510== Address 0xcf333e0 is 16 bytes inside a block of size 200 free'd
==32510== at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32510== by 0x77CB74: xfree (common-utils.c:98)
==32510== by 0x5AA954: delete_breakpoint (breakpoint.c:14056)
==32510== by 0x5988BD: update_breakpoints_after_exec (breakpoint.c:3765)
==32510== by 0x61360F: follow_exec (infrun.c:1091)
==32510== by 0x6186FA: handle_inferior_event (infrun.c:4061)
==32510== by 0x616C55: fetch_inferior_event (infrun.c:3261)
==32510== by 0x63A2DE: inferior_event_handler (inf-loop.c:57)
==32510== by 0x4E0E56: remote_async_serial_handler (remote.c:11877)
==32510== by 0x4AF620: run_async_handler_and_reschedule (ser-base.c:137)
==32510== by 0x4AF6F0: fd_event (ser-base.c:182)
==32510== by 0x63806D: handle_file_event (event-loop.c:762)
==32510==
[Switching to Thread 32509.32532]
Breakpoint 1, thread_execler (arg=0x0) at src/gdb/testsuite/gdb.threads/thread-execl.c:29
29 if (execl (image, image, NULL) == -1)
(gdb)
The breakpoint in question is the step-resume breakpoint of the
non-main thread, the one that was "next"ed.
The exact same issue can be seen on mainline with native debugging, by
running the thread-execl.exp test in non-stop mode, because the kernel
doesn't report a thread exit event for the execing thread.
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-03-02 Pedro Alves <palves@redhat.com>
* infrun.c (follow_exec): Delete all threads of the process except
the event thread. Extended comments.
gdb/testsuite/ChangeLog:
2015-03-02 Pedro Alves <palves@redhat.com>
* gdb.threads/thread-execl.exp (do_test): Handle non-stop.
(top level): Call do_test with non-stop as well.
gdb_test_multiple is supposed to return -1 on internal error:
# Returns:
# 1 if the test failed, according to a built-in failure pattern
# 0 if only user-supplied patterns matched
# -1 if there was an internal error.
But alas, that's broken, it returns success... It looks like the code
is assuming an earlier 'set result -1' is still in effect, but
'result' is set to 0 at the end, just before we call gdb_expect:
set result 0
set code [catch {gdb_expect $code} string]
gdb/testsuite/
2015-03-02 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_test_multiple) <internal error>: Set result to
-1.
As we cannot use type bool until conversion to C++ is official,
this patch re-instates the ARI checks for "true/false".
gdb/ChangeLog:
* contrib/ari/gdb_ari.sh: Reinstate checks for "true" and "false".
Using type bool from stdbool unfortunately causes problems trying
to build GDB on AiX and Solaris:
In file included from ../../src/gdb/utils.h:24:0,
from ../../src/gdb/defs.h:707,
from ../../src/gdb/utils.c:20:
/[...]/curses.h:96:14: error: two or more data types in declaration
specifiers
typedef char bool;
^
make[2]: *** [utils.o] Error 1
In theory, the problem is in curses.h which, in both cases, do
something similar. On Solaris:
#if !defined(__cplusplus) && !defined(_BOOL)
typedef char bool;
#endif /* !defined(__cplusplus) && !defined(_BOOL) */
On AiX:
#if !defined(__cplusplus) || (defined(__IBMCPP__) &&(__IBMCPP__<400))
#ifndef _BOOL
#define _BOOL
typedef int bool;
#endif
#endif
You can reproduce the same problem by trying to compile:
% cat toto.c
#include <stdbool.h>
#include <curses.h>
% gcc -c toto.c
In file included from toto.c:1:0:
/[...]/curses.h:159:13: error: two or more data types in declaration
specifiers
typedef int bool;
^
This specific issue wouldn't occur if we included curses.h before
including stdbool.h, and I looked at that just to be complete.
Here is a small schematic representation of the include logic:
* utils.c:
-> defs.h -> utils.h -> stdbool.h
-> gdb_curses.h -> curses.h
Because defs.h should always be first on the list, it means that
stdbool.h will always necessarily be included ahead of curses.h.
But, thinking beyond this very specific issue, it shows that using
stdbool.h is going to cause problems on these systems until either
GCC fixes those includes in a way that makes them work; or we switch
to C++.
In the meantime, I think the path of least resistance is to revert
the use of stdbool.h, and use integers, the way we've done up until
now. The benefits of using type "bool" are modest, IMO, so not
a great loss, and a temporary one.
gdb/ChangeLog:
* utils.h: Remove <stdbool.h> #include.
(producer_is_gcc): Change return type to "int".
* utils.c (producer_is_gcc): Change return type to int.
Return 1 instead of true, and 0 instead of false.
Adjust function documentation accordingly.
On S/390 targets with vector registers, enable gdbserver to advertise
and handle the feature "org.gnu.gdb.s390.vx".
gdb/gdbserver/ChangeLog:
* Makefile.in (s390-vx-linux64.c, s390-tevx-linux64.c)
(s390x-vx-linux64.c, s390x-tevx-linux64.c): New rules.
(clean): Add "rm -f" for above C files.
* configure.srv (srv_regobj): Add s390-vx-linux64.o,
s390-tevx-linux64.o, s390x-vx-linux64.o, and s390x-tevx-linux64.o.
(srv_xmlfiles): Add s390-vx-linux64.xml, s390-tevx-linux64.xml,
s390x-vx-linux64.xml, s390x-tevx-linux64.xml, and s390-vx.xml.
* linux-s390-low.c (HWCAP_S390_VX): New macro.
(init_registers_s390_vx_linux64, init_registers_s390_tevx_linux64)
(init_registers_s390x_vx_linux64)
(init_registers_s390x_tevx_linux64)
(tdesc_s390_vx_linux64, tdesc_s390_tevx_linux64)
(tdesc_s390x_vx_linux64, tdesc_s390x_tevx_linux64): New extern
declarations.
(s390_fill_vxrs_low, s390_store_vxrs_low, s390_fill_vxrs_high)
(s390_store_vxrs_high): New functions.
(s390_regsets): Add entries for NT_S390_VXRS_LOW and
NT_S390_VXRS_HIGH.
(s390_arch_setup): Add logic for selecting one of the new target
descriptions. Activate the new vector regsets if applicable.
(initialize_low_arch): Also invoke init_registers_s390_vx_linux64,
init_registers_s390_tevx_linux64, init_registers_s390x_vx_linux64,
and init_registers_s390x_tevx_linux64.
Recognize S/390 targets with the new vector feature and present their
vector registers appropriately: as 32 new 128-bit wide registers
v0-v31, where the first 16 embed the floating point registers f0-f15.
Each of the full registers v0-v15 is modelled as a pseudo register.
gdb/ChangeLog:
* s390-linux-nat.c (have_regset_vxrs): New static variable.
(s390_linux_fetch_inferior_registers): Handle vector registers, if
present.
(s390_linux_store_inferior_registers): Likewise.
(s390_get_hwcap): Remove function. Embed its logic...
(s390_read_description): ...here. Yield a target description with
vector registers if applicable.
* s390-linux-tdep.c: Include "features/s390-vx-linux64.c",
"features/s390-tevx-linux64.c", "features/s390x-vx-linux64.c", and
"features/s390x-tevx-linux64.c".
(struct gdbarch_tdep) <v0_full_regnum>: New field.
(s390_dwarf_regmap): Add vector registers. Remove bogus entries
for "GNU/Linux-specific registers".
(s390_dwarf_reg_r0l): New enum value.
(s390_dwarf_reg_to_regnum): Support vector registers.
(s390_adjust_frame_regnum): Adjust pseudo DWARF register numbers
of GPR lower halves.
(regnum_is_vxr_full): New function.
(s390_register_name): New function.
(s390_pseudo_register_name): Handle v0-v15, which are composed of
f0-f15 and v0l-v15l.
(s390_pseudo_register_type): Likewise.
(s390_pseudo_register_read): Likewise.
(s390_pseudo_register_write): Likewise.
(s390_value_from_register): Account for the fact that values are
placed left-justified in vector registers.
(s390_pseudo_register_reggroup_p): Add pseudo registers v0-v15 to
the vector reggroup and omit them from the general reggroup.
(s390_regmap_vxrs_low, s390_regmap_vxrs_high): New register maps.
(s390_vxrs_low_regset, s390_vxrs_high_regset): New regsets.
(s390_iterate_over_regset_sections): Add iterations for the two
new vector regsets.
(s390_core_read_description): Yield a target description with
vector registers if applicable.
(s390_gdbarch_init): Handle target descriptions with vector
registers. Add "register_name" gdbarch method.
(_initialize_s390_tdep): Call new tdesc initialization functions.
* s390-linux-tdep.h (HWCAP_S390_VX): New macro.
(S390_V0_LOWER_REGNUM, S390_V1_LOWER_REGNUM, S390_V2_LOWER_REGNUM)
(S390_V3_LOWER_REGNUM, S390_V4_LOWER_REGNUM, S390_V5_LOWER_REGNUM)
(S390_V6_LOWER_REGNUM, S390_V7_LOWER_REGNUM, S390_V8_LOWER_REGNUM)
(S390_V9_LOWER_REGNUM, S390_V10_LOWER_REGNUM)
(S390_V11_LOWER_REGNUM, S390_V12_LOWER_REGNUM)
(S390_V13_LOWER_REGNUM, S390_V14_LOWER_REGNUM)
(S390_V15_LOWER_REGNUM, S390_V16_REGNUM, S390_V17_REGNUM)
(S390_V18_REGNUM, S390_V19_REGNUM, S390_V20_REGNUM)
(S390_V21_REGNUM, S390_V22_REGNUM, S390_V23_REGNUM)
(S390_V24_REGNUM, S390_V25_REGNUM, S390_V26_REGNUM)
(S390_V27_REGNUM, S390_V28_REGNUM, S390_V29_REGNUM)
(S390_V30_REGNUM, S390_V31_REGNUM): New macros.
(S390_NUM_REGS): Adjust value.
(s390_vxrs_low_regset, s390_vxrs_high_regset): Declare.
(tdesc_s390_vx_linux64, tdesc_s390_tevx_linux64)
(tdesc_s390x_vx_linux64, tdesc_s390x_tevx_linux64): Likewise.
* NEWS: Announce S/390 vector register support.
The IBM z13 has new vector registers v0-v31 which are presented by the
Linux kernel as two additional register sets. This patch adds XML
descriptions and the respective autogenerated .c and .dat files for
S390 targets with this feature. Note that supported combinations
include targets with and without a transactional execution facility.
gdb/ChangeLog:
* features/s390-tevx-linux64.xml: New file.
* features/s390-vx-linux64.xml: New file.
* features/s390-vx.xml: New file.
* features/s390x-tevx-linux64.xml: New file.
* features/s390x-vx-linux64.xml: New file.
* features/Makefile (WHICH): Add s390-vx-linux64,
s390x-vx-linux64, s390-tevx-linux64, and s390x-tevx-linux64.
(s390-vx-linux64-expedite, s390-tevx-linux64-expedite)
(s390x-vx-linux64-expedite, s390x-tevx-linux64-expedite): New
macros.
* features/s390-tevx-linux64.c: New generated file.
* features/s390-vx-linux64.c: Likewise.
* features/s390x-tevx-linux64.c: Likewise.
* features/s390x-vx-linux64.c: Likewise.
* regformats/s390-tevx-linux64.dat: Likewise.
* regformats/s390-vx-linux64.dat: Likewise.
* regformats/s390x-tevx-linux64.dat: Likewise.
* regformats/s390x-vx-linux64.dat: Likewise.
gdb/doc/ChangeLog:
* gdb.texinfo (S/390 and System z Features): Describe new feature
"org.gnu.gdb.s390.vx".
Git commit 3c14e5a39b added a declaration for
gdb_agent_get_raw_reg to tracepoint.h, and this now caught that the
32-bit x86 implementation has the wrong prototype:
../../../src/gdb/gdbserver/linux-i386-ipa.c:103:1: error: conflicting types for ‘gdb_agent_get_raw_reg’
gdb_agent_get_raw_reg (unsigned char *raw_regs, int regnum)
^
In file included from ../../../src/gdb/gdbserver/linux-i386-ipa.c:24:0:
../../../src/gdb/gdbserver/tracepoint.h:168:31: note: previous declaration of ‘gdb_agent_get_raw_reg’ was here
IP_AGENT_EXPORT_FUNC ULONGEST gdb_agent_get_raw_reg
^
make[2]: *** [linux-i386-ipa.o] Error 1
gdb/gdbserver/
2015-03-01 Pedro Alves <palves@redhat.com>
* linux-i386-ipa.c (gdb_agent_get_raw_reg): Constify 'raw_regs'
parameter.
In C++, we can't forward declare objects like in C. The compiler
complains about symbol redefinition. Most cases of this were fixed in
e36122e9, but dtrace probes introduced a new one meanwhile. This
patch fixes it the same way e36122e9 fixed the others.
gdb/
2015-02-27 Pedro Alves <palves@redhat.com>
* dtrace-probe.c (dtrace_probe_ops): Make extern.
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* common/common-exceptions.h (exception_none): Declare.
* common/common-exceptions.c (exception_none): Moved from
exceptions.c.
(exceptions_state_mc_init): Use exception_none.
* exceptions.c (exception_none): Move to
common/common-exceptions.c.
* exceptions.h (exception_none): Move to
common/common-exceptions.h.
gdb/testsuite/
2015-02-27 Pedro Alves <palves@redhat.com>
* gdb.gdb/complaints.exp (test_initial_complaints): Also accept
"true" for boolean result.
* gdb.gdb/selftest.exp (test_with_self): Also accept full
prototype of main.
Fixes this in C++ mode:
src/gdb/python/python-internal.h: At global scope:
src/gdb/python/python-internal.h:313:13: error: use of enum ‘ext_lang_rc’ without previous declaration
extern enum ext_lang_rc gdbpy_apply_val_pretty_printer
^
src/gdb/python/python-internal.h:320:41: error: invalid type in declaration before ‘;’ token
const struct language_defn *language);
^
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* python/python-internal.h: Include "extension-priv.h".
Building GDB in C++, we get:
src/gdb/breakpoint.h:529:8: error: use of enum ‘print_stop_action’ without previous declaration
We can't forward declare enums in C++.
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* breakpoint.h (enum print_stop_action): Move further up in the
file.
Building GDB in C++ mode, I got:
src/gdb/gdbarch.h:240:149: error: invalid type in declaration before ‘;’ token
src/gdb/gdbarch.h:240:14: error: use of enum ‘register_status’ without previous declaration
src/gdb/gdbarch.h:241:13: error: use of enum ‘register_status’ without previous declaration
src/gdb/gdbarch.h:241:140: error: invalid type in declaration before ‘;’ token
That's because 'enum register_status' has not been declared (and we can't
forward declare enums in C++).
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* gdbarch.sh: Include regcache.h.
* gdbarch.h: Regenerate.
const works different in C vs C++. In C++, a global "const" variable
has internal linkage by default, resulting in link errors like:
...
extension.o: In function `get_ext_lang_defn(extension_language)':
gdb/extension.c:126: undefined reference to `extension_language_guile'
gdb/extension.c:124: undefined reference to `extension_language_guile'
...
The fix is to define exported const objects with "extern const". But
that in C would not be a definition. So we need to #ifdef C vs C++ in
this case.
EXPORTED_CONST comes from include/ansidecl.h, but in the
feature_to_c.sh case I think it's better to leave the script with no
dependencies.
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* cp-valprint.c (vtbl_ptr_name): Use EXPORTED_CONST.
* guile/guile.c (extension_language_guile): Use EXPORTED_CONST.
* features/feature_to_c.sh: Tag the generated xml_builtin array
with extern const in C++ mode.
/home/pedro/gdb/mygit/src/gdb/minidebug.c: At global scope:
/home/pedro/gdb/mygit/src/gdb/minidebug.c:55:8: error: using typedef-name ‘lzma_stream’ after ‘struct’
struct lzma_stream
^
In file included from /usr/include/lzma.h:281:0,
from /home/pedro/gdb/mygit/src/gdb/minidebug.c:28:
/usr/include/lzma/base.h:498:3: note: ‘lzma_stream’ has a previous declaration here
} lzma_stream;
^
gdb/ChangeLog:
2015-02-27 Tom Tromey <tromey@redhat.com>
* minidebug.c (struct lzma_stream): Rename to ...
(struct gdb_lzma_stream): ... this.
(lzma_open, lzma_pread, lzma_close, lzma_stat): Adjust.
The enums are value compatible by design, but building in C++ mode trips
on them, like:
...
gdb/mi/mi-cmd-stack.c:363:34: error: cannot convert ‘print_values’ to ‘ext_lang_frame_args’ for argument ‘3’ to ‘ext_lang_bt_status apply_ext_lang_frame_filter(frame_info*, int, ext_lang_frame_args, ui_out*, int, int)’
...
Fix this by adding a helper function.
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* mi/mi-cmd-stack.c (mi_apply_ext_lang_frame_filter): New
function.
(mi_cmd_stack_list_locals, mi_cmd_stack_list_args)
(mi_cmd_stack_list_variables): Use it.
In C++ mode, we get:
gdb/gdbserver/linux-x86-low.c: In function ‘void x86_linux_dr_set(ptid_t, int, long unsigned int)’:
gdb/gdbserver/linux-x86-low.c:558:38: error: ‘regnum’ cannot appear in a constant-expression
offsetof (struct user, u_debugreg[regnum]), value);
^
gdb/gdbserver/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* linux-x86-low.c (u_debugreg_offset): New function.
(x86_linux_dr_get, x86_linux_dr_set): Use it.
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* x86-linux-nat.c (u_debugreg_offset): New function.
(x86_linux_dr_get, x86_linux_dr_set): Use it.
Can't do that in C++.
2015-02-27 Pedro Alves <palves@redhat.com>
* nat/x86-dregs.h (enum target_hw_bp_type): Remove forward
declaration.
Include break-common.h.
In C++, we can't do arithmetic on enums. This patch fixes build errors like:
src/gdb/i386-tdep.c: In function ‘int i386_stap_parse_special_token(gdbarch*, stap_parse_info*)’:
src/gdb/i386-tdep.c:4309:7: error: no match for ‘operator++’ (operand type is ‘i386_stap_parse_special_token(gdbarch*, stap_parse_info*)::<anonymous enum>’)
++current_state;
^
...
src/gdb/rs6000-tdep.c:4265:18: error: no match for ‘operator++’ (operand type is ‘powerpc_vector_abi’)
src/gdb/arm-tdep.c:9428:71: error: no match for ‘operator++’ (operand type is ‘arm_float_model’)
src/gdb/arm-tdep.c:9465:64: error: no match for ‘operator++’ (operand type is ‘arm_abi_kind’)
...
gdb/ChangeLog:
2015-02-27 Tom Tromey <tromey@redhat.com>
Pedro Alves <palves@redhat.com>
* arm-tdep.c (set_fp_model_sfunc, arm_set_abi): Use 'int' for
local used to iterate over enums.
* completer.c (signal_completer): Likewise.
* i386-tdep.c (i386_stap_parse_special_token): Likewise.
* rs6000-tdep.c (powerpc_set_vector_abi): Likewise.
* tui/tui-data.c (tui_next_win, tui_prev_win): Likewise.
* tui/tui-layout.c (next_layout, prev_layout): Likewise.
* tui/tui-win.c (tui_refresh_all_win, tui_rehighlight_all)
(tui_resize_all, tui_set_focus_command, tui_all_windows_info): Likewise.
* tui-wingeneral.c (tui_refresh_all): Likewise.
Fixes:
src/gdb/target.h:753:10: error: use of enum ‘exec_direction_kind’ without previous declaration
in C++ mode. We can't forward declare enums.
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* target.h: Include "infrun.h".
libthread_db.so calls symbols in the client (GDB), through the
proc-service interface. These routines must have extern "C" linkage
so their symbol names are not mangled when GDB is built as a C++
program. On the GDBserver side, we were missing fallback declarations for
all these symbols.
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* gdb_proc_service.h: Wrap with EXTERN_C_PUSH/EXTERN_C_POP.
gdb/gdbserver/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* gdb_proc_service.h: Wrap with EXTERN_C_PUSH/EXTERN_C_POP.
[!HAVE_PROC_SERVICE_H] (struct ps_prochandle): Forward declare.
[!HAVE_PROC_SERVICE_H] (ps_pdread, ps_pdwrite, ps_ptread)
ps_ptwrite, ps_lgetregs, ps_lsetregs, ps_lgetfpregs)
(ps_lsetfpregs, ps_getpid)
(ps_get_thread_area, ps_pglobal_lookup, ps_pstop, ps_pcontinue)
(ps_lstop, ps_lcontinue, ps_lgetxregsize, ps_lgetxregs)
(ps_lsetxregs, ps_plog): Declare.
Functions and variables that are exported by the IPA DSO (that
GDBserver needs to look up) should have "C" mangling, thus be declared
with extern "C".
Function and variable declarations need the extern "C" marker, but
variable definitions can't be marked extern, so the patch splits
IP_AGENT_EXPORT into three.
Building in C++ mode revealed that a few variables were missing
IP_AGENT_EXPORT, thus the IPA has been broken when stripped, even in C
mode... So this ends being a bug fix as well.
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* common/agent.h (IPA_SYM_EXPORTED_NAME): New.
(IPA_SYM): Use it.
* common/common-defs.h (EXTERN_C_PUSH, EXTERN_C_POP): New macros.
gdb/gdbserver/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* linux-amd64-ipa.c (gdb_agent_get_raw_reg): Use
IP_AGENT_EXPORT_FUNC.
* linux-i386-ipa.c (gdb_agent_get_raw_reg): Use
IP_AGENT_EXPORT_FUNC.
* tracepoint.c (ATTR_USED, ATTR_NOINLINE, ATTR_CONSTRUCTOR)
(IP_AGENT_EXPORT): Delete.
(gdb_tp_heap_buffer, gdb_jump_pad_buffer, gdb_jump_pad_buffer_end)
(gdb_trampoline_buffer, gdb_trampoline_buffer_end)
(gdb_trampoline_buffer_error, collecting, gdb_collect)
(stop_tracing, flush_trace_buffer, about_to_request_buffer_space)
(trace_buffer_is_full, stopping_tracepoint, expr_eval_result)
(error_tracepoint, tracepoints, tracing, trace_buffer_ctrl)
(trace_buffer_ctrl_curr, trace_buffer_lo, trace_buffer_hi)
(traceframe_read_count, traceframe_write_count)
(traceframes_created, trace_state_variables, get_raw_reg)
(get_trace_state_variable_value, set_trace_state_variable_value)
(ust_loaded, helper_thread_id, cmd_buf): Use
IPA_SYM_EXPORTED_NAME.
(stop_tracing, flush_trace_buffer): Use IP_AGENT_EXPORT_FUNC.
(tracepoints) Use IP_AGENT_EXPORT_VAR.
(stopping_tracepoint, trace_buffer_is_full, expr_eval_result): Use
IP_AGENT_EXPORT_VAR and wrap in EXTERN_C_PUSH/EXTERN_C_POP.
(last_tracepoint): Move into !IN_PROCESS_AGENT block.
(error_tracepoint): Use IP_AGENT_EXPORT_VAR and wrap in
EXTERN_C_PUSH/EXTERN_C_POP.
(trace_state_variables): Use IP_AGENT_EXPORT_VAR.
(trace_buffer_lo, trace_buffer_hi): Use IP_AGENT_EXPORT_VAR and
wrap in EXTERN_C_PUSH/EXTERN_C_POP.
(trace_buffer_ctrl, trace_buffer_ctrl_curr)
(traceframe_write_count, traceframe_read_count)
(traceframes_created, tracing): Use IP_AGENT_EXPORT_VAR.
(about_to_request_buffer_space, get_trace_state_variable_value)
(set_trace_state_variable_value): Use IP_AGENT_EXPORT_FUNC.
(collecting): Use IP_AGENT_EXPORT_VAR and wrap in
EXTERN_C_PUSH/EXTERN_C_POP.
(gdb_collect): Use IP_AGENT_EXPORT_FUNC.
(ust_loaded, cmd_buf): Use IP_AGENT_EXPORT_VAR.
(helper_thread_id, gdb_agent_capability): Use IP_AGENT_EXPORT_VAR
and wrap in EXTERN_C_PUSH/EXTERN_C_POP.
(gdb_tp_heap_buffer, gdb_jump_pad_buffer, gdb_jump_pad_buffer_end)
(gdb_trampoline_buffer, gdb_trampoline_buffer_end)
(gdb_trampoline_buffer_error): Use IP_AGENT_EXPORT_VAR.
* tracepoint.h (ATTR_USED, ATTR_NOINLINE, EXPORTED_SYMBOL):
Define.
(IP_AGENT_EXPORT_FUNC, IP_AGENT_EXPORT_VAR)
(IP_AGENT_EXPORT_VAR_DECL): Define.
(tracing): Declare.
(gdb_agent_get_raw_reg): Declare.
These symbols are defined in C code, so in C++ mode we need to use
extern "C" to declare them. As extern "C" can't be used inside a
function's scope, we move the declarations to the global scope at the
same time.
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* cli-out.c (_rl_erase_entire_line): Move declaration out of
cli_mld_erase_entire_line, and make it extern "C".
* common/common-defs.h (EXTERN_C): New.
* completer.c (_rl_completion_prefix_display_length)
(_rl_print_completions_horizontally, QSFUNC): Move declarations
out of gdb_display_match_list_1.
(_rl_qsort_string_compare): Move declaration out of
gdb_display_match_list_1, and make it extern "C".
* defs.h (re_comp): Use EXTERN_C.
* maint.c (_mcleanup): Move declaration out of mcleanup_wrapper,
and make it extern "C".
(monstartup): Move declaration out of maintenance_set_profile_cmd,
and make it extern "C".
(main): Move declaration out of maintenance_set_profile_cmd.
* nat/linux-ptrace.c (linux_ptrace_attach_fail_reason_string): Use
EXTERN_C.
Compiling python.c in C++ mode, we get:
...src/gdb/python/python.c: At global scope:
...src/gdb/python/python.c:106:31: error: storage size of ‘GdbMethods’ isn’t known
static PyMethodDef GdbMethods[];
^
Fix it by making the affected array objects extern.
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* python/python.c (GdbMethods): Rename to ...
(python_GdbMethods): ... this and make extern.
(GdbModuleDef): Rename to ...
(python_GdbModuleDef): ... this and make extern.
The set_record_btrace_cmdlist and show_record_btrace_cmdlist objects
are declared twice in the file, seemingly a simply copy/paste
oversight. In C, the first time counts as forward declaration, but in
C++, they are all definitions. That results in:
src/gdb/record-btrace.c:80:33: error: redefinition of ‘cmd_list_element* set_record_btrace_cmdlist’
src/gdb/record-btrace.c:61:33: error: ‘cmd_list_element* set_record_btrace_cmdlist’ previously declared here
src/gdb/record-btrace.c:81:33: error: redefinition of ‘cmd_list_element* show_record_btrace_cmdlist’
src/gdb/record-btrace.c:62:33: error: ‘cmd_list_element* show_record_btrace_cmdlist’ previously declared here
gdb/ChangeLog:
2015-02-27 Pedro Alves <palves@redhat.com>
* record-btrace.c (set_record_btrace_cmdlist)
(show_record_btrace_cmdlist): Remove redefinitions.
---
gdb/record-btrace.c | 4 ----
1 file changed, 4 deletions(-)
