From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11250 invoked by alias); 10 Jun 2009 20:38:49 -0000 Received: (qmail 11242 invoked by uid 22791); 10 Jun 2009 20:38:48 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_NUMERIC_HELO,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Jun 2009 20:38:39 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MEUZ9-0006k7-Tp for gdb@sources.redhat.com; Wed, 10 Jun 2009 20:38:35 +0000 Received: from 132.207.220.31 ([132.207.220.31]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Jun 2009 20:38:35 +0000 Received: from aristovski by 132.207.220.31 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Jun 2009 20:38:35 +0000 To: gdb@sources.redhat.com From: Aleksandar Ristovski Subject: Re: corelow and threads question Date: Wed, 10 Jun 2009 20:38:00 -0000 Message-ID: References: <200906060127.57034.pedro@codesourcery.com> <200906101747.20527.pedro@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) In-Reply-To: <200906101747.20527.pedro@codesourcery.com> 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: 2009-06/txt/msg00096.txt.bz2 Thanks for replying. Ok, then I think what you wanted to commit works for me (I am talking about: http://sourceware.org/ml/gdb-patches/2009-06/msg00112.html). As for extra thread info, I guess if we have "core_pid_to_str" to be a thing of architecture, then extra thread info from core fits there too. But I am still not happy about having to expand gdbarch whenever I have something specific to my architecture for a particular stratum - maybe it does belong there but the target stack mechanism seems attractive for using in "fine-tuning" existing targets ("strata"). This will really lead us to having target_ops functions per each predefined strata in gdbarch (i.e. customization for core, for process, for thread...) I was playing (in my head) with idea of defining new "gdbarch_stratum" that would be used on top of other strata... for example, having one gdbarch_stratum per defined stratum (i.e. gdbarch_stratum+file_stratum - to allow gdbarch customize file_stratum, gdbarch_stratum + core_stratum for customizing core stuff, etc...); we would have to "spread" stratums in "strata" enum and insert gdbarch_ versions above correspoinding strata... that way I could really customize each of the strata for my architecture only by overriding corresponding _ops functions without having to add new function to gdbarch interface and regenerating gdbarch files. Something like this (just an illustration): enum strata { dumm_stratum = 0, gdbarch_stratum = 1, file_stratum = 2, core_stratum = 4, process_stratum = 6, thread_stratum = 8, record_stratum = 10 }; Then I would be able to "inject" my: ... nto_core_ops.to_stratum = gdbarch_stratum + core_stratum; /* But NO add_target(&nto_core_ops); */ ... Then, somewhere in core_open: /* insert gdbarch specific core stratum just above core_stratum */ if (gdbarch_has_stratum (gdbarch_stratum + core_stratum)) push_target (gdbarch_stratum (gdbarch_stratum + core_stratum)); Thanks, -- Aleksandar Ristovski QNX Software Systems