From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11727 invoked by alias); 16 Jan 2002 19:16:15 -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 11684 invoked from network); 16 Jan 2002 19:16:12 -0000 Received: from unknown (HELO public.xfree86.org) (204.152.184.37) by sources.redhat.com with SMTP; 16 Jan 2002 19:16:12 -0000 Received: from localhost (takis@localhost) by public.xfree86.org (8.11.6/8.11.6) with ESMTP id g0GJGCW24838 for ; Wed, 16 Jan 2002 11:16:12 -0800 (PST) (envelope-from takis@public.xfree86.org) Date: Wed, 16 Jan 2002 11:16:00 -0000 From: Takis Psarogiannakopoulos To: gdb@sources.redhat.com Subject: 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/msg00173.txt.bz2 Hello, Trying to port DG/UX source files from gdb 5.0 to version 5.1 (and hopping to submit these at last to GNU) I have found that there is a serious inconsistency for the BFD core files. Before one could overload a process pid with a thread id using the macro: #define MERGEPID(PID, TID) (((PID) & 0xffff) | ((TID) << 16)) Note that this will give us again an integer! In 5.1 someone change this to a stucture called ptid. However it seems to me that you forgot to implemnet something similar to BFD. Problem: Suppose that one has a line co code of the type sprintf (section_name, "%s/%d", name, inferior_pid); OR of the type struct thread_info *tp; ... sprintf (section_name, "%s/%d", name, tp->pid); inside the gdb/core-dgux.c file. Note that this integer (tp->pid or inferior_pid) it should contains/be overloaded with the tid too! Clearly neven if in the 5.1 we have a tp->ptid one cannot write sprintf (section_name, "%s/%d", name, tp->ptid); because ptid is now a structure! 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)); } ======= Any suggestions? Eg can the guy that introduced these new ptids how specicfically to rewrite the line: sprintf (section_name, "%s/%d", name, tp->pid); (pid is from 5.0 ie. a mixed pid but still integer!) having given the tp->ptid and taking in account the elfcore_make_pid that is used by bfd!!! We want to rewrite the bit above so that gdb-5.1 will understand! that this section has info about the pid= PIDGET(tp->ptid) and the lwp=TIDGET(tp->ptid). And reflect these when asked. Regards, Takis PS: My suggestion will be as follows: #define CORE_BFD_MERGEPID(PID, TID) (((PID) & 0xffff) | ((TID) << 16)) (This is just the old gdb 5.0 MERGEPID style). pid_t mixed_bfd_core_pid; ... process_pid = PIDGET(tp->ptid); process_tid = TIDGET(tp->ptid); mixed_bfd_core_pid = CORE_BFD_ERGEPID( process_pid, process_tid); sprintf (section_name, "%s/%d", name, mixed_bfd_core_pid); Would that be OK ? Would gdb-5.1 understand correctly this section?