Re: Proposal for customization of output of "to_pid_to_str" op in remote.c

[Nat Gurumoorthy <natg at ubicom dot com>]

>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