* [python] FYI a testcase FAIL: test Frame.read_var_value - error @ 2009-03-03 19:48 Jan Kratochvil 2009-03-04 17:02 ` Thiago Jung Bauermann 0 siblings, 1 reply; 10+ messages in thread From: Jan Kratochvil @ 2009-03-03 19:48 UTC (permalink / raw) To: archer Hi, FYI there is now on [archer-tromey-python] (no merges, just this branch): FAIL: gdb.python/python-frame.exp: test Frame.read_var_value - error I know nothing more, Jan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [python] FYI a testcase FAIL: test Frame.read_var_value - error 2009-03-03 19:48 [python] FYI a testcase FAIL: test Frame.read_var_value - error Jan Kratochvil @ 2009-03-04 17:02 ` Thiago Jung Bauermann 2009-03-05 22:58 ` Jan Kratochvil 0 siblings, 1 reply; 10+ messages in thread From: Thiago Jung Bauermann @ 2009-03-04 17:02 UTC (permalink / raw) To: Jan Kratochvil; +Cc: archer Hi Jan, El mar, 03-03-2009 a las 20:47 +0100, Jan Kratochvil escribió: > FYI there is now on [archer-tromey-python] (no merges, just this branch): > FAIL: gdb.python/python-frame.exp: test Frame.read_var_value - error Thanks for the heads up. I just tested on ppc-linux, ppc64-linux and i386-linux but python-frame.exp passes on all of them. Would you mind sending the excerpt from testsuite/gdb.log for this failure? -- []'s Thiago Jung Bauermann IBM Linux Technology Center ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [python] FYI a testcase FAIL: test Frame.read_var_value - error 2009-03-04 17:02 ` Thiago Jung Bauermann @ 2009-03-05 22:58 ` Jan Kratochvil 2009-03-06 3:35 ` Thiago Jung Bauermann 0 siblings, 1 reply; 10+ messages in thread From: Jan Kratochvil @ 2009-03-05 22:58 UTC (permalink / raw) To: Thiago Jung Bauermann; +Cc: archer On Wed, 04 Mar 2009 18:01:59 +0100, Thiago Jung Bauermann wrote: > El mar, 03-03-2009 a las 20:47 +0100, Jan Kratochvil escribió: > > FYI there is now on [archer-tromey-python] (no merges, just this branch): > > FAIL: gdb.python/python-frame.exp: test Frame.read_var_value - error > > Thanks for the heads up. I just tested on ppc-linux, ppc64-linux and > i386-linux but python-frame.exp passes on all of them. As suggested by Tom could you please try to get x86_64 access on the GCC farm? http://gcc.gnu.org/wiki/CompileFarm > Would you mind sending the excerpt from testsuite/gdb.log for this failure? python print 'result =', f0.read_var ('b') result = {i = {0, 1068498944}, d = 0.0625} (gdb) FAIL: gdb.python/python-frame.exp: test Frame.read_var - error Regards, Jan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [python] FYI a testcase FAIL: test Frame.read_var_value - error 2009-03-05 22:58 ` Jan Kratochvil @ 2009-03-06 3:35 ` Thiago Jung Bauermann 2009-03-06 13:25 ` [python] [approval request] " Jan Kratochvil 0 siblings, 1 reply; 10+ messages in thread From: Thiago Jung Bauermann @ 2009-03-06 3:35 UTC (permalink / raw) To: Jan Kratochvil; +Cc: archer El jue, 05-03-2009 a las 23:58 +0100, Jan Kratochvil escribió: > On Wed, 04 Mar 2009 18:01:59 +0100, Thiago Jung Bauermann wrote: > > El mar, 03-03-2009 a las 20:47 +0100, Jan Kratochvil escribió: > > > FYI there is now on [archer-tromey-python] (no merges, just this branch): > > > FAIL: gdb.python/python-frame.exp: test Frame.read_var_value - error > > > > Thanks for the heads up. I just tested on ppc-linux, ppc64-linux and > > i386-linux but python-frame.exp passes on all of them. > > As suggested by Tom could you please try to get x86_64 access on the GCC farm? > http://gcc.gnu.org/wiki/CompileFarm I have a personal x86_64 box running Debian unstable and I still don't see the failure there. Do you see this in x86_64 machines in the compile farm? If so, I can try to get access there to analyse the problem. > > Would you mind sending the excerpt from testsuite/gdb.log for this failure? > > python print 'result =', f0.read_var ('b') > result = {i = {0, 1068498944}, d = 0.0625} > (gdb) FAIL: gdb.python/python-frame.exp: test Frame.read_var - error This is weird. python-frame.c doesn't have a b variable in f2, which is where the testcase stops for the tests. It does have an argument named b in f1, but it surely doesn't have such type. It's a plain int. -- []'s Thiago Jung Bauermann IBM Linux Technology Center ^ permalink raw reply [flat|nested] 10+ messages in thread
* [python] [approval request] Re: FYI a testcase FAIL: test Frame.read_var_value - error 2009-03-06 3:35 ` Thiago Jung Bauermann @ 2009-03-06 13:25 ` Jan Kratochvil 2009-03-06 14:22 ` Thiago Jung Bauermann 2009-03-06 23:41 ` Tom Tromey 0 siblings, 2 replies; 10+ messages in thread From: Jan Kratochvil @ 2009-03-06 13:25 UTC (permalink / raw) To: Thiago Jung Bauermann; +Cc: archer On Fri, 06 Mar 2009 04:35:18 +0100, Thiago Jung Bauermann wrote: > El jue, 05-03-2009 a las 23:58 +0100, Jan Kratochvil escribió: > > python print 'result =', f0.read_var ('b') > > result = {i = {0, 1068498944}, d = 0.0625} > > (gdb) FAIL: gdb.python/python-frame.exp: test Frame.read_var - error > > This is weird. python-frame.c doesn't have a b variable in f2, which is > where the testcase stops for the tests. It does have an argument named b > in f1, but it surely doesn't have such type. It's a plain int. I could have investigated it more first (and curious you do not have glibc-debuginfo installed): (gdb) info addr b Symbol "b" is static storage at address 0x33f124d198. (gdb) info sym 0x33f124d198 inv16 in section .rodata of /lib64/libm.so.6 [`inv16' is just shared common rodata with `b'] IMO GDB should be strictly following the c++ lookup scopes. This `b' lookup would therefore require to type `s_atan.c:b' or `atnat.h:b' when some current frame or current_source_symtab are in a different file. OK to checkin the patch below? glibc-20081031T2102/sysdeps/ieee754/dbl-64/atnat.h:113: static const number /**/ b = {{0x00000000, 0x3fb00000} }, /* 1/16 */ Compilation Unit @ offset 0x8ac8: Length: 0x7cb (32-bit) Version: 2 Abbrev Offset: 10308 Pointer Size: 8 <0><8ad3>: Abbrev Number: 1 (DW_TAG_compile_unit) <8ad4> DW_AT_producer : (indirect string, offset: 0x12e): GNU C 4.3.2 20081105 (Red Hat 4.3.2-7) <8ad8> DW_AT_language : 1 (ANSI C) <8ad9> DW_AT_name : (indirect string, offset: 0x13b2): ../sysdeps/ieee754/dbl-64/s_atan.c <8add> DW_AT_comp_dir : (indirect string, offset: 0x5a7): /usr/src/debug/glibc-20081113T2206/math <8ae1> DW_AT_low_pc : 0x15ee0 <8ae9> DW_AT_high_pc : 0x18725 <8af1> DW_AT_stmt_list : 0x36a2 <1><90c2>: Abbrev Number: 15 (DW_TAG_variable) <90c3> DW_AT_name : b <90c5> DW_AT_decl_file : 4 <90c6> DW_AT_decl_line : 113 <90c7> DW_AT_type : <0x8f0d> <90cb> DW_AT_location : 9 byte block: 3 98 d1 4 0 0 0 0 0 (DW_OP_addr: 4d198) Symbol table '.symtab' contains 1761 entries: Num: Value Size Type Bind Vis Ndx Name 302: 000000000004d198 8 OBJECT LOCAL DEFAULT 15 b Regards, Jan Fix false FAIL with libm.so debuginfo installed. * gdb.python/python-frame.exp (test Frame.read_var - error): Convert it to gdb_test_multiple with XFAIL on the libm instance on `b'. diff --git a/gdb/testsuite/gdb.python/python-frame.exp b/gdb/testsuite/gdb.python/python-frame.exp index 083fa90..e9e063a 100644 --- a/gdb/testsuite/gdb.python/python-frame.exp +++ b/gdb/testsuite/gdb.python/python-frame.exp @@ -81,9 +81,20 @@ gdb_test "python print 'result =', f0.pc ()" " = \[0-9\]+" "test Frame.pc" gdb_test "python print 'result =', f0.addr_in_block ()" " = \[0-9\]+" "test Frame.addr_in_block" gdb_test "python print 'result =', f0.older ().equals (f1)" " = True" "test Frame.older" gdb_test "python print 'result =', f1.newer ().equals (f0)" " = True" "test Frame.newer" -gdb_test "python print 'result =', f0.read_var ('b')" \ - "ValueError: variable 'b' not found.*Error while executing Python code." \ - "test Frame.read_var - error" + +set test "test Frame.read_var - error" +gdb_test_multiple "python print 'result =', f0.read_var ('b')" $test { + -re "ValueError: variable 'b' not found.*Error while executing Python code.\r\n$gdb_prompt $" { + pass $test + } + -re "result = \\\{i = \\\{0, \[0-9\]+\\\}, d = 0\\.\[0-9\]+\\\}\r\n$gdb_prompt $" { + # libm.so debuginfo contains file static symbol `b' from `atnat.h'. + # local `b' would be find first if it would exist so it is more a PASS. + setup_xfail *-*-* + fail $test + } +} + gdb_test "python print 'result =', f0.read_var ('a')" " = 1" "test Frame.read_var - success" gdb_test "python print 'result =', gdb.newest_frame ().equals (f0)" " = True" "test gdb.newest_frame" ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [python] [approval request] Re: FYI a testcase FAIL: test Frame.read_var_value - error 2009-03-06 13:25 ` [python] [approval request] " Jan Kratochvil @ 2009-03-06 14:22 ` Thiago Jung Bauermann 2009-03-06 14:28 ` Thiago Jung Bauermann 2009-03-06 23:41 ` Tom Tromey 1 sibling, 1 reply; 10+ messages in thread From: Thiago Jung Bauermann @ 2009-03-06 14:22 UTC (permalink / raw) To: Jan Kratochvil; +Cc: archer El vie, 06-03-2009 a las 14:25 +0100, Jan Kratochvil escribió: > On Fri, 06 Mar 2009 04:35:18 +0100, Thiago Jung Bauermann wrote: > > El jue, 05-03-2009 a las 23:58 +0100, Jan Kratochvil escribió: > > > python print 'result =', f0.read_var ('b') > > > result = {i = {0, 1068498944}, d = 0.0625} > > > (gdb) FAIL: gdb.python/python-frame.exp: test Frame.read_var - error > > > > This is weird. python-frame.c doesn't have a b variable in f2, which is > > where the testcase stops for the tests. It does have an argument named b > > in f1, but it surely doesn't have such type. It's a plain int. > > I could have investigated it more first (and curious you do not have > glibc-debuginfo installed): I actually do have it, but Debian's debuginfo for libc is minimal, unfortunately. > OK to checkin the patch below? Fine by me. Thanks for working on this. -- []'s Thiago Jung Bauermann IBM Linux Technology Center ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [python] [approval request] Re: FYI a testcase FAIL: test Frame.read_var_value - error 2009-03-06 14:22 ` Thiago Jung Bauermann @ 2009-03-06 14:28 ` Thiago Jung Bauermann 2009-03-06 14:31 ` Jan Kratochvil 0 siblings, 1 reply; 10+ messages in thread From: Thiago Jung Bauermann @ 2009-03-06 14:28 UTC (permalink / raw) To: Jan Kratochvil; +Cc: archer El vie, 06-03-2009 a las 11:21 -0300, Thiago Jung Bauermann escribió: > El vie, 06-03-2009 a las 14:25 +0100, Jan Kratochvil escribió: > > OK to checkin the patch below? > > Fine by me. Thanks for working on this. Actually, I think it's better to change the variable name from 'b' to something hwich will surely not exist anywhere else. What do you think? I can make that change. -- []'s Thiago Jung Bauermann IBM Linux Technology Center ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [python] [approval request] Re: FYI a testcase FAIL: test Frame.read_var_value - error 2009-03-06 14:28 ` Thiago Jung Bauermann @ 2009-03-06 14:31 ` Jan Kratochvil 2009-03-06 15:04 ` Thiago Jung Bauermann 0 siblings, 1 reply; 10+ messages in thread From: Jan Kratochvil @ 2009-03-06 14:31 UTC (permalink / raw) To: Thiago Jung Bauermann; +Cc: archer On Fri, 06 Mar 2009 15:28:10 +0100, Thiago Jung Bauermann wrote: > Actually, I think it's better to change the variable name from 'b' to > something hwich will surely not exist anywhere else. What do you think? > I can make that change. Good idea but already checked-in. Patch it a way you like. Also XFAIL was probably not right as the system environment was correct. KFAIL also would not be right as GDB behaves as expected. Maybe it should have been just PASS as it comes from GDB breakage by design. Regards, Jan ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [python] [approval request] Re: FYI a testcase FAIL: test Frame.read_var_value - error 2009-03-06 14:31 ` Jan Kratochvil @ 2009-03-06 15:04 ` Thiago Jung Bauermann 0 siblings, 0 replies; 10+ messages in thread From: Thiago Jung Bauermann @ 2009-03-06 15:04 UTC (permalink / raw) To: Jan Kratochvil; +Cc: archer El vie, 06-03-2009 a las 15:31 +0100, Jan Kratochvil escribió: > On Fri, 06 Mar 2009 15:28:10 +0100, Thiago Jung Bauermann wrote: > > Actually, I think it's better to change the variable name from 'b' to > > something hwich will surely not exist anywhere else. What do you think? > > I can make that change. > > Good idea but already checked-in. Patch it a way you like. Ok, I reversed your patch and committed the patch below. I'm just worried about my lack of sense of humor when choosing the variable name... > Also XFAIL was probably not right as the system environment was correct. > KFAIL also would not be right as GDB behaves as expected. > Maybe it should have been just PASS as it comes from GDB breakage by design. PASS wouldn't be good either because if read_var finds a variable the test doesn't exercise the error path I want it to, so the PASS doesn't mean anything. -- []'s Thiago Jung Bauermann IBM Linux Technology Center commit 7479ac4e385bcaa2846c3aad5c616f571ff53c97 Author: Thiago Jung Bauermann <bauerman@br.ibm.com> Date: Fri Mar 6 11:49:59 2009 -0300 Fix python-frame.exp testcase when you have libm.so debuginfo. Revert "Fix false FAIL with libm.so debuginfo installed." This reverts commit eff2403b365bdda84c08eb68890152ca1a58f1c6. * gdb.python/python-frame.exp (test Frame.read_var - error): Use variable name which surely won't exist anywhere. diff --git a/gdb/testsuite/gdb.python/python-frame.exp b/gdb/testsuite/gdb.python/python-frame.exp index e9e063a..674c25e 100644 --- a/gdb/testsuite/gdb.python/python-frame.exp +++ b/gdb/testsuite/gdb.python/python-frame.exp @@ -81,20 +81,9 @@ gdb_test "python print 'result =', f0.pc ()" " = \[0-9\]+" "test Frame.pc" gdb_test "python print 'result =', f0.addr_in_block ()" " = \[0-9\]+" "test Frame.addr_in_block" gdb_test "python print 'result =', f0.older ().equals (f1)" " = True" "test Frame.older" gdb_test "python print 'result =', f1.newer ().equals (f0)" " = True" "test Frame.newer" - -set test "test Frame.read_var - error" -gdb_test_multiple "python print 'result =', f0.read_var ('b')" $test { - -re "ValueError: variable 'b' not found.*Error while executing Python code.\r\n$gdb_prompt $" { - pass $test - } - -re "result = \\\{i = \\\{0, \[0-9\]+\\\}, d = 0\\.\[0-9\]+\\\}\r\n$gdb_prompt $" { - # libm.so debuginfo contains file static symbol `b' from `atnat.h'. - # local `b' would be find first if it would exist so it is more a PASS. - setup_xfail *-*-* - fail $test - } -} - +gdb_test "python print 'result =', f0.read_var ('variable_which_surely_doesnt_exist')" \ + "ValueError: variable 'variable_which_surely_doesnt_exist' not found.*Error while executing Python code." \ + "test Frame.read_var - error" gdb_test "python print 'result =', f0.read_var ('a')" " = 1" "test Frame.read_var - success" gdb_test "python print 'result =', gdb.newest_frame ().equals (f0)" " = True" "test gdb.newest_frame" ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [python] [approval request] Re: FYI a testcase FAIL: test Frame.read_var_value - error 2009-03-06 13:25 ` [python] [approval request] " Jan Kratochvil 2009-03-06 14:22 ` Thiago Jung Bauermann @ 2009-03-06 23:41 ` Tom Tromey 1 sibling, 0 replies; 10+ messages in thread From: Tom Tromey @ 2009-03-06 23:41 UTC (permalink / raw) To: archer >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes: Jan> IMO GDB should be strictly following the c++ lookup scopes. This Jan> `b' lookup would therefore require to type `s_atan.c:b' or Jan> `atnat.h:b' when some current frame or current_source_symtab are Jan> in a different file. I tend to agree. I think the current behavior is nice with small programs, but gets unwieldy with larger ones, or when you have debuginfo for the system libraries. Also, the delayed symfile hack would work better with this style of lookup. Maybe we can try this out at some point. I suspect we might find it inconvenient in some situations. Tom ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2009-03-06 23:41 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-03-03 19:48 [python] FYI a testcase FAIL: test Frame.read_var_value - error Jan Kratochvil 2009-03-04 17:02 ` Thiago Jung Bauermann 2009-03-05 22:58 ` Jan Kratochvil 2009-03-06 3:35 ` Thiago Jung Bauermann 2009-03-06 13:25 ` [python] [approval request] " Jan Kratochvil 2009-03-06 14:22 ` Thiago Jung Bauermann 2009-03-06 14:28 ` Thiago Jung Bauermann 2009-03-06 14:31 ` Jan Kratochvil 2009-03-06 15:04 ` Thiago Jung Bauermann 2009-03-06 23:41 ` Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).