From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31680 invoked by alias); 6 Aug 2004 04:10:02 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 31653 invoked from network); 6 Aug 2004 04:10:00 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sourceware.org with SMTP; 6 Aug 2004 04:10:00 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 5502747D91; Thu, 5 Aug 2004 21:09:59 -0700 (PDT) Date: Fri, 06 Aug 2004 04:10:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: thread ptids when debugging from core file (x86-linux) Message-ID: <20040806040959.GL1192@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2004-08/txt/msg00147.txt.bz2 Hello, We recently noticed that Ada task switching doesn't work when debugging a program using a core file. This is on x86-linux. ada-tasks.c is just a module similar to thread*.c. It shows the list of Ada tasks (high-level equivalent of C threads), and allows a user to switch from one task to the other. Ada tasks are usually mapped one-on-one on threads, so task switching is implemented by using the thread layer: Given a certain task to switch to, we deduce from some data stored in the GNAT runtime memory (+ the inferior ptid) the PTID of the associated thread, and then ask the thread layer to switch to that PTID. Unfortunately, that doesn't work when debugging from a core file, because the PTID of the threads are not the same as when debugging live. According to corelow.c:add_to_thread_list(), the thread PTID is a degenerated {pid, 0, 0} where pid is just the number in the section name where the thread has been dumped (ie section ".reg/1234" => thread ptid = {1234, 0, 0}). This breaks the mapping that we computed in the ada-tasks layer, and thus causes the task switch to fail, because ada-tasks asks thread to switch to a thread it doesn't know about. I was wondering whether I could be able to dig the original thread PTIDs back from the data stored in the core file. Would anybody know? Is there some sort of documentation on how this core file is created and what information it contains? How are the number in the .reg/n sections generated? Are they PID+n where PID is the inferior PID and n the thread number? If I can't find the original PTIDs, I really don't know how I am going to be able to restore the mapping between the Ada tasks and the underlying threads. Does anybody have some ideas of how this could be done? We don't have much information in the GNAT runtime. It's all stored in the Ada Task Control Block (ATCB) and basically our only link is that thread ID. Thanks, -- Joel