From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12982 invoked by alias); 9 Oct 2003 19:50:48 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12963 invoked from network); 9 Oct 2003 19:50:47 -0000 Received: from unknown (HELO zenia.home) (12.223.225.216) by sources.redhat.com with SMTP; 9 Oct 2003 19:50:47 -0000 Received: by zenia.home (Postfix, from userid 5433) id 8998A20766; Thu, 9 Oct 2003 14:49:14 -0500 (EST) To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: A target has-a 1:N threads? References: <3F856BF9.5020708@redhat.com> From: Jim Blandy Date: Thu, 09 Oct 2003 19:50:00 -0000 In-Reply-To: <3F856BF9.5020708@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00162.txt.bz2 Andrew Cagney writes: > Hello, > > At present GDB maintains a thread-db that contains all the "threads" > known to GDB. The list is cross-target. That is, it can include both > LWPs from the lower "process layer" and "threads" from the higher > "thread layer". > > I think the currently implicit target <-> thread relationship should > be made more explicit: > > - thread_info should point back at it's target > - a target should let you iterate over its "threads" > > This, I belive, will help clean-up the current tid:pid dance. A > thread would always know its target and hence thread operations would > always be applied at the correct level. Sure --- every thread should know how to read and write its registers, so it needs to know which target to use for that. I'm more concerned about the symbol table's ability to support multiple processes, the solib list handling, and so on. There needs to be a data structure that represents an address space, with which we can associate the addr->block, addr->line, and addr->symbol mappings, the solib lists, and so on.