This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Tristan Gingold wrote:As per my comments on machoread.c.
darwin-nat.h:
DEF_VEC_I(thread_t);
I think there should be at least a one-liner describing each field. Even if it's obvious, the one-liner at least tells us that the meaning is indeed the obvious one, and not something tricky.struct darwin_inferior { int pid; task_t task;
/* Previous port for requesr notification on task. */"request"
extern darwin_inferior *darwin_inf;I guess it would be mean to insist that the Darwin port be multi- process ready. :-)
Follow what gdb_assert.h does for __PRETTY_FUNCTION__ .#if (defined __GNUC__) #define __MACH_CHECK_FUNCTION __PRETTY_FUNCTION__ #else #define __MACH_CHECK_FUNCTION ((__const char *) 0) #endif
Definitely want to say a few words about what we have to do to work with Mach. Refer people to a URL or manual for full details, what we're interested in here is a) basic hints, and b) special issues for GDB.static union { mach_msg_header_t hdr; char data[1024]; } msgin, msgout;
#define X86_EFLAGS_T 0x100ULWon't the PowerPC port get indigestion from this part? :-)
static void darwin_set_sstep (thread_t thread, int enable) { x86_thread_state_t regs; unsigned int count = x86_THREAD_STATE_COUNT;
Let's just call darwin_ptrace directly. I don't see much value in a macro, it's just in this one file.res = PTRACE (PT_THUPDATE, pid, (void *)exc_msg.thread_port, nsignal);
#ifdef HAVE_64_BIT_MACH_EXCEPTIONSWhere does this macro come from? (Yes, I could look it up, but don't make me, add a comment. :-) )
Hmmm. OK for now, I'm sure we'll have to revisit.case EXC_BREAKPOINT: /* Many internal GDB routines expect breakpoints to be reported as TARGET_SIGNAL_TRAP, and will report TARGET_EXC_BREAKPOINT as a spurious signal. */ status->value.sig = TARGET_SIGNAL_TRAP;
return ptid_build (pid, 0, exc_msg.thread_port);Thread port is the id we want to use for threads? I guess it's plausible, we should say that somewhere.
If the code has a use, keep it and make a maintenance command, else discard. Our policy these days is to discourage if-0 blocks everywhere.#if 0 static void darwin_list_gdb_ports (const char *msg)
/* The child must synchronize with gdb: gdb must set the exception portHuh, interesting. I don't have any better ideas myself.
before the child call PTRACE_SIGEXC. We use a pipe to achieve this.
FIXME: is there a lighter way ? */
add_setshow_zinteger_cmd ("inferior", class_obscure,Wasn't this in a different file too? Make sure there is only one.
&inferior_debug_flag, _("\
Set if printing inferior communication debugging statements."), _("\
Show if printing inferior communication debugging statements."), NULL,
NULL, NULL,
&setdebuglist, &showdebuglist);
add_setshow_boolean_cmd ("mach-exceptions", class_support,Likewise.
&enable_mach_exceptions, _("\
Set if mach exceptions are caught."), _("\
Show if mach exceptions are caught."), _("\
When this mode is on, all low level exceptions are reported before being\n\
reported by the kernel."),
&set_enable_mach_exceptions, NULL,
&setlist, &showlist);
}
I'd like to see the x86-specific bits pulled out, we should get off on the right foot with that sort of thing.
Otherwise this file is fine, once feedback is incorporated.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |