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

Tom Tromey
2010-02-04T23:30:38Z

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