Re: New feature: allow thread command to take a LWPID.

[Tom Tromey <tromey@redhat.com>]

>>>>> "scott" == scott harrison <scott.harrison@tandberg.com> writes:

Scott> Before invoking GDB we know the LWPID and the PID so we attach to
Scott> the PID (--pid), however, currently GDB only knows about its own
Scott> threadids, we don't know this before invoking GDB but our script
Scott> is already written, so I have created a small patch to the
Scott> "thread" command to take a %<LWPID> option, and swtich to that
Scott> thread.

This seems like a reasonable idea.

I am not super fond of the syntax.  I don't have a better suggestion
though :-(

Scott> Patch is attached.  I realise that this patch may not be applicable to
Scott> all platforms that gdb is used on, sorry.

Do you have a copyright assignment in place?  We'll need one before we
can incorporate this.  If you don't, send me email off-list and I will
get you started.

Mini review:

Scott> +struct thread_info *
Scott> +find_thread_lwp (int num)

New functions should have a header comment describing their purpose,
arguments, and return.  And, this one should be static.

Scott> +    if (tp->ptid.lwp == num)
Scott> +      return tp;

lwp is an long but the `num' argument is an int.  That seems wrong.

Scott> +  char *tidstring=(char *)tidstr;

In the GNU style, there are spaces around operators.  In this case you
also don't need the cast.  So it would look like:

    char *tidstring = tidstr;

Scott> +  if (tidstring[0] == '%')
Scott> +  {

Brace indented two more spaces, then the body two beyond that.

Scott> +    num = value_as_long (parse_and_eval ((void *)(tidstring+1)));

Spaces.  You should probably introduce a new local of 'long' type here.
You don't need the cast to void*, because parse_and_eval actually takes
a char* argument.

thanks,
Tom