sol-thread.c core_ops oddity

sol-thread.c core_ops oddity

[Doug Evans]

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?

Re: sol-thread.c core_ops oddity

[Daniel Jacobowitz]

On Thu, Aug 07, 2008 at 12:11:36PM -0700, Doug Evans wrote:
> 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?

Luck and sorting.  I'm pretty sure we generate the calls in
alphabetical order (by filename or by function, I'm not sure).

-- 
Daniel Jacobowitz
CodeSourcery

Re: sol-thread.c core_ops oddity

[Doug Evans]

On Thu, Aug 7, 2008 at 12:25 PM, Daniel Jacobowitz <drow@false.org> wrote:
> On Thu, Aug 07, 2008 at 12:11:36PM -0700, Doug Evans wrote:
>> 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?
>
> Luck and sorting.  I'm pretty sure we generate the calls in
> alphabetical order (by filename or by function, I'm not sure).

Thanks.  I don't see any sorting beyond
INIT_FILES = $(COMMON_OBS) $(TSOBS) $(CONFIG_SRCS)
and the hack for gdbtypes.
Is there an intention to officially sanction the sorting as something
one can take advantage of?
I'd like to fix the misleading comments but it's not clear what better
wording should be.

Re: sol-thread.c core_ops oddity

[Stan Shebs]

Doug Evans wrote:
> On Thu, Aug 7, 2008 at 12:25 PM, Daniel Jacobowitz <drow@false.org> wrote:
>   
>> On Thu, Aug 07, 2008 at 12:11:36PM -0700, Doug Evans wrote:
>>     
>>> 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?
>>>       
>> Luck and sorting.  I'm pretty sure we generate the calls in
>> alphabetical order (by filename or by function, I'm not sure).
>>     
>
> Thanks.  I don't see any sorting beyond
> INIT_FILES = $(COMMON_OBS) $(TSOBS) $(CONFIG_SRCS)
> and the hack for gdbtypes.
> Is there an intention to officially sanction the sorting as something
> one can take advantage of?
>   
*I'm* not going to officially sanction any particular sort order, we 
have enough tricky implicit bits already.

Maybe we should have the daily checkin change the initialization order 
randomly, so as to catch misbehaving code... 1/2 :-)

Stan

Re: sol-thread.c core_ops oddity

[Daniel Jacobowitz]

On Thu, Aug 07, 2008 at 12:44:07PM -0700, Doug Evans wrote:
> Thanks.  I don't see any sorting beyond
> INIT_FILES = $(COMMON_OBS) $(TSOBS) $(CONFIG_SRCS)
> and the hack for gdbtypes.

Right you are.  Well, it's the order of that then.

> Is there an intention to officially sanction the sorting as something
> one can take advantage of?

No.  Definitely not.  You've found a bug, just not one that ever triggers.

-- 
Daniel Jacobowitz
CodeSourcery