From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 9EB71385741C for ; Fri, 8 Apr 2022 22:38:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9EB71385741C Received: by mail-ed1-x52e.google.com with SMTP id b15so11597355edn.4 for ; Fri, 08 Apr 2022 15:38:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=svy+N1LnsVUuvAqj0lD9BRUiYub17WjPbcWHSdCyybA=; b=PylNb3JWqRcReoJqdKUAB8WaFHFKu8vDB62YNSdOqqhtlc/rVBt1Xi+znzBC2MX9QR F/c0xUmg4yDSKguaNk483cx2Y7dHcayJpvic70ac23G/1R9XkcYA10/JOph0JqDACYQm /P2A6kOJ5Cs1e7L5L7mGgmH7F2CVirajcia7HzUV/RjeRqnFC/xpAqtc05SlX8u51H4o 8K+eG5zu7UgjlSmO4rwDImK2LKFTPOvlDCTRpEREqVp2fyW7ZQfP1UgkCwPfy8CEWXmj DhhrKifswD+MuLdPvHsc+QCzND6WaEkbRmAlu+hZcPaSSBmwMJKhVU1N7R1cTcodarSW qzGw== X-Gm-Message-State: AOAM533wmalq15nJP7fbgFR8C/X5P0z7A78clLJPCF44ltRzY4JX8tpx AKLA1YBe9dPX6gACc165G6pLk2Nr3yWUy557Ai+8TQs0xP80eA== X-Google-Smtp-Source: ABdhPJzwn+fAsdooFnZWp5Suvc3mt74ayBVUxFrdB4Wb6Y99kWFTy9zUKI1JVxEDWATotfYBKf/RUqkgSFDxvXjBsO0= X-Received: by 2002:a05:6402:510c:b0:419:3fe5:15f with SMTP id m12-20020a056402510c00b004193fe5015fmr21935378edd.274.1649457502281; Fri, 08 Apr 2022 15:38:22 -0700 (PDT) MIME-Version: 1.0 References: <83CFFA00-57E0-417C-8F3B-393F7FB92734@hxcore.ol> In-Reply-To: <83CFFA00-57E0-417C-8F3B-393F7FB92734@hxcore.ol> From: Ahmed Sayed Mousse Date: Sat, 9 Apr 2022 00:38:11 +0200 Message-ID: Subject: FW: ompd_get_thread_id in OMPD implementation To: gcc@gcc.gnu.org Cc: jakub@redhat.com X-Spam-Status: No, score=-0.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2022 22:38:26 -0000 Sorry for the late reply. I did check gomp_thread_self but I'm still not sure about what I should do, maybe because I lack experience/knowledge. Here is where my thinking is going right now and I hope you tell me if I'm wrong. in gomp_thread_to_pthread_t there are 4 possible outputs 1 - if LIBGOMP_USE_PTHREADS is enabled { first pthread_self() if the thread calling is the same thread as the function input. or gomp_thread->handle in case GOMP_NEEDS_THREAD_HANDLE is enabled. or pthread_self () + ((uintptr_t) input_thread - (uintptr_t) calling_thread) } 2 -if LIBGOMP_USE_PTHREADS not enabled - empty struct casted to a pthread_t currently think i should check for the GOMP_NEED_THREAD_HANDLE, if it's enabled i extract the pthread_t from the gomp_thread handle given in the function and return that. If it's not enabled then I return an empty struct or an rc_unspported return code. Note: The openmp specification doesn't really tell me how things should be done so I get confused a lot and I think I have a misunderstanding of the function. I would appreciate it a lot if I get any directions to where I can increase my knowledge around this part. *From: *Ahmed Sayed Mousse *Sent: *Wednesday, March 23, 2022 7:23 PM *To: *gcc-help@gcc.gnu.org *Cc: *jakub@redhat.com *Subject: *ompd_get_thread_id in OMPD implementation Hi everyone, I was doing a research to help me implement the function =E2=80=9Compd_get_thread_id=E2=80=9D from the OpenMP API specification unde= r section 20.5.5.5. In this function I need to return a native thread identifier and from research I found that it=E2=80=99s a =E2=80=9Cpthread_t=E2=80=9D handle whi= ch exists inside a struct named =E2=80=9Cgomp_thread=E2=80=9D of the =E2=80=9Clibgomp.h=E2=80= =9D file. The problem is that this handle isn=E2=80=99t always defined and to show what I mean look at th= e code below. struct gomp_thread { =E2=80=A6.. #if defined(LIBGOMP_USE_PTHREADS) \ && (!defined(HAVE_TLS) \ || !defined(__GLIBC__) \ || !defined(USING_INITIAL_EXEC_TLS)) #define GOMP_NEEDS_THREAD_HANDLE 1 pthread_t handle; #endif }; I use a macro to calculate the offset of this handle and use the this offset to get it from memory and I thought I would just check for GOMP_NEEDS_THREAD_HANDLE before trying to calculate this offset but It still causes errors and also if that handle isn=E2=80=99t defined then what= should I return as a native identifier? Thanks for help.