From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41649 invoked by alias); 9 Oct 2017 12:42:03 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 41242 invoked by uid 89); 9 Oct 2017 12:42:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Oct 2017 12:42:02 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E470A552DC; Mon, 9 Oct 2017 12:42:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E470A552DC Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves@redhat.com Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4A73D675C2; Mon, 9 Oct 2017 12:41:59 +0000 (UTC) Subject: Re: [PATCH] symlookup: improves symbol lookup when a file is specified. To: Walfred Tedeschi , qiyaoltc@gmail.com References: <1504687613-14649-1-git-send-email-walfred.tedeschi@intel.com> <1504687613-14649-3-git-send-email-walfred.tedeschi@intel.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Mon, 09 Oct 2017 12:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1504687613-14649-3-git-send-email-walfred.tedeschi@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-10/txt/msg00195.txt.bz2 On 09/06/2017 09:46 AM, Walfred Tedeschi wrote: > The provided patch adds a global lookup with higher priority for the > provided file. > > Usual symbol lookup from GDB follows linker logic. This is what is > desired most of the time. In the usage case a file is provided as > scope, so the lookup has to follow this priority. Failing in finding > the symbol at this scope usual path is followed. > > As test case it is presented two shared objects having a global variable > with the same name but comming from different source files. Without the > patch accessing them via the file scope returns the value seen in the > first loaded shared object. Using the patch the value defined in the file > scope is the one returned. > > One of the already existing test cases in print-file-var.exp starts to > fail after using this patch. In fact the value that the linker sees is > different then the one debugger can read from the shared object. In > this sense it looks like to me that the test has to be changed. > The fail is in the call: > print 'print-file-var-lib2.c'::this_version_id == v2 > In this case there also in both libraries the symbol this_version_id. > During load of the libraries linker resolves the symbol as the first one > loaded and independent of the scope symbol will have the same value, as > defined in the first library loaded. > However, when defining the scope the value should represent the value > in that context. Diferent evaluations of the same symbols might also better > spot the issue in users code. > > - I haven't changed the test because I wanted to hear the community > thought on the subject. I'm not sure I understand the description above, so I'd like to try this locally to try to understand it better, but the test fails for me: (gdb) break print-file-var-dlopen-main.c:51 Breakpoint 2 at 0x400751: file /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/print-file-var-dlopen-main.c, line 51. (gdb) PASS: gdb.base/print-file-var-dlopen.exp: breapoint past v1 & v2 initialization continue Continuing. [Inferior 1 (process 11534) exited with code 01] (gdb) FAIL: gdb.base/print-file-var-dlopen.exp: continue to STOP marker (the program exited) The program exits because dlopen failed. Is there a reason the test is trying to use LD_LIBRARY_PATH instead of compiling the program with the shared library file name defined as an absolute path via additional_flags=-DXXXX like seemingly every other dlopen test does? > + > + dummy (); /* STOP */ > + dlclose (lib1); > + dlclose (lib2); > + if (v1 != 104) > + return 1; > + /* The value returned by get_version_2 depends on the target system. */ > + if (v2 != 104 || v2 != 203) > + return 2; > + > + return 0; > +} > + I tried to fix the above to get it running for me, but then noticed other things clearly bad with the test. This certainly can't have passed as is for you. For example, the test reuses these source files from the print-file-var.exp test: +set lib1 "print-file-var-lib1" +set lib2 "print-file-var-lib2" But then looks for "get_version" symbols in them, but there's no such symbols...: + *(int **) (&get_version1) = dlsym (lib1, "get_version"); + *(int **) (&get_version2) = dlsym (lib2, "get_version"); While here: > + > +gdb_test "print 'print-file-var-dlopen-lib1.c'::this_version_id == v1" \ > + " = 1" it looks like the test actually wanted to use some different source files, but there's no print-file-var-dlopen-lib1.c included in the patch. Walfred, please double check what you intend to submit. Pedro Alves