From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 769A56ECDB; Tue, 22 Mar 2022 21:31:31 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 769A56ECDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1647973891; bh=t7DGvtrTYluHfm6KZQvm870GIAFQ9c5Jr5H5S8Erh+E=; h=To:Date:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=jwpKBcZroC77KRb9+NIIYXfbpDugEKtDpU7H3CKH339rBBusp7dvqKMHeSUEJiFNy c58UqjECYAXW03oUVZJ8eAZOyXIYcJd52yIG5eSpQvOs2sFanInWVnJwS4EL3JojDq LOwdZ8XPfmrd9MTD3/OvXu/rqAt/DhuS6XVyVToE= Received: from mail-lj1-f171.google.com (mail-lj1-f171.google.com [209.85.208.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 5CCFA6ECDB for ; Tue, 22 Mar 2022 21:31:30 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 5CCFA6ECDB Received: by mail-lj1-f171.google.com with SMTP id g24so23951586lja.7 for ; Tue, 22 Mar 2022 11:31:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=yG3U25VsSGhfC5463mslHW6uu2uYrnY3IU1bP7TKuxo=; b=Nj5rD+KfVZJVwuRab1SdTy3kUUBXcbGL02bXis/DCyAkvWIBbfe6hoDYosSOmcdLAv rZL4Tfmxj1AtjTcVNp/05J8oZGGjudOvbCAMfqi957teWv/ne3VmrHJmWIuzqcj00+TA HeGLWB7HIoRGeQCKCkaVu67cDRqTZZzjfwdAswm/uzHS9sVnTMw9ALdtMWsLOEoyzAXG zwU6hR8Ji6s+YuxSqX+ktmV/MmCcryjqLQRLGZGKWHKY9e+a2scUqsfgoqtI9UP0HM6Q 9A/w+U3JBvjQm0jfo2chF5lD+YzHQZKR9enh3CgQk/bwoBpLZ4HE+qcB6WnQt8en0U7C gskg== X-Gm-Message-State: AOAM5300lYwxmFEJ3HI2wfUspUyf8Dt/3GhZrZrjwZ/O1sOFVyzyLfax WQap/FJmjijSSeA/sJVMas/cIT3bCxLBkA== X-Google-Smtp-Source: ABdhPJxUYhTc0sMvuV9CcQSMPmfRXDMxZUYgLPtfI3Dc3HIkIc9bOcLgEOlRQWooB67nRFjI0viwMw== X-Received: by 2002:a2e:6804:0:b0:245:f269:618 with SMTP id c4-20020a2e6804000000b00245f2690618mr19195125lja.198.1647973889015; Tue, 22 Mar 2022 11:31:29 -0700 (PDT) Received: from localhost.localdomain ([93.175.11.199]) by smtp.gmail.com with ESMTPSA id p6-20020a056512234600b0044a0a2b061esm1772996lfu.82.2022.03.22.11.31.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Mar 2022 11:31:28 -0700 (PDT) X-Google-Original-From: Maxim Kokryashkin To: tarantool-patches@dev.tarantool.org, imun@tarantool.org, skaplun@tarantool.org Date: Tue, 22 Mar 2022 21:31:23 +0300 Message-Id: X-Mailer: git-send-email 2.35.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: [Tarantool-patches] [PATCH luajit v6 0/2] memprof: C-symbols resolving X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Maxim Kokryashkin via Tarantool-patches Reply-To: Maxim Kokryashkin Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Changes in v6: - Fixed comments as per review by Sergey - Added tests for newly loaded symbols resolution --- >> +#include >> +#include > > and are included inside lj_def.h, so this include is excess. Relying on includes in other header files is a terrible practice. Ignoring. >> +-- Parse a single entry in a symtab: .so library >> +local function parse_sym_cfunc(reader, symtab) >> + local addr = reader:read_uleb128() >> + local name = reader:read_string() >> + >> + symtab.cfunc = avl.insert(symtab.cfunc, addr, { >> + name = name >> + }) >> +end > > Side note: Does it sufficient for all 3 cases mentioned above as far as > format is the same? It is obvious that it works for the first two cases so I am going to provide explanation only for the last one. In the last case, symtab contains an addr and a name of a shared library. When allocation occurs in a function from this library, its address is dumped into the event stream. Later on, during the process of resolution, parser searches the name of the function in AVL tree. Since it uses the 'upper_bound' for that, the only match for the mentioned function is the entry for the shared object, from which it was loaded. Maxim Kokryashkin (2): memprof: extend symtab with C-symbols memprof: enrich symtab with newly loaded symbols Makefile.original | 2 +- src/lj_memprof.c | 407 +++++++++++++++++- src/lj_memprof.h | 15 +- test/tarantool-tests/CMakeLists.txt | 1 + .../gh-5813-resolving-of-c-symbols.test.lua | 60 +++ .../CMakeLists.txt | 2 + .../testresolving.c | 19 + test/tarantool-tests/tools-utils-avl.test.lua | 54 +++ tools/CMakeLists.txt | 2 + tools/memprof.lua | 5 + tools/memprof/parse.lua | 19 + tools/utils/avl.lua | 114 +++++ tools/utils/symtab.lua | 27 +- 13 files changed, 715 insertions(+), 12 deletions(-) create mode 100644 test/tarantool-tests/gh-5813-resolving-of-c-symbols.test.lua create mode 100644 test/tarantool-tests/gh-5813-resolving-of-c-symbols/CMakeLists.txt create mode 100644 test/tarantool-tests/gh-5813-resolving-of-c-symbols/testresolving.c create mode 100644 test/tarantool-tests/tools-utils-avl.test.lua create mode 100644 tools/utils/avl.lua -- 2.35.1