[RFA] Darwin/x86 port (v4 - part 2/4: darwin-nat.?)
Tristan Gingold
gingold@adacore.com
Wed Nov 19 21:18:00 GMT 2008
On Nov 18, 2008, at 3:18 AM, Stan Shebs wrote:
> Tristan Gingold wrote:
>>
>> darwin-nat.h:
>>
>>
>> DEF_VEC_I(thread_t);
> As per my comments on machoread.c.
Space added.
>> struct darwin_inferior
>> {
>> int pid;
>> task_t task;
> 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.
Done.
>> /* Previous port for requesr notification on task. */
> "request"
Oops!
>> extern darwin_inferior *darwin_inf;
> I guess it would be mean to insist that the Darwin port be multi-
> process ready. :-)
Yes. I will try to work on that later. Shouldn't be that hard.
>> #if (defined __GNUC__)
>> #define __MACH_CHECK_FUNCTION __PRETTY_FUNCTION__
>> #else
>> #define __MACH_CHECK_FUNCTION ((__const char *) 0)
>> #endif
> Follow what gdb_assert.h does for __PRETTY_FUNCTION__ .
I now use ASSERT_FUNCTIOn from gdb_assert.h it it is defined. That's
avoid code duplication.
(OTOH only GCC 4.x or later is available on Darwin)
>> static union {
>> mach_msg_header_t hdr;
>> char data[1024];
>> } msgin, msgout;
>>
> 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.
Done.
>> #define X86_EFLAGS_T 0x100UL
>>
>> static void
>> darwin_set_sstep (thread_t thread, int enable)
>> {
>> x86_thread_state_t regs;
>> unsigned int count = x86_THREAD_STATE_COUNT;
> Won't the PowerPC port get indigestion from this part? :-)
Yes, moved to i386-darwin-nat.c
>
>> res = PTRACE (PT_THUPDATE, pid,
>> (void *)exc_msg.thread_port, nsignal);
> Let's just call darwin_ptrace directly. I don't see much value in a
> macro, it's just in this one file.
The macro is used to stringify the request name (and thus generating a
nicer message).
>> #ifdef HAVE_64_BIT_MACH_EXCEPTIONS
> Where does this macro come from? (Yes, I could look it up, but don't
> make me, add a comment. :-) )
Removed.
>> 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;
> Hmmm. OK for now, I'm sure we'll have to revisit.
Hmm, maybe.
>> 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.
Yes, that makes the code simpler. To be revisited at least to display
a much nicer value to the user.
>> #if 0
>> static void
>> darwin_list_gdb_ports (const char *msg)
> 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.
Discarded.
>> /* The child must synchronize with gdb: gdb must set the exception
>> port
>> before the child call PTRACE_SIGEXC. We use a pipe to achieve
>> this.
>> FIXME: is there a lighter way ? */
> Huh, interesting. I don't have any better ideas myself.
The question is still open!
>> add_setshow_zinteger_cmd ("inferior", class_obscure,
>> &inferior_debug_flag, _("\
>> Set if printing inferior communication debugging statements."), _("\
>> Show if printing inferior communication debugging statements."),
>> NULL,
>> NULL, NULL,
>> &setdebuglist, &showdebuglist);
> Wasn't this in a different file too? Make sure there is only one.
The command is now "darwin" and the flag darwin_debug_flag.
>> add_setshow_boolean_cmd ("mach-exceptions", class_support,
>> &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);
>> }
>>
> Likewise.
There is only one.
> I'd like to see the x86-specific bits pulled out, we should get off
> on the right foot with that sort of thing.
Sure.
> Otherwise this file is fine, once feedback is incorporated.
Thanks.
Tristan.
More information about the Gdb-patches
mailing list