This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
sol-thread.c core_ops oddity
- From: dje at google dot com (Doug Evans)
- To: gdb at sourceware dot org
- Date: Thu, 7 Aug 2008 12:11:36 -0700 (PDT)
- Subject: sol-thread.c core_ops oddity
The code says it doesn't care which of _initialize_sol_thread
or _initialize_corelow is run first (and clearly one would rather
not care).
corelow.c:
/* non-zero if we should not do the add_target call in
_initialize_corelow; not initialized (i.e., bss) so that
the target can initialize it (i.e., data) if appropriate.
This needs to be set at compile time because we don't know
for sure whether the target's initialize routine is called
before us or after us. */
int coreops_suppress_target;
and sol-thread.c has:
/* We suppress the call to add_target of core_ops in corelow because
if there are two targets in the stratum core_stratum,
find_core_target won't know which one to return. See corelow.c for
an additonal comment on coreops_suppress_target. */
int coreops_suppress_target = 1;
Ok, so far so good.
However, if _initialize_sol_thread is run first then the order is:
sol-thread.c:
init_sol_core_ops ();
[...]
memcpy (&orig_core_ops, &core_ops, sizeof (struct target_ops));
memcpy (&core_ops, &sol_core_ops, sizeof (struct target_ops));
add_target (&core_ops);
then corelow.c:
init_core_ops ();
and afterwards orig_core_ops is still full of zeroes (bad for
later calls to orig_core_ops.mumble), and the
core_ops target is filled with the values from corelow.c
(undoing the work of init_col_core_ops).
Obviously I'm missing something.
I don't have a solaris system to see what really happens,
can someone fill in the missing piece that makes the above work?