import gdb-1999-11-08 snapshot
[deliverable/binutils-gdb.git] / gdb / config / pa / nm-hppah.h
CommitLineData
c906108c
SS
1/* Native support for HPPA-RISC machine running HPUX, for GDB.
2 Copyright 1991, 1992 Free Software Foundation, Inc.
3
c5aa993b 4 This file is part of GDB.
c906108c 5
c5aa993b
JM
6 This program is free software; you can redistribute it and/or modify
7 it under the terms of the GNU General Public License as published by
8 the Free Software Foundation; either version 2 of the License, or
9 (at your option) any later version.
c906108c 10
c5aa993b
JM
11 This program is distributed in the hope that it will be useful,
12 but WITHOUT ANY WARRANTY; without even the implied warranty of
13 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
14 GNU General Public License for more details.
c906108c 15
c5aa993b
JM
16 You should have received a copy of the GNU General Public License
17 along with this program; if not, write to the Free Software
18 Foundation, Inc., 59 Temple Place - Suite 330,
19 Boston, MA 02111-1307, USA. */
c906108c
SS
20
21#define U_REGS_OFFSET 0
22
23#define KERNEL_U_ADDR 0
24
25/* What a coincidence! */
26#define REGISTER_U_ADDR(addr, blockend, regno) \
27{ addr = (int)(blockend) + REGISTER_BYTE (regno);}
28
a0b3c4fd
JM
29/* This isn't really correct, because ptrace is actually a 32-bit
30 interface. However, the modern HP-UX targets all really use
31 ttrace, which is a 64-bit interface --- a debugger running in
32 either 32- or 64-bit mode can debug a 64-bit process. BUT, the
33 code doesn't use ttrace directly --- it calls call_ptrace instead,
34 which is supposed to be drop-in substitute for ptrace. In other
35 words, they access a 64-bit system call (ttrace) through a
36 compatibility layer which is allegedly a 32-bit interface.
37
38 So I don't feel the least bit guilty about this. */
39#define PTRACE_ARG3_TYPE CORE_ADDR
40
c906108c
SS
41/* HPUX 8.0, in its infinite wisdom, has chosen to prototype ptrace
42 with five arguments, so programs written for normal ptrace lose. */
43#define FIVE_ARG_PTRACE
44
45/* We need to figure out where the text region is so that we use the
46 appropriate ptrace operator to manipulate text. Simply reading/writing
47 user space will crap out HPUX. */
48#define NEED_TEXT_START_END 1
49
50/* This macro defines the register numbers (from REGISTER_NAMES) that
51 are effectively unavailable to the user through ptrace(). It allows
52 us to include the whole register set in REGISTER_NAMES (inorder to
53 better support remote debugging). If it is used in
54 fetch/store_inferior_registers() gdb will not complain about I/O errors
55 on fetching these registers. If all registers in REGISTER_NAMES
56 are available, then return false (0). */
57
58#define CANNOT_STORE_REGISTER(regno) \
59 ((regno) == 0) || \
60 ((regno) == PCSQ_HEAD_REGNUM) || \
61 ((regno) >= PCSQ_TAIL_REGNUM && (regno) < IPSW_REGNUM) || \
62 ((regno) > IPSW_REGNUM && (regno) < FP4_REGNUM)
63
64/* In hppah-nat.c: */
65#define FETCH_INFERIOR_REGISTERS
66#define CHILD_XFER_MEMORY
67#define CHILD_POST_FOLLOW_INFERIOR_BY_CLONE
68#define CHILD_POST_FOLLOW_VFORK
69
70/* While this is for use by threaded programs, it doesn't appear
71 * to hurt non-threaded ones. This is used in infrun.c: */
9e086581 72#define PREPARE_TO_PROCEED(select_it) hppa_prepare_to_proceed()
c5aa993b 73extern int hppa_prepare_to_proceed PARAMS ((void));
c906108c
SS
74
75/* In infptrace.c or infttrace.c: */
76#define CHILD_PID_TO_EXEC_FILE
77#define CHILD_POST_STARTUP_INFERIOR
78#define CHILD_ACKNOWLEDGE_CREATED_INFERIOR
79#define CHILD_INSERT_FORK_CATCHPOINT
80#define CHILD_REMOVE_FORK_CATCHPOINT
81#define CHILD_INSERT_VFORK_CATCHPOINT
82#define CHILD_REMOVE_VFORK_CATCHPOINT
83#define CHILD_HAS_FORKED
84#define CHILD_HAS_VFORKED
85#define CHILD_CAN_FOLLOW_VFORK_PRIOR_TO_EXEC
86#define CHILD_INSERT_EXEC_CATCHPOINT
87#define CHILD_REMOVE_EXEC_CATCHPOINT
88#define CHILD_HAS_EXECD
89#define CHILD_REPORTED_EXEC_EVENTS_PER_EXEC_CALL
90#define CHILD_HAS_SYSCALL_EVENT
91#define CHILD_POST_ATTACH
92#define CHILD_THREAD_ALIVE
93
94#define REQUIRE_ATTACH(pid) hppa_require_attach(pid)
95extern int hppa_require_attach PARAMS ((int));
96
97#define REQUIRE_DETACH(pid,signal) hppa_require_detach(pid,signal)
c5aa993b 98extern int hppa_require_detach PARAMS ((int, int));
c906108c
SS
99
100/* So we can cleanly use code in infptrace.c. */
101#define PT_KILL PT_EXIT
102#define PT_STEP PT_SINGLE
103#define PT_CONTINUE PT_CONTIN
104
105/* FIXME HP MERGE : Previously, PT_RDUAREA. this is actually fixed
106 in gdb-hp-snapshot-980509 */
107#define PT_READ_U PT_RUAREA
108#define PT_WRITE_U PT_WUAREA
109#define PT_READ_I PT_RIUSER
110#define PT_READ_D PT_RDUSER
111#define PT_WRITE_I PT_WIUSER
112#define PT_WRITE_D PT_WDUSER
113
114/* attach/detach works to some extent under BSD and HPUX. So long
115 as the process you're attaching to isn't blocked waiting on io,
116 blocked waiting on a signal, or in a system call things work
117 fine. (The problems in those cases are related to the fact that
118 the kernel can't provide complete register information for the
119 target process... Which really pisses off GDB.) */
120
121#define ATTACH_DETACH
122
123/* In infptrace or infttrace.c: */
124
125/* Starting with HP-UX 10.30, support is provided (in the form of
126 ttrace requests) for memory-protection-based hardware watchpoints.
127
128 The 10.30 implementation of these functions reside in infttrace.c.
129
130 Stubs of these functions will be provided in infptrace.c, so that
131 10.20 will at least link. However, the "can I use a fast watchpoint?"
132 query will always return "No" for 10.20. */
133
134#define TARGET_HAS_HARDWARE_WATCHPOINTS
135
136/* The PA can watch any number of locations (generic routines already check
137 that all intermediates are in watchable memory locations). */
138#define TARGET_CAN_USE_HARDWARE_WATCHPOINT(type, cnt, ot) \
139 hppa_can_use_hw_watchpoint(type, cnt, ot)
140
141/* The PA can also watch memory regions of arbitrary size, since we're using
142 a page-protection scheme. (On some targets, apparently watch registers
143 are used, which can only accomodate regions of REGISTER_SIZE.) */
144#define TARGET_REGION_SIZE_OK_FOR_HW_WATCHPOINT(byte_count) \
145 (1)
146
147/* However, some addresses may not be profitable to use hardware to watch,
148 or may be difficult to understand when the addressed object is out of
149 scope, and hence should be unwatched. On some targets, this may have
150 severe performance penalties, such that we might as well use regular
151 watchpoints, and save (possibly precious) hardware watchpoints for other
152 locations.
153
154 On HP-UX, we choose not to watch stack-based addresses, because
155
156 [1] Our implementation relies on page protection traps. The granularity
157 of these is large and so can generate many false hits, which are expensive
158 to respond to.
159
160 [2] Watches of "*p" where we may not know the symbol that p points to,
161 make it difficult to know when the addressed object is out of scope, and
162 hence shouldn't be watched. Page protection that isn't removed when the
163 addressed object is out of scope will either degrade execution speed
164 (false hits) or give false triggers (when the address is recycled by
165 other calls).
166
167 Since either of these points results in a slow-running inferior, we might
168 as well use normal watchpoints, aka single-step & test. */
169#define TARGET_RANGE_PROFITABLE_FOR_HW_WATCHPOINT(pid,start,len) \
170 hppa_range_profitable_for_hw_watchpoint(pid, start, (LONGEST)(len))
171
172/* On HP-UX, we're using page-protection to implement hardware watchpoints.
173 When an instruction attempts to write to a write-protected memory page,
174 a SIGBUS is raised. At that point, the write has not actually occurred.
175
176 We must therefore remove page-protections; single-step the inferior (to
177 allow the write to happen); restore page-protections; and check whether
178 any watchpoint triggered.
179
180 If none did, then the write was to a "nearby" location that just happens
181 to fall on the same page as a watched location, and so can be ignored.
182
183 The only intended client of this macro is wait_for_inferior(), in infrun.c.
184 When HAVE_NONSTEPPABLE_WATCHPOINT is true, that function will take care
185 of the stepping & etc. */
186
187#define STOPPED_BY_WATCHPOINT(W) \
188 ((W.kind == TARGET_WAITKIND_STOPPED) && \
189 (stop_signal == TARGET_SIGNAL_BUS) && \
190 ! stepped_after_stopped_by_watchpoint && \
191 bpstat_have_active_hw_watchpoints ())
192
193/* When a hardware watchpoint triggers, we'll move the inferior past it
194 by removing all eventpoints; stepping past the instruction that caused
195 the trigger; reinserting eventpoints; and checking whether any watched
196 location changed. */
197#define HAVE_NONSTEPPABLE_WATCHPOINT
198
199/* Our implementation of "hardware" watchpoints uses memory page-protection
200 faults. However, HP-UX has unfortunate interactions between these and
201 system calls; basically, it's unsafe to have page protections on when a
202 syscall is running. Therefore, we also ask for notification of syscall
203 entries and returns. When the inferior enters a syscall, we disable
204 h/w watchpoints. When the inferior returns from a syscall, we reenable
205 h/w watchpoints.
206
207 infptrace.c supplies dummy versions of these; infttrace.c is where the
208 meaningful implementations are.
c5aa993b 209 */
c906108c
SS
210#define TARGET_ENABLE_HW_WATCHPOINTS(pid) \
211 hppa_enable_page_protection_events (pid)
c5aa993b 212extern void hppa_enable_page_protection_events PARAMS ((int));
c906108c
SS
213
214#define TARGET_DISABLE_HW_WATCHPOINTS(pid) \
215 hppa_disable_page_protection_events (pid)
c5aa993b 216extern void hppa_disable_page_protection_events PARAMS ((int));
c906108c
SS
217
218/* Use these macros for watchpoint insertion/deletion. */
219#define target_insert_watchpoint(addr, len, type) \
220 hppa_insert_hw_watchpoint (inferior_pid, addr, (LONGEST)(len), type)
221
222#define target_remove_watchpoint(addr, len, type) \
223 hppa_remove_hw_watchpoint (inferior_pid, addr, (LONGEST)(len), type)
224
225/* We call our k-thread processes "threads", rather
226 * than processes. So we need a new way to print
227 * the string. Code is in hppah-nat.c.
228 */
229#define target_pid_to_str( pid ) \
230 hppa_pid_to_str( pid )
c5aa993b 231extern char *hppa_pid_to_str PARAMS ((pid_t));
c906108c
SS
232
233#define target_tid_to_str( pid ) \
234 hppa_tid_to_str( pid )
c5aa993b 235extern char *hppa_tid_to_str PARAMS ((pid_t));
c906108c
SS
236
237/* For this, ID can be either a process or thread ID, and the function
238 will describe it appropriately, returning the description as a printable
239 string.
240
241 The function that implements this macro is defined in infptrace.c and
242 infttrace.c.
c5aa993b 243 */
c906108c
SS
244#define target_pid_or_tid_to_str(ID) \
245 hppa_pid_or_tid_to_str (ID)
c5aa993b 246extern char *hppa_pid_or_tid_to_str PARAMS ((pid_t));
c906108c
SS
247
248/* This is used when handling events caused by a call to vfork(). On ptrace-
249 based HP-UXs, when you resume the vforked child, the parent automagically
250 begins running again. To prevent this runaway, this function is used.
251
252 Note that for vfork on HP-UX, we receive three events of interest:
253
254 1. the vfork event for the new child process
255 2. the exit or exec event of the new child process (actually, you get
c5aa993b 256 two exec events on ptrace-based HP-UXs)
c906108c
SS
257 3. the vfork event for the original parent process
258
259 The first is always received first. The other two may be received in any
260 order; HP-UX doesn't guarantee an order.
c5aa993b 261 */
c906108c
SS
262#define ENSURE_VFORKING_PARENT_REMAINS_STOPPED(PID) \
263 hppa_ensure_vforking_parent_remains_stopped (PID)
c5aa993b 264extern void hppa_ensure_vforking_parent_remains_stopped PARAMS ((int));
c906108c
SS
265
266/* This is used when handling events caused by a call to vfork().
267
268 On ttrace-based HP-UXs, the parent vfork and child exec arrive more or less
269 together. That is, you could do two wait()s without resuming either parent
270 or child, and get both events.
271
272 On ptrace-based HP-UXs, you must resume the child after its exec event is
273 delivered or you won't get the parent's vfork. I.e., you can't just wait()
274 and get the parent vfork, after receiving the child exec.
c5aa993b 275 */
c906108c
SS
276#define RESUME_EXECD_VFORKING_CHILD_TO_GET_PARENT_VFORK() \
277 hppa_resume_execd_vforking_child_to_get_parent_vfork ()
c5aa993b 278extern int hppa_resume_execd_vforking_child_to_get_parent_vfork PARAMS ((void));
c906108c
SS
279
280#ifdef HAVE_HPUX_THREAD_SUPPORT
281
c906108c
SS
282extern char *hpux_pid_to_str PARAMS ((int pid));
283#define target_pid_to_str(PID) hpux_pid_to_str (PID)
284
285#endif /* HAVE_HPUX_THREAD_SUPPORT */
286
287#define HPUXHPPA
7a292a7a
SS
288
289#define MAY_SWITCH_FROM_INFERIOR_PID (1)
290
291#define MAY_FOLLOW_EXEC (1)
292
293#define USE_THREAD_STEP_NEEDED (1)
This page took 0.06448 seconds and 4 git commands to generate.