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

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

[Nat Gurumoorthy]

HI all,
   This is a proposal to allow targets using the remote backend to
customize the output of "to_pid_to_str" operations.  The changes to
src/gdb/remote.c would be as follows:

/* Convert a thread ID to a string.  Returns the string in a static
   buffer.  */

static char *
remote_pid_to_str (ptid_t ptid)
{
  static char buf[30];

#ifndef REMOTE_PID_TO_STR
  sprintf (buf, "Thread %d", PIDGET (ptid));
#else
  REMOTE_PID_TO_STR(buf, ptid, 30);
#endif
  return buf;
}



In the target "tm-XXXX.h"

extern void my_target_pid_to_str(char *buf, ptid_t ptid, unsigned int buflength);
#define REMOTE_PID_TO_STR(buf, ptid, buflength) my_target_pid_to_str(buf, ptid, buflength)


In the target "target-tdep.c" file

void
my_target_pid_to_str(char *buf, ptid_t ptid, unsigned int buflength)
{
  /* sprintf some sensible string into the provided buffer */
  ..
  ..
  ..
}


Currently remote.c provides all the facilities for multithreaded
debugging except for a way to print a customized name for that thread.

Is this the proper forum to discuss this idea? Do I have to file a PR
and mark it as an enhancement request? 

I'd like some feedback on this proposal. Is this going to screw up
multi arch support?

Regards
Nat

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

[Daniel Jacobowitz]

On Tue, Dec 10, 2002 at 04:17:11PM -0800, Nat Gurumoorthy wrote:
> HI all,
>    This is a proposal to allow targets using the remote backend to
> customize the output of "to_pid_to_str" operations.  The changes to
> src/gdb/remote.c would be as follows:

> Currently remote.c provides all the facilities for multithreaded
> debugging except for a way to print a customized name for that thread.
> 
> Is this the proper forum to discuss this idea? Do I have to file a PR
> and mark it as an enhancement request? 
> 
> I'd like some feedback on this proposal. Is this going to screw up
> multi arch support?

Let's take a step back.  What would you be defining this macro as? 
What do you want besides "New thread"?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Nat Gurumoorthy]

>Daniel Jaccobowitz wrote
>Let's take a step back. What would you be defining this macro as? What do
you want besides >"New thread"? 

Daniel,
      What I am proposing is that this macro is a call into a print
function defined in my target-tdep.c file. When I type "info threads"
this interface is getting invoked and I'd like to print a more
descriptive string about the various threads running on our hardware.
Right now it prints it out as
     8 Thread 6 
Which is quite confusing. (The first number is GDB internal numbering. 
The second number is the thread ID issued in my target) What will change 
is that Thread 6 will become something more descriptive.

Regards
Nat

Ps: Daniel I apologize I you are seeing this for the 3rd time. The first
2 times I sent it from a Windows machine and the redhat Mailer barfed.

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

[Christopher Faylor]

On Tue, Dec 10, 2002 at 06:24:22PM -0800, Nat Gurumoorthy wrote:
>Ps: Daniel I apologize I you are seeing this for the 3rd time. The first
>2 times I sent it from a Windows machine and the redhat Mailer barfed.

Translation: There was an attempt to send html mail to the list rather
than just plain text.  sources.redhat.com mailing lists don't accept html
formatted mail.

cgf

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

[Daniel Jacobowitz]

On Tue, Dec 10, 2002 at 06:24:22PM -0800, Nat Gurumoorthy wrote:
> >Daniel Jaccobowitz wrote
> >Let's take a step back. What would you be defining this macro as? What do
> you want besides >"New thread"? 
> 
> Daniel,
>       What I am proposing is that this macro is a call into a print
> function defined in my target-tdep.c file. When I type "info threads"
> this interface is getting invoked and I'd like to print a more
> descriptive string about the various threads running on our hardware.
> Right now it prints it out as
>      8 Thread 6 
> Which is quite confusing. (The first number is GDB internal numbering. 
> The second number is the thread ID issued in my target) What will change 
> is that Thread 6 will become something more descriptive.

The remote protocol allows you to return more information in the stub. 
Can you do that instead?  See ThreadExtraInfo.

> Ps: Daniel I apologize I you are seeing this for the 3rd time. The first
> 2 times I sent it from a Windows machine and the redhat Mailer barfed.

This one has natg@ as your from address, which bounces...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Andrew Cagney]

>>Daniel Jaccobowitz wrote
>>Let's take a step back. What would you be defining this macro as? What do
> 
> you want besides >"New thread"? 
> 
> Daniel,
>       What I am proposing is that this macro is a call into a print
> function defined in my target-tdep.c file. When I type "info threads"
> this interface is getting invoked and I'd like to print a more
> descriptive string about the various threads running on our hardware.
> Right now it prints it out as
>      8 Thread 6 
> Which is quite confusing. (The first number is GDB internal numbering. 
> The second number is the thread ID issued in my target) What will change 
> is that Thread 6 will become something more descriptive.
> 
> Regards
> Nat

Er, isn't there already stuff like qThreadInfo?

Andrew

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

[Nat Gurumoorthy]

>Daniel Jaccobowitz wrote
>The remote protocol allows you to return more information in the stub. 
>Can you do that instead?  See ThreadExtraInfo.

Daniel,
    I know that. Just as the remote protocol allows me to print out
extra information about each thread, I would like it to let me print
out the name of the thread and not call it "Thread 1" or "Thread 2"
etc. The proposed interface will allow the target dependent layer
to print what ever it wants. If the target dependent layer does not
specify the macro the behavior reverts to the Original mode.

Regards
Nat

ps: Thanks for pointing out the problem with the natg@ubicom.com address.
It has been fixed.

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

[Daniel Jacobowitz]

On Wed, Dec 11, 2002 at 02:51:46PM -0800, Nat Gurumoorthy wrote:
> >Daniel Jaccobowitz wrote
> >The remote protocol allows you to return more information in the stub. 
> >Can you do that instead?  See ThreadExtraInfo.
> 
> Daniel,
>     I know that. Just as the remote protocol allows me to print out
> extra information about each thread, I would like it to let me print
> out the name of the thread and not call it "Thread 1" or "Thread 2"
> etc. The proposed interface will allow the target dependent layer
> to print what ever it wants. If the target dependent layer does not
> specify the macro the behavior reverts to the Original mode.
> 
> Regards
> Nat
> 
> ps: Thanks for pointing out the problem with the natg@ubicom.com address.
> It has been fixed.

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.

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...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

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

[Nat Gurumoorthy]

>Andrew Cagney Wrote
>Er, isn't there already stuff like qThreadInfo?

Andrew,
   qThreadInfo only lets the remote pass back target thread IDs to GDB.
GDB then converts the pid into and GDB internal ptid (process + thread ID).
The "to_pid_to_str" function pointer in the target structure is used
to convert a ptid to a printable string. If you are currently using the
remote interface this defaults to looking like "Thread 1" "Thread 2" etc.
I would like the the target to be print whatever it wants.
Regards
Nat

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

[Nat Gurumoorthy]

>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