[Openmp-dev] [Openmp-commits] Intel OpenMP Runtime & LLVM : RUNTIME FUNCTION (newly written) CALL gets " Undefined Reference"
Rezaul Karim Raju via Openmp-dev
openmp-dev at lists.llvm.org
Wed Jan 20 18:45:39 PST 2016
Hi James:
Thank you very much for your reply.
If I am right to address as you said -
the shared library is being linked
is: -L/home/XXX/opt/libomp_oss/exports/lin_32e/lib/ -L. -liomp5
Running *nm *command on *libiomp5.so *shows: (same symbol format as for
omp_set_num_threads runtime routine call)
000000000001b380 t __*kmp_api_omp_set_my_threads*
000000000001c050 t __*kmp_api_omp_set_my_threads_*
and my runtime gets linked and it reflects the modifications.
Secondly, about stylistic issue: yes I will definitely follow the standard
practice. thanks again for your nice explanations.
One more thing, I am just wondering: I see in intel openMP source code
contains a file name <*dllexports*> where dllexports file contains,
# Deprecated entry points (numbers are reserved):
omp_set_num_threads 717
ompc_set_num_threads 724
*Is this something significant, I need to care about..? *
Appreciate your invaluable feedback.
Best regards,
- Raju
On Wed, Jan 20, 2016 at 4:07 AM, Cownie, James H <james.h.cownie at intel.com>
wrote:
> At a guess you’re not linking against the runtime you have modified.
>
> Check exactly which shared library is being linked, and then use nm on it
> to see what symbols it contains.
>
>
>
> As a second, stylistic, issue: please don’t name your new, non-standard
> function “omp_*anything”. *Such names should be reserved for functions
> from the OpenMP standard. Historically other, non-standard, entrypoints to
> the runtime have used the “kmp_” prefix. Either use that, or choose your
> own, but having non-standard functionality appear to be standard is asking
> for trouble.
>
>
>
> -- Jim
>
> James Cownie <james.h.cownie at intel.com>
> SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)
>
> Tel: +44 117 9071438
>
>
>
> *From:* Openmp-commits [mailto:openmp-commits-bounces at lists.llvm.org] *On
> Behalf Of *Rezaul Karim Raju via Openmp-commits
> *Sent:* Wednesday, January 20, 2016 3:33 AM
> *To:* openmp-dev at lists.llvm.org; openmp-commits at lists.llvm.org
> *Subject:* Re: [Openmp-commits] [Openmp-dev] Intel OpenMP Runtime & LLVM
> : RUNTIME FUNCTION (newly written) CALL gets " Undefined Reference"
>
>
>
> Hello everyone,
>
>
>
> I was writing a new runtime routine to integrate with intel openMP
> runtime. My function call is pretty like the calling of,
> "omp_set_num_threads(4);"
>
>
>
> *omp_set_my_threads(8);*
>
> *omp_set_data_bind(&bindvariable);*
>
>
>
> *my goal here is to set/provide (to runtime) a integer value and an
> address location through runtime routine call. *
>
>
>
> *What I did: *
>
> I have made a shadow copy like the omp_set_num_thread() function
> implementation; it generates the function prototype as below *in the
> omp.h header file:*
>
> extern void __KAI_KMPC_CONVENTION omp_set_num_threads (int);
>
>
>
> extern void __KAI_KMPC_CONVENTION omp_set_data_bind (void *);
>
> extern void __KAI_KMPC_CONVENTION omp_set_my_threads (int);
>
>
>
>
>
> and in my program I am calling like:
>
>
>
> int main(){
>
> ....
>
>
>
> omp_set_num_threads(4);
>
>
>
> *omp_set_my_threads(8);*
>
> *omp_set_data_bind(&bindvariable);*
>
> #pragma omp parallel
>
> {
>
> ---
>
> }
>
>
>
> }
>
>
>
> Compile with CLANG (LLVM) the IR code generates the function call as: *call
> void @omp_set_my_threads(i32 8)*
>
>
>
> *but while I am going to compile it gives me the error as: *
>
>
>
> */tmp/XXXa.o: In function `main':*
>
> *XXXa.c:(.text+0x403): undefined reference to `omp_set_my_threads'*
>
> *clang-3.5: error: linker command failed with exit code 1 *
>
>
>
> *CAN YOU PLEASE COMMENT WHAT I AM MISSING HERE ..? *
>
>
>
> *thank you very much in advance..!!*
>
>
>
> *- Raju*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Tue, Dec 15, 2015 at 11:02 AM, Churbanov, Andrey <
> Andrey.Churbanov at intel.com> wrote:
>
> Hello,
>
>
>
> If you print information from __kmp_task_alloc() function, you cannot find
> your data in the structures.
>
> The reason is that this routine only allocates space requested by the
> compiler and initializes its own runtime-related info, and if you examine
> the space allocated for shareds you can only find uninitialized memory
> there.
>
>
>
> The addresses of shared variables are put into allocated memory by the
> compiler later, AFTER the __kmp_task_alloc() call. E.g. the array of
> shareds should already be initialized in the __kmp_omp_task() call. But I
> doubt you can rely on particular location of any shared variable in the
> array of shareds, it is compiler’s decision where to place your particular
> variable’s address, and it may or may not be the first in the array of
> shareds. E.g. compiler can insert its own auxiliary data before user’s data.
>
>
>
> Regards,
>
> Andrey
>
>
>
> *From:* Openmp-dev [mailto:openmp-dev-bounces at lists.llvm.org] *On Behalf
> Of *Rezaul Karim Raju via Openmp-dev
> *Sent:* Tuesday, December 15, 2015 8:47 AM
> *To:* openmp-dev at lists.llvm.org; openmp-commits at lists.llvm.org
> *Subject:* [Openmp-dev] Intel OpenMP Runtime & LLVM [kmp_tasking.c]:
> Problem to access SHARED VARIABLE DATA LOCATION
>
>
>
> Dear concern,
>
>
>
> Please consider the source code(openmp c code) snippet as below:
>
> --- code snippet ---
>
> int a1, b1, c1, N;
>
>
>
> Initially address of a1:= 0x7fff9bd58304
>
> omp_set_num_threads(2);
>
> #pragma omp parallel
>
> {
>
> #pragma omp single
>
> {
>
> // task one: a1=b1+c1;
>
> #pragma omp task shared(a1)
> firstprivate(b1,c1)
>
> {
>
> a1 = a1 + b1 + c1;
>
> }
>
> }
>
> }
>
>
>
> In the above openMP code task construct contains shared variable (a1), I
> AM INTERESTED TO FIND THE SHARED VARIABLE OF TASK DATA IN RUNTIME TASK
> ALLOCATION.
>
>
>
> I am looking into the source code of Intel OpenMP Runtime, my openmp code
> is compiled with LLVM. In the LLVM IR, @__kmpc_omp_task_alloc( ...) calls
> runtime function kmp_task_alloc(), source code is here: under the <src>
> directory, Kmp_tasking.c
>
>
>
>
>
> I am trying to access the "shared variable data location for a task" which
> is as below:
>
> kmp_task_t *
>
> __kmp_task_alloc(...){
>
>
>
> kmp_task_t *task;
>
> kmp_taskdata_t *taskdata;
>
>
>
> // Calculate shared structure offset including padding after kmp_task_t
> struct
>
> // to align pointers in shared struct
>
> shareds_offset = sizeof( kmp_taskdata_t ) + sizeof_kmp_task_t;
>
> shareds_offset = __kmp_round_up_to_val( shareds_offset, sizeof( void *
> ));
>
>
>
> // Avoid double allocation here by combining shareds with taskdata
>
> #if USE_FAST_MEMORY
>
> taskdata = (kmp_taskdata_t *) __kmp_fast_allocate( thread,
> shareds_offset + sizeof_shareds );
>
> #else /* ! USE_FAST_MEMORY */
>
> taskdata = (kmp_taskdata_t *) __kmp_thread_malloc( thread,
> shareds_offset + sizeof_shareds );
>
> #endif /* USE_FAST_MEMORY */
>
>
>
> task = KMP_TASKDATA_TO_TASK(taskdata);
>
>
>
> if (sizeof_shareds > 0) {
>
> // Avoid double allocation here by combining shareds with taskdata
>
> task->shareds = & ((char *) taskdata)[ shareds_offset ];
>
> printf("task->shareds address original:= %p address of pointer it points
> to := %p\n", & ((char *) taskdata)[ shareds_offset ], *task->shareds);
>
>
>
> }
>
> }
>
>
>
> here,
>
> typedef struct kmp_task { /* GEH: Shouldn't this be
> aligned somehow? */
>
> void * shareds; /**< pointer to block of
> pointers to shared vars */
>
> }
>
>
>
> But, task->shareds = & ((char *) taskdata)[ shareds_offset ];
> which is a pointer to block of pointers to shared variables, if I print the
> shared variable pointing address(which should be the address of a1:=
> 0x7fff9bd58304)
>
> IT PRINTS DIFFERENT ADDRESS: <0x1fe0ef0>
>
>
>
> NEED TO GET THE ADDRESS OF TASK'S SHARED VARIABLE ADDRESS FROM RUNTIME.
>
>
>
> appreciate your comment and help. Thanking you.
>
> ------------------------
>
> RaJu, Rezaul Karim
> Graduate Student (PhD) | Computer Science | University of Houston
>
> Research in High Performance Computing Tools
>
> Houston, Texas-77004
>
>
> --------------------------------------------------------------------
> Joint Stock Company Intel A/O
> Registered legal address: Krylatsky Hills Business Park,
> 17 Krylatskaya Str., Bldg 4, Moscow 121614,
> Russian Federation
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
>
>
>
> --
>
> ------------------------
>
> RaJu, Rezaul Karim
> Graduate Student (PhD) | Computer Science | University of Houston
>
> Research in High Performance Computing Tools
>
> Houston, Texas-77004
>
> ---------------------------------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
--
------------------------
RaJu, Rezaul Karim
Graduate Student (PhD) | Computer Science | University of Houston
Research in High Performance Computing Tools
Houston, Texas-77004
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20160120/0170cf7b/attachment-0001.html>
More information about the Openmp-dev
mailing list