From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18127 invoked by alias); 5 Jun 2009 19:00:23 -0000 Received: (qmail 18111 invoked by uid 22791); 5 Jun 2009 19:00:21 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 05 Jun 2009 19:00:15 +0000 Received: (qmail 545 invoked from network); 5 Jun 2009 19:00:12 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Jun 2009 19:00:12 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: ptid from core section Date: Fri, 05 Jun 2009 19:00:00 -0000 User-Agent: KMail/1.9.10 Cc: Aleksandar Ristovski References: <4A23F9FF.8040708@qnx.com> <200906051726.51861.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <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/msg00112.txt.bz2 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.=20 > =A0 In nto, I override core_open to add thread private data=20 > once core_open has finished it's work.=20 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=20 > 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=20 > clean.=20 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=20=20 > of your approach - we moved the default code to corelow but=20 > now introduced check for gdbarch_..._p. The advantage is that we only implement the default case *once* (core_gdbarch =3D=3D NULL; not-NULL, but the arch doesn't implement the callbacks). > But don't get me wrong - I am not against your approach - as=20 > long as I don't have to patch corelow in order to get gdb=20 > working for neutrino. Ok, assuming it works, I'll check it in. --=20 Pedro Alves