From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 567D84366A for ; Mon, 4 Dec 2023 10:45:58 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D2A0D40294; Mon, 4 Dec 2023 10:45:57 +0100 (CET) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by mails.dpdk.org (Postfix) with ESMTP id B43CF4028C for ; Mon, 4 Dec 2023 10:45:56 +0100 (CET) Received: from kwepemi500009.china.huawei.com (unknown [172.30.72.57]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4SkJZK209kz14L65; Mon, 4 Dec 2023 17:40:57 +0800 (CST) Received: from dggpeml500020.china.huawei.com (7.185.36.88) by kwepemi500009.china.huawei.com (7.221.188.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.35; Mon, 4 Dec 2023 17:45:53 +0800 Received: from dggpeml500020.china.huawei.com ([7.185.36.88]) by dggpeml500020.china.huawei.com ([7.185.36.88]) with mapi id 15.01.2507.035; Mon, 4 Dec 2023 17:45:53 +0800 From: "jiangheng (G)" To: Matan Azrad , Slava Ovsiienko , "orika@nvidia.com" , "suanmingm@nvidia.com" , "users@dpdk.org" Subject: when link librte_net_mlx5.so and use gdb, my program can't get environment variable Thread-Topic: when link librte_net_mlx5.so and use gdb, my program can't get environment variable Thread-Index: Adomk3S/8GcBsSaaROeZLMMcpE3/Qg== Date: Mon, 4 Dec 2023 09:45:52 +0000 Message-ID: <282c6e61a40f40ab81d8d14adce84f1e@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.136.117.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org Environment: [root@localhost jh]# cat /etc/centos-release CentOS Linux release 8.5.2111 root@localhost jh]# uname -r 4.18.0-348.el8.x86_64 [root@localhost jh]# rpm -qa gcc gcc-8.5.0-3.el8.x86_64 [root@localhost jh]# rpm -qa dpdk dpdk-21.11-3.el8.x86_64 Reproduction Procedure: 1. We need create test.c and init.c [root@localhost jh]# cat init.c #include #include #include __attribute__ ((constructor)) void init(void) { char *enval =3D NULL; enval =3D getenv("LD_PRELOAD"); printf("enval LD_PRELOAD : %s\n", enval); return; } [root@localhost jh]# cat test.c #include int main(int argc, char **argv) { printf("Hello World\n"); return 0; } 2. Build test.c gcc test.c -o test 3. Build init.c as so in three cases: 3.1 only link librte_eal.so gcc --shared -fPIC -lrte_eal init.c -o libinit.so 3.2 link librte_eal.so and librte_net_i40e.so gcc --shared -fPIC -lrte_eal -lrte_net_i40e init.c -o libinit_i40e.so 3.3 link librte_eal.so and librte_net_mlx5.so gcc --shared -fPIC -lrte_eal -lrte_net_mlx5 init.c -o libinit_mlx5.so 4. run test using gdb and LD_PRELOAD=20 4.1 : libinit.so links only librte_eal.so=20 LD_PRELOAD=3D./libinit.so gdb ./test =20 (gdb) r enval LD_PRELOAD : ./libinit.so enval LD_PRELOAD : ./libinit.so (I don't know why the constrctor function= is executed twice.) Hello World 4.2 libinit.so links librte_eal.so and librte_net_i40e.so LD_PRELOAD=3D./libinit_i40e.so gdb ./test enval LD_PRELOAD : ./libinit_i40e.so enval LD_PRELOAD : ./libinit_i40e.so (I don't know why the constrctor fu= nction is executed twice.) Hello World 4.3 4.3 libinit.so links librte_eal.so and librte_net_mlx5.so LD_PRELOAD=3D./libinit_mlx5.so gdb ./test enval LD_PRELOAD : (null) // ? ? ? ? enval LD_PRELOAD : ./libinit_mlx5.so Hello World After libinit.so is linked to librte_net_mlx5.so, the symptom when the gdb = is used to execute the program is different from the preceding two cases. T= he value of LD_PRELOAD obtained is NULL for the first time. Have you ever had the same problem? Looking forward to your favourable reply. Thanks