From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25080 invoked by alias); 17 Jan 2002 14:09:35 -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 24435 invoked from network); 17 Jan 2002 14:08:57 -0000 Received: from unknown (HELO public.xfree86.org) (204.152.184.37) by sources.redhat.com with SMTP; 17 Jan 2002 14:08:57 -0000 Received: from localhost (takis@localhost) by public.xfree86.org (8.11.6/8.11.6) with ESMTP id g0HE8ut76920; Thu, 17 Jan 2002 06:08:56 -0800 (PST) (envelope-from takis@public.xfree86.org) Date: Thu, 17 Jan 2002 06:09:00 -0000 From: Takis Psarogiannakopoulos To: kevinb@redhat.com cc: gdb@sources.redhat.com, binutils@sources.redhat.com Subject: RE:Re: GDB 5.1/Core files and ptids Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-01/txt/msg00182.txt.bz2 Hi Kevin, On Wed, 16 Jan 2002, Kevin Buettner wrote: > The context here is that we're trying to fetch the appropriate > .reg (.reg2, etc) section from bfd, right? That is correct. We are trying to get a section with name "name". > > Especially when, even in the new gdb-5.1/bfd we find: > > > > ====== > > static int > > elfcore_make_pid (abfd) > > bfd *abfd; > > { > > return ((elf_tdata (abfd)->core_lwpid << 16) > > + (elf_tdata (abfd)->core_pid)); > > } > > ======= > > This will need to change. It is incorrect to attempt to represent > both the pid and lwp as a single integer whose size isn't large > enough to hold all of the bits. > I have no problem with the ptid especially when it is less confusing from the old mixed pid's! My problem is that a core DG/UX file has lot of info sections that I would like to read and wasnt sure if gdb would be able now taking in account that elfcore_make_pid had the above form. > So, to fetch a .reg section in a multithreaded core dump where > the pid is 14 and the lwp is 42, GDB would need to ask BFD for > the .reg/14+42 (pseudo) section. > > else if (TIDGET (inferior_ptid)) > sprintf (section_name, "%s/%d+%d", name, PIDGET (inferior_ptid), > TIDGET (inferior_ptid)); > else if (PIDGET (inferior_ptid)) > sprintf (section_name, "%s/%d", name, PIDGET (inferior_ptid)); > else > strcpy (section_name, name); > OK. That is indeed a solution to what I was saying about reading sections using ptid's. Thanks Kevin. Regards, Takis