RE: [PATCH] symlookup: improves symbol lookup when a file is specified.

Tedeschi, Walfred
2017-10-09T14:06:41Z

-----Original Message-----
From: Pedro Alves [mailto:palves@redhat.com]
Sent: Monday, October 9, 2017 2:42 PM
To: Tedeschi, Walfred <walfred.tedeschi@intel.com>; qiyaoltc@gmail.com
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] symlookup: improves symbol lookup when a file is specified.

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

Pedro,

Thanks a lot for your review and sorry.

I should have started patching the test that was already existing in GDB and then moved to a new one.
I believe that a fixup was missed in the process. I will prepare the patch again!

Regards,
/Fred
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928