This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: gdb.base/print-file-var.exp false PASS [Re: [RFA] choose symbol from given block's objfile first.]
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