Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* Re: Proposal for customization of output of "to_pid_to_str" op in remote.c
@ 2002-12-12 11:33 Nat Gurumoorthy
  0 siblings, 0 replies; 10+ messages in thread
From: Nat Gurumoorthy @ 2002-12-12 11:33 UTC (permalink / raw)
  To: drow; +Cc: gdb

>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


^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: Proposal for customization of output of "to_pid_to_str" op in remote.c
@ 2002-12-11 14:55 Nat Gurumoorthy
  0 siblings, 0 replies; 10+ messages in thread
From: Nat Gurumoorthy @ 2002-12-11 14:55 UTC (permalink / raw)
  To: ac131313; +Cc: gdb

>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


^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: Proposal for customization of output of "to_pid_to_str" op in remote.c
@ 2002-12-11 14:52 Nat Gurumoorthy
  2002-12-11 14:57 ` Daniel Jacobowitz
  0 siblings, 1 reply; 10+ messages in thread
From: Nat Gurumoorthy @ 2002-12-11 14:52 UTC (permalink / raw)
  To: drow; +Cc: gdb

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


^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: Proposal for customization of output of "to_pid_to_str" op in remote.c
@ 2002-12-10 18:24 Nat Gurumoorthy
  2002-12-10 18:57 ` Christopher Faylor
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Nat Gurumoorthy @ 2002-12-10 18:24 UTC (permalink / raw)
  To: drow; +Cc: gdb

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


^ permalink raw reply	[flat|nested] 10+ messages in thread
* Proposal for customization of output of "to_pid_to_str" op in remote.c.
@ 2002-12-10 16:17 Nat Gurumoorthy
  2002-12-10 16:49 ` Daniel Jacobowitz
  0 siblings, 1 reply; 10+ messages in thread
From: Nat Gurumoorthy @ 2002-12-10 16:17 UTC (permalink / raw)
  To: gdb; +Cc: nickk

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


^ permalink raw reply	[flat|nested] 10+ messages in thread
end of thread, other threads:[~2002-12-12 19:33 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-12 11:33 Proposal for customization of output of "to_pid_to_str" op in remote.c Nat Gurumoorthy
  -- strict thread matches above, loose matches on Subject: below --
2002-12-11 14:55 Nat Gurumoorthy
2002-12-11 14:52 Nat Gurumoorthy
2002-12-11 14:57 ` Daniel Jacobowitz
2002-12-10 18:24 Nat Gurumoorthy
2002-12-10 18:57 ` Christopher Faylor
2002-12-10 19:04 ` Daniel Jacobowitz
2002-12-10 19:04 ` Andrew Cagney
2002-12-10 16:17 Nat Gurumoorthy
2002-12-10 16:49 ` Daniel Jacobowitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox