From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26239 invoked by alias); 7 Aug 2008 19:12:19 -0000 Received: (qmail 26221 invoked by uid 22791); 7 Aug 2008 19:12:18 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 07 Aug 2008 19:11:44 +0000 Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out3.google.com with ESMTP id m77JBbPu002901 for ; Thu, 7 Aug 2008 20:11:37 +0100 Received: from localhost (ruffy.corp.google.com [172.18.118.116]) by zps18.corp.google.com with ESMTP id m77JBaNb008509 for ; Thu, 7 Aug 2008 12:11:36 -0700 Received: by localhost (Postfix, from userid 67641) id 274F81C77BE; Thu, 7 Aug 2008 12:11:36 -0700 (PDT) To: gdb@sourceware.org Subject: sol-thread.c core_ops oddity Message-Id: <20080807191136.274F81C77BE@localhost> Date: Thu, 07 Aug 2008 19:12:00 -0000 From: dje@google.com (Doug Evans) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00137.txt.bz2 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?