[OMPD] The LLVM OMPD does not have any support for display control variables

[jdelsign]

The LLVM OMPD ompd_get_display_control_vars() and ompd_rel_display_control_vars() (or ompd_release_display_control_vars()) functions are completely stubbed out.

[hansangbae]

I pushed my patch to ompd-devices-50 (15c6dbd), but it will be great if someone can check if this is working correctly.

[jdelsign]

Hi Hansang, Thanks for working on fixing these issues. I cloned the ompd-devices-50 branch this morning, built it, and ran some OMPD tests with TotalView. Unfortunately, the library crashed almost immediately, and I was not able to get as far as looking at the fix for issue #60. The specific reason was that the ompd_callbacks_t structure layout was fixed, but the ompd_get_api_version() still returns 0x05000602, which TotalView uses to "know" that it is dealing with the ompd-devices branch version of the library which was missing the read_string callback. So, since ompd-devices-50 branch is supposed to implement the OMPD v5.0 API, I tried changing the library to #define OMPD_VERSION to 201811 like it is supposed to, and rebuilt the library. But TotalView then tripped over issue #58, which is "[OMPD] The LLVM OMPD ompd_enumerate_icvs() and ompd_enumerate_states() functions do not allocate the strings they returns <#58>". TotalView crashed trying to free the string returned by ompd_enumerate_states(). That was supposed to have been fixed by Manoel on the ompd-devices-50 branch, but looking at the ompd_enumerate_states() function code, it was only /partially/ fixed... AFAICT, the code path for CUDA allocates the state name strings it returns, but the code path for the host does not. So, more work is required before I'll be able to test issue #60. Cheers, John D.

…

On 3/29/2019 10:49 AM, Hansang Bae wrote: I pushed my patch to ompd-devices-50 (15c6dbd <15c6dbd>), but it will be great if someone can check if this is working correctly. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALxO7NgP_XVlVZ8UDmu3VvcU8vAQtJxdks5vbigIgaJpZM4bVbtT>.

[jdelsign]

Hi Hansang, I patched up the OMPD library and was able to get around the issues I mentioned to test the control variables. The TotalView output follows (it reformats the strings). AFAICT, it looks like it's working well. Cheers, John D. d1.<> domp -control_vars 1 (230160):        KMP_ABORT_DELAY: 0   KMP_ADAPTIVE_LOCK_PROPS: '1,1024'           KMP_AFFINITY: 'noverbose,warnings,disabled'        KMP_ALIGN_ALLOC: 64   KMP_ALL_THREADPRIVATE: 0        KMP_ATOMIC_MODE: 2            KMP_A_DEBUG: 0          KMP_BLOCKTIME: 200            KMP_B_DEBUG: 0   KMP_CONSISTENCY_CHECK: none       KMP_CPUINFO_FILE: undefined            KMP_C_DEBUG: 0          KMP_DEBUG_BUF: false   KMP_DEBUG_BUF_ATOMIC: false    KMP_DEBUG_BUF_CHARS: 128    KMP_DEBUG_BUF_LINES: 512   KMP_DETERMINISTIC_REDUCTION: false   KMP_DEVICE_THREAD_LIMIT: 0               KMP_DIAG: 0   KMP_DISP_NUM_BUFFERS: 7   KMP_DUPLICATE_LIB_OK: false       KMP_DYNAMIC_MODE: undefined            KMP_D_DEBUG: 0            KMP_E_DEBUG: 0    KMP_FORCE_REDUCTION: undefined   KMP_FOREIGN_THREADS_THREADPRIVATE: true   KMP_FORKJOIN_BARRIER: '0,0'   KMP_FORKJOIN_BARRIER_PATTERN: 'linear,linear'    KMP_FORKJOIN_FRAMES: true   KMP_FORKJOIN_FRAMES_MODE: 3            KMP_F_DEBUG: 0          KMP_GTID_MODE: 3     KMP_HANDLE_SIGNALS: false   KMP_HOT_TEAMS_MAX_LEVEL: 1     KMP_HOT_TEAMS_MODE: 0   KMP_INHERIT_FP_CONTROL: true       KMP_INIT_AT_FORK: true          KMP_INIT_WAIT: 2048   KMP_ITT_PREPARE_DELAY: 0   KMP_LOAD_BALANCE_INTERVAL: 1.000000          KMP_LOCK_KIND: default   KMP_MALLOC_POOL_INCR: 1M          KMP_NEXT_WAIT: 1024   KMP_NUM_LOCKS_IN_BLOCK: 1      KMP_PLAIN_BARRIER: '0,0'   KMP_PLAIN_BARRIER_PATTERN: 'linear,linear'   KMP_REDUCTION_BARRIER: '0,0'   KMP_REDUCTION_BARRIER_PATTERN: 'linear,linear'           KMP_SCHEDULE: 'static,greedy;guided,iterative'           KMP_SETTINGS: false   KMP_SPIN_BACKOFF_PARAMS: '4096,100'        KMP_STACKOFFSET: 64           KMP_STACKPAD: 0          KMP_STACKSIZE: 4M        KMP_STORAGE_MAP: false            KMP_TASKING: 2   KMP_TASKLOOP_MIN_TASKS: 0   KMP_TASK_STEALING_CONSTRAINT: 1   KMP_TEAMS_THREAD_LIMIT: 0    KMP_TOPOLOGY_METHOD: default            KMP_VERSION: false           KMP_WARNINGS: true        KMP_YIELD_CYCLE: true          KMP_YIELD_OFF: 1           KMP_YIELD_ON: 10    OMP_AFFINITY_FORMAT: '(null)'          OMP_ALLOCATOR: omp_default_mem_alloc       OMP_CANCELLATION: false     OMP_DEFAULT_DEVICE: 0   OMP_DISPLAY_AFFINITY: false        OMP_DISPLAY_ENV: false            OMP_DYNAMIC: false   OMP_MAX_ACTIVE_LEVELS: 2147483647   OMP_MAX_TASK_PRIORITY: 0             OMP_NESTED: false        OMP_NUM_THREADS: undefined             OMP_PLACES: undefined          OMP_PROC_BIND: undefined           OMP_SCHEDULE: 'static'          OMP_STACKSIZE: 4M     OMP_TARGET_OFFLOAD: DEFAULT       OMP_THREAD_LIMIT: 0               OMP_TOOL: enabled     OMP_TOOL_LIBRARIES: undefined d1.<>

…

On 3/30/2019 12:53 PM, John DelSignore wrote: Hi Hansang, Thanks for working on fixing these issues. I cloned the ompd-devices-50 branch this morning, built it, and ran some OMPD tests with TotalView. Unfortunately, the library crashed almost immediately, and I was not able to get as far as looking at the fix for issue #60. The specific reason was that the ompd_callbacks_t structure layout was fixed, but the ompd_get_api_version() still returns 0x05000602, which TotalView uses to "know" that it is dealing with the ompd-devices branch version of the library which was missing the read_string callback. So, since ompd-devices-50 branch is supposed to implement the OMPD v5.0 API, I tried changing the library to #define OMPD_VERSION to 201811 like it is supposed to, and rebuilt the library. But TotalView then tripped over issue #58, which is "[OMPD] The LLVM OMPD ompd_enumerate_icvs() and ompd_enumerate_states() functions do not allocate the strings they returns <#58>". TotalView crashed trying to free the string returned by ompd_enumerate_states(). That was supposed to have been fixed by Manoel on the ompd-devices-50 branch, but looking at the ompd_enumerate_states() function code, it was only /partially/ fixed... AFAICT, the code path for CUDA allocates the state name strings it returns, but the code path for the host does not. So, more work is required before I'll be able to test issue #60. Cheers, John D. On 3/29/2019 10:49 AM, Hansang Bae wrote: > > I pushed my patch to ompd-devices-50 (15c6dbd <15c6dbd>), but it will be great if someone can check if this is working correctly. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALxO7NgP_XVlVZ8UDmu3VvcU8vAQtJxdks5vbigIgaJpZM4bVbtT>. >

[hansangbae]

Hi John, Great to know that it works. Thank you! Thanks, Hansang From: John V. DelSIgnore, Jr. [mailto:[email protected]] Sent: Sunday, March 31, 2019 10:15 AM To: OpenMPToolsInterface/LLVM-openmp <[email protected]> Cc: Bae, Hansang <[email protected]>; Comment <[email protected]> Subject: Re: [OpenMPToolsInterface/LLVM-openmp] [OMPD] The LLVM OMPD does not have any support for display control variables (#60) Hi Hansang, I patched up the OMPD library and was able to get around the issues I mentioned to test the control variables. The TotalView output follows (it reformats the strings). AFAICT, it looks like it's working well. Cheers, John D. d1.<> domp -control_vars 1 (230160): KMP_ABORT_DELAY: 0 KMP_ADAPTIVE_LOCK_PROPS: '1,1024' KMP_AFFINITY: 'noverbose,warnings,disabled' KMP_ALIGN_ALLOC: 64 KMP_ALL_THREADPRIVATE: 0 KMP_ATOMIC_MODE: 2 KMP_A_DEBUG: 0 KMP_BLOCKTIME: 200 KMP_B_DEBUG: 0 KMP_CONSISTENCY_CHECK: none KMP_CPUINFO_FILE: undefined KMP_C_DEBUG: 0 KMP_DEBUG_BUF: false KMP_DEBUG_BUF_ATOMIC: false KMP_DEBUG_BUF_CHARS: 128 KMP_DEBUG_BUF_LINES: 512 KMP_DETERMINISTIC_REDUCTION: false KMP_DEVICE_THREAD_LIMIT: 0 KMP_DIAG: 0 KMP_DISP_NUM_BUFFERS: 7 KMP_DUPLICATE_LIB_OK: false KMP_DYNAMIC_MODE: undefined KMP_D_DEBUG: 0 KMP_E_DEBUG: 0 KMP_FORCE_REDUCTION: undefined KMP_FOREIGN_THREADS_THREADPRIVATE: true KMP_FORKJOIN_BARRIER: '0,0' KMP_FORKJOIN_BARRIER_PATTERN: 'linear,linear' KMP_FORKJOIN_FRAMES: true KMP_FORKJOIN_FRAMES_MODE: 3 KMP_F_DEBUG: 0 KMP_GTID_MODE: 3 KMP_HANDLE_SIGNALS: false KMP_HOT_TEAMS_MAX_LEVEL: 1 KMP_HOT_TEAMS_MODE: 0 KMP_INHERIT_FP_CONTROL: true KMP_INIT_AT_FORK: true KMP_INIT_WAIT: 2048 KMP_ITT_PREPARE_DELAY: 0 KMP_LOAD_BALANCE_INTERVAL: 1.000000 KMP_LOCK_KIND: default KMP_MALLOC_POOL_INCR: 1M KMP_NEXT_WAIT: 1024 KMP_NUM_LOCKS_IN_BLOCK: 1 KMP_PLAIN_BARRIER: '0,0' KMP_PLAIN_BARRIER_PATTERN: 'linear,linear' KMP_REDUCTION_BARRIER: '0,0' KMP_REDUCTION_BARRIER_PATTERN: 'linear,linear' KMP_SCHEDULE: 'static,greedy;guided,iterative' KMP_SETTINGS: false KMP_SPIN_BACKOFF_PARAMS: '4096,100' KMP_STACKOFFSET: 64 KMP_STACKPAD: 0 KMP_STACKSIZE: 4M KMP_STORAGE_MAP: false KMP_TASKING: 2 KMP_TASKLOOP_MIN_TASKS: 0 KMP_TASK_STEALING_CONSTRAINT: 1 KMP_TEAMS_THREAD_LIMIT: 0 KMP_TOPOLOGY_METHOD: default KMP_VERSION: false KMP_WARNINGS: true KMP_YIELD_CYCLE: true KMP_YIELD_OFF: 1 KMP_YIELD_ON: 10 OMP_AFFINITY_FORMAT: '(null)' OMP_ALLOCATOR: omp_default_mem_alloc OMP_CANCELLATION: false OMP_DEFAULT_DEVICE: 0 OMP_DISPLAY_AFFINITY: false OMP_DISPLAY_ENV: false OMP_DYNAMIC: false OMP_MAX_ACTIVE_LEVELS: 2147483647 OMP_MAX_TASK_PRIORITY: 0 OMP_NESTED: false OMP_NUM_THREADS: undefined OMP_PLACES: undefined OMP_PROC_BIND: undefined OMP_SCHEDULE: 'static' OMP_STACKSIZE: 4M OMP_TARGET_OFFLOAD: DEFAULT OMP_THREAD_LIMIT: 0 OMP_TOOL: enabled OMP_TOOL_LIBRARIES: undefined d1.<>

On 3/30/2019 12:53 PM, John DelSignore wrote: Hi Hansang, Thanks for working on fixing these issues. I cloned the ompd-devices-50 branch this morning, built it, and ran some OMPD tests with TotalView. Unfortunately, the library crashed almost immediately, and I was not able to get as far as looking at the fix for issue #60. The specific reason was that the ompd_callbacks_t structure layout was fixed, but the ompd_get_api_version() still returns 0x05000602, which TotalView uses to "know" that it is dealing with the ompd-devices branch version of the library which was missing the read_string callback. So, since ompd-devices-50 branch is supposed to implement the OMPD v5.0 API, I tried changing the library to #define OMPD_VERSION to 201811 like it is supposed to, and rebuilt the library. But TotalView then tripped over issue #58, which is "[OMPD] The LLVM OMPD ompd_enumerate_icvs() and ompd_enumerate_states() functions do not allocate the strings they returns <#58>". TotalView crashed trying to free the string returned by ompd_enumerate_states(). That was supposed to have been fixed by Manoel on the ompd-devices-50 branch, but looking at the ompd_enumerate_states() function code, it was only /partially/ fixed... AFAICT, the code path for CUDA allocates the state name strings it returns, but the code path for the host does not. So, more work is required before I'll be able to test issue #60. Cheers, John D. On 3/29/2019 10:49 AM, Hansang Bae wrote: > > I pushed my patch to ompd-devices-50 (15c6dbd <15c6dbd>), but it will be great if someone can check if this is working correctly. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <#60 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALxO7NgP_XVlVZ8UDmu3VvcU8vAQtJxdks5vbigIgaJpZM4bVbtT>. >

— You are receiving this because you commented. Reply to this email directly, view it on GitHub<#60 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AbU44plHTMdcBxH_3e35yJ_OimdD9fVwks5vcNDYgaJpZM4bVbtT>.