From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27220 invoked by alias); 5 Jun 2009 19:03:57 -0000 Received: (qmail 26806 invoked by uid 22791); 5 Jun 2009 19:03:51 -0000 X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,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; Fri, 05 Jun 2009 19:03:45 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MCehb-0003fi-2P for gdb-patches@sources.redhat.com; Fri, 05 Jun 2009 19:03:43 +0000 Received: from mobius.qnx.com ([209.226.137.108]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Jun 2009 19:03:43 +0000 Received: from aristovski by mobius.qnx.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Jun 2009 19:03:43 +0000 To: gdb-patches@sources.redhat.com From: Aleksandar Ristovski Subject: Re: ptid from core section Date: Fri, 05 Jun 2009 19:03:00 -0000 Message-ID: References: <4A23F9FF.8040708@qnx.com> <200906051726.51861.pedro@codesourcery.com> <200906052001.03187.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: <200906052001.03187.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00113.txt.bz2 Pedro Alves wrote: > On Friday 05 June 2009 18:54:08, Aleksandar Ristovski wrote: >> On nto, we are not using lwp field at all. We use thread id. >> In nto, I override core_open to add thread private data >> once core_open has finished it's work. > > It's hard to guess without seeing the code, but, by overriding > you mean: you have a function that replaces core_open itself, then > that goes against the direction we want to go with corelow.c. We > want this file to work the same for both native and cross debugging, > and overriding target_ops methods like that doesn't work well in > that case. :-( That's why all new core support customising > methods are done through gdbarch. > > Hmmm, I don't have the details on how you're storing or > extracting that info, and if it is a different mechanism from > when doing live debugging, but, there's a call to > target_find_new_threads at the bottom of core_open: > > /* Now go through the target stack looking for threads since there > may be a thread_stratum target loaded on top of target core by > now. The layer above should claim threads found in the BFD > sections. */ > target_find_new_threads (); > > it may work for you to attach thread private data from > within that callback. > >> In summary: the motivation for this patch is to avoid having >> to patch corelow.c. > > I understand that. I was just asking/suggesting ( since the > beggining of the thread, actually :-) ) that the nto overrides > be included in the patch, so we'd understand if we're doing > the right decisions, that's all. I didn't know about that > core_open override or the intention to add private data to > threads. > > On Friday 05 June 2009 18:54:08, Aleksandar Ristovski wrote: >> Looking at core handling I think the whole thing is not >> clean. > > Cleaning up patches welcome. We never have enough of those :-) > The other option I see, is to revamp, cleanup and and normalize > how bfd exports core process or threads ids to GDB. But, what, > exactly, are you refering to as not clean? corelow.c would > be leaner and cleaner if we didn't have all those legacy targets > using the deprecated mechanisms around in the tree, but we do. > > Alternatively, I suppose it wouldn't be such a bad idea to > officially declare that the lwp field of ptid is for kernel > threads, and that the tid field is for user/thread library > threads (thread_stratum targets) (which itself would mostly > be useful to M:N configurations, where details of > user thread registers are found somewhere in memory data > structures). Then, it would be clearer that the .reg sections > map to kernel processes/lwps/threads. This would mean that > it wouldn't be such a stretch to make nto-procfs.c use the > lwp field of ptids at all. > >> I see your point, but I see no particular advantage >> of your approach - we moved the default code to corelow but >> now introduced check for gdbarch_..._p. > > The advantage is that we only implement the default > case *once* (core_gdbarch == NULL; not-NULL, but the arch > doesn't implement the callbacks). > >> But don't get me wrong - I am not against your approach - as >> long as I don't have to patch corelow in order to get gdb >> working for neutrino. > > Ok, assuming it works, I'll check it in. > Wait :-) I have opened another thread in http://sourceware.org/ml/gdb/2009-06/msg00051.html Maybe we don't need to customize it this way... -- Aleksandar Ristovski QNX Software Systems