From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4774 invoked by alias); 12 Dec 2002 19:33:55 -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 4765 invoked from network); 12 Dec 2002 19:33:53 -0000 Received: from unknown (HELO hydra.ubicom.com) (4.20.168.98) by sources.redhat.com with SMTP; 12 Dec 2002 19:33:53 -0000 Received: FROM jaguar.scenix_engr BY hydra.ubicom.com ; Thu Dec 12 11:32:32 2002 -0800 Received: from ubicom.com by jaguar.scenix_engr (SMI-8.6/SMI-SVR4) id LAA26737; Thu, 12 Dec 2002 11:33:44 -0800 Received: (from natg@localhost) by ubicom.com (8.11.6/8.11.6) id gBCJXht27822; Thu, 12 Dec 2002 11:33:43 -0800 Date: Thu, 12 Dec 2002 11:33:00 -0000 From: Nat Gurumoorthy Message-Id: <200212121933.gBCJXht27822@ubicom.com> To: drow@mvista.com Subject: Re: Proposal for customization of output of "to_pid_to_str" op in remote.c Cc: gdb@sources.redhat.com X-SW-Source: 2002-12/txt/msg00192.txt.bz2 >Daniel Jaccobowitz wrote >What's wrong with: >1 Thread 1 (Original thread) >2 Thread 2 (Extra thread) >3 Thread 4 (Thread I Felt Like) >? What output do you want? I'd like to keep it printing the TID for >consistency. Daniel, Personally there is nothing wrong with the above display. I have consumers of our debugger who want to see only: 1 Original thread 2 Extra thread 3 Thread I Felt Like Right now the way remote.c is set up I am unable to satisfy that. >In any case, a target macro the way you did this is probably the wrong >way. It looks almost like you want a gdbarch method... I am in total agreement with you on this. Red Had did a port of GDB for our next generation processor where they did add support to gdbarch to allow a target which uses the remote protocl to be able to provide functions in its tdep.c files for the following thread related operations to_thread_alive to_find_new_threads to_pid_to_str to_extra_thread_info They changed code in remote.c to invoke the functionality in the tdep.c file. Here is a sample of what they did In gdbarch.sh the following was added # Return a static string representation of internal gdb process id PID. F:2:REMOTE_PID_TO_STR:char *:remote_pid_to_str:ptid_t ptid:ptid::0 # In remote.c the remote_pid_to_str was changed as follows static char * remote_pid_to_str (ptid_t ptid) { static char buf[30]; if (REMOTE_PID_TO_STR_P ()) return REMOTE_PID_TO_STR (ptid); sprintf (buf, "Thread %d", PIDGET (ptid)); return buf; } In the target-tdep.c there is a call to "set_gdbarch_remote_pid_to_str" to register the target dependent pid_to_str function. I am trying to migrate the original Red Hat work to the top of trunk GDB and I ran into the issue that what Red Hat had done for us in not available in the top of trunk. The way they have implemented is the right way to do it. What do I have to do make it happen? Regards Nat