libgompd output test

[Mohamed Atef]

On Wed, Jun 29, 2022 at 2:21 PM Jakub Jelinek <jakub@redhat.com> wrote:

> On Wed, Jun 29, 2022 at 06:45:51AM +0200, Mohamed Atef wrote:
> > for this test case,
> >
> > 1.#include <stdio.h>
> > 2.#include <omp.h>
> > 3.int
> > 4.main()
> > 5.{
> > 6.  omp_set_num_threads (5);
> > 7.  #pragma omp parallel
> > 8.    {
> > 9.      int th = omp_get_thread_num ();
> > 10.      printf ("i am thread %d\n", th);
> > 11.    }
> > 12.  return 0;
> > 13.}
>
> You can also use OMP_DISPLAY_ENV=verbose in the environment
> to see how it is printed by the runtime.
>
> > Reading symbols from a.out...
> > OMPD GDB support loaded
> > Run 'ompd init' to start debugging
> > (gdb) ompd init
> > Temporary breakpoint 1 at 0x40115a: file pro.c, line 6.
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library
> "/lib/x86_64-linux-gnu/libthread_db.so.1".
> >
> > Temporary breakpoint 1, main () at pro.c:6
> > 6  omp_set_num_threads (5);
> > Loaded OMPD lib successfully!
>
> Is the GDB OMPD patch available somewhere?
>
No, this is the GDB plugin.

>
> > (gdb) b 10
> > Breakpoint 2 at 0x401198: file pro.c, line 10.
> > (gdb) c
> > Continuing.
> > [New Thread 0x7ffff7d45700 (LWP 116224)]
> > [New Thread 0x7ffff7544700 (LWP 116225)]
> > [New Thread 0x7ffff6d43700 (LWP 116226)]
> > [Switching to Thread 0x7ffff7d45700 (LWP 116224)]
> >
> > Thread 2 "a.out" hit Breakpoint -14, gomp_thread_start
> > (xdata=0x7fffffffd950) at ../../../gcc/libgomp/config/linux/sem.h:46
> > 46  *sem = value * SEM_INC;
> > [New Thread 0x7ffff6542700 (LWP 116227)]
> > [Switching to Thread 0x7ffff7544700 (LWP 116225)]
> >
> > Thread 3 "a.out" hit Breakpoint -14, gomp_thread_start
> > (xdata=0x7fffffffd9d0) at ../../../gcc/libgomp/config/linux/sem.h:46
> > 46  *sem = value * SEM_INC;
> > [Switching to Thread 0x7ffff6d43700 (LWP 116226)]
> >
> > Thread 4 "a.out" hit Breakpoint -14, gomp_thread_start
> > (xdata=0x7fffffffda50) at ../../../gcc/libgomp/config/linux/sem.h:46
> > 46  *sem = value * SEM_INC;
> > [Switching to Thread 0x7ffff6542700 (LWP 116227)]
> >
> > Thread 5 "a.out" hit Breakpoint -14, gomp_thread_start
> > (xdata=0x7fffffffdad0) at ../../../gcc/libgomp/config/linux/sem.h:46
> > 46  *sem = value * SEM_INC;
> >
> > Thread 5 "a.out" hit Breakpoint 2, main._omp_fn.0 () at pro.c:10
> > 10    printf ("i am thread %d\n", th);
> > (gdb) bt
> > #0  main._omp_fn.0 () at pro.c:10
> > #1  0x00007ffff7f9dd8e in gomp_thread_start (xdata=<optimized out>) at
> > ../../../gcc/libgomp/team.c:131
> > #2  0x00007ffff7f48609 in start_thread (arg=<optimized out>) at
> > pthread_create.c:477
> > #3  0x00007ffff7e6d133 in clone () at
> > ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> > (gdb) ompd icv
> > Initialized ICV map successfully for checking OMP API values.
> > ICV                                Name Scope                 Value
> > ===============================================================
> > cancel var                      address_space             0
> > max task priority var           address_space          0
> > stack size var                  address_space             0
> > debug var                       address_space              0
> > OMP_DEBUG                address_space              enabled
> > display affinity var            address_space              0
> > affinity format var             address_space              level %L
> thread
> > %i affinity %A
>
> This ought to be IMHO printed as a string literal, so "level %L thread %i
> affinity %A"
>
> > affinity format len var         address_space              0
> > wait policy var                 address_space              4294967295
> > num teams var                   address_space              0
> > teams thread limit var          address_space              0
> > spin count var                  address_space              300000
> > num proc var                    address_space              8
> > throttled spin count var        address_space              100
> > managed threads var             address_space              5
>
> And also, it would be nice if it was clear which ICVs are GCC
> implementation
> specific and which are standard (the spin count vars are non-standard).
> Also, the names of ICVs in the standard are with hyphens, so perhaps print
> cancel-var, max-task-priority-var etc.?
>
OK, I will fix it in the next patch.

>
>         Jakub
>
>