Re: gdb.base/print-file-var.exp false PASS [Re: [RFA] choose symbol from given block's objfile first.]

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Fri, 18 May 2012 19:17:08 +0200, Joel Brobecker wrote:
> I really don't know how to read your last sentence, and I am going to
> pretend you did not write it. Please correct me if I misunderstood
> what you are trying to imply.

I think it is clear that if GDB commands prints value X of variable Y then the
inferior program (either running standalone or under GDB) should also evaluate
variable Y as value X.

$ gdb.base/print-file-var-main ;echo $?
0

Therefore inferior sees 'print-file-var-lib2.c'::this_version_id as 104
> > > +  if (get_version_2 () != 104)
> > > +    return 2;
as otherwise the executable would return 2 (and not 0).

But GDB PASSes if 'print-file-var-lib2.c'::this_version_id is read as 203.
I do not understand this discrepancy between print-file-var.exp and
print-file-var-main.c.


> On the other hand, on Windows, with the same code, the function
> returns 203.  So the code is not portable.

I did not remember the MS-Windows platform behavior (Pedro has stated it).
In such case this program returns code 2 (and not 0) on MS-Windows?



> I wonder how things are working on GNU/Linux, because the two shared
> libraries are linked independently, and then the main executable
> does not reference the global variable at all.

As the libraries are build with -fPIC they use .got references:
0000000000000670 <get_version_1>:
[...]
 674:   48 8b 05 95 02 20 00    mov    0x200295(%rip),%rax        # 200910 <_DYNAMIC+0x1e0>
 67b:   8b 00                   mov    (%rax),%eax

Section Headers:
  [Nr] Name              Type            Address          Off    Size   ES Flg Lk Inf Al
  [22] .data             PROGBITS        0000000000200950 000950 000004 00  WA  0   0  4
  [20] .got              PROGBITS        0000000000200900 000900 000030 08  WA  0   0  8

Relocation section '.rela.dyn' at offset 0x450 contains 9 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
0000000000200910  0000000d00000006 R_X86_64_GLOB_DAT      0000000000200950 this_version_id + 0
 - in .got

Symbol table '.dynsym' contains 14 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
    13: 0000000000200950     4 OBJECT  GLOBAL DEFAULT   22 this_version_id
 - in .data

And therefore for the first library ld.so resolves the .got reference into
itself but for the second library the .got reference points to the first library's variable.


> I don't know what to do. I can remove the testcase entirely, or
> we can test the target and adjust the expected output based on
> that.

I think it depends how complete/good fix ends up checked in GDB.


> This is still not going to help with the GDB side of things. But
> I don't think that this is a regression. I don't think we have any
> way of knowing which instance of the variable to pick.

This check-in regressed the C example from:
	http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40040

cat >clib.c <<EOH
int var = 1;
int func (void) { return var; }
EOH
cat >cmain.c <<EOH
extern int var; extern int func (void); int main (void) {
  var = 2;
  return var == func () ? 0 : 1; }
EOH
C="gcc -Wall -g"; $C -o clib.so -shared -fPIC clib.c; $C -o cmain cmain.c ./clib.so
gdb ./cmain
(gdb) b func
(gdb) run
Breakpoint 1, func () at clib.c:6
6   return var;
(gdb) p var
before - matches inferior:
$1 = 2
current - does not match inferior:
$1 = 1


Thanks,
Jan