This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] New thread testcase.


Hi Manoj,

I am not the maintainer of gdb.threads -- that is Michael Snyder.
(See the gdb/MAINTAINERS file for a list of who maintains what
subdirectory).  You'll have to work with Michael Snyder on this
patch.  I can give you some feedback though.

The basic idea of the test is good but it needs revision.  Don't get
discouraged by the long list that follows.  I spent some time
proof-reading this because I think it's good and I want it to get in.

Also, since this is Michael Snyder's area, anything he says
outweighs anything I say.  The changes below are just my advice.

Michael C

===

  tbug.c

    I think this name is too generic.  gdb.threads is full of
    files which are about thread bugs.

  * Please email any bugs, comments, and/or additions to this file to:
  * bug-gdb@prep.ai.mit.edu

    Drop this part, bug-gdb@prep.ai.mit.edu is dead.

  sleep(2);

    See the call to sleep() in gdb.mi/pthreads.c:

      /* When gdb is running, it sets hidden breakpoints in the thread
	 library.  The signals caused by these hidden breakpoints can
	 cause system calls such as 'sleep' to return early.  Pay attention
	 to the return value from 'sleep' to get the full sleep.  */
      int unslept = 9;
      while (unslept > 0)
	unslept = sleep (unslept);

    All the sleep() calls in gdb.threads need to be like this.
    See gdb.texinfo, section "Stopping and starting multi-thread
    programs", for more information on this.

  thread_check.exp

    Same complaint about the name.

  'bracktrace'

    Typo.

  'On ppc64 system this test is known to fail due to kernel bug
   in ptrace system call.'

    This is a start, but more info please.  ppc64 is just a processor,
    we need a whole gnu triple here, like ppc64-unknown-linux-gnu.
    Run 'config.guess' on the system where it fails and report that
    info.  Also run 'uname -a' and get the kernel version.  And it
    would help to report the libc / glibc version as well.

  send_gdb / gdb_expect

    We are moving away from those to gdb_test_multiple.
    With gdb_test_multiple, you don't need the default FAIL case
    and the timeout case.

  send_gdb "delete\n"
  gdb_expect 100 {

    Drop the timeout, you should not need a special timeout
    for deleting breakpoints.

  -re "39.*sprintf.* .*\r\n$gdb_prompt $" {

    Do not use absolute line numbers!  Call gdb_get_line_number to
    get the line number you want.

      set marker_1 [gdb_get_line_number "marker 1"]
      ...
      -re "$marker_1.*sprintf.* .*\r\n$gdb_prompt $" {

    Then in the test program, do this:

      sprintf(number, "tf(%ld): begin", (long)arg); /* marker 1 */

  -re ".*3.* .*0x.* in clone.* from .*libc.*$" {

    This is not generic enough.  There's no guarantee that
    pthread_create is implemented with clone.  For your purposes,
    is it good enough to look for pthread_create on the stack?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]