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

[Pedro Alves <palves at redhat dot com>]

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