[#6135] Failure to set breakpoint on abort() (manifests as failure to connect to target)
Submitted By: Vivi Li
2010-07-21 03:40:27 Close Date
N/A Silicon Revision:
Fixed Fixed In Release:
Host Operating System:
Closed Found In Release:
Is this bug repeatable?:
Summary: Failure to set breakpoint on abort() (manifests as failure to connect to target)
When test binutils/g++/gcc/libstdc++/newlib through jtag on bf537-stamp, it shows warning of unable to connect to GDB for certain test cases.
No such problem on bf561-ezkit. Detailed logs are attached.
Bellow is an example in g++ test.
spawn bfin-elf-c++ /home/test/work/cruise/checkouts/toolchain/gcc-4.3/gcc/testsuite/g++.dg/opt/pr36187.C -fmessage-length=0 -O2 --param max-aliased-vops=20 -fno-show-column -mcpu=bf537-0.2 -lm -o ./pr36187.exe
PASS: g++.dg/opt/pr36187.C (test for excess errors)
spawn bfin-elf-gdb -nw -nx
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=bfin-elf".
(gdb) set height 0
(gdb) set width 0
(gdb) delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) file ./pr36187.exe
Reading symbols from /home/test/work/cruise/temp/regtest_build4.3/g++_build/testsuite/pr36187.exe...done.
(gdb) break _exit
Breakpoint 1 at 0xffa00ef8: file /home/test/work/cruise/checkouts/toolchain/gcc-4.3/libgloss/libnosys/_exit.c, line 13.
(gdb) break abort
Function "abort" not defined.
Make breakpoint pending on future shared library load? (y or [n]) target remote :2000
Please answer y or [n].
Make breakpoint pending on future shared library load? (y or [n]) WARNING: Unable to connect to :2000 with GDB.
Please answer y or [n].
Make breakpoint pending on future shared library load? (y or [n])
Bellow is the list of test cases in which this problem exists:
ERROR: unresolved setup, status = untested
UNRESOLVED: simple objcopy of executable
UNRESOLVED: g++.dg/opt/pr36187.C execution test
UNRESOLVED: gcc.c-torture/execute/pr43220.c execution, -O1
UNRESOLVED: gcc.c-torture/execute/pr43220.c execution, -O2
UNRESOLVED: gcc.c-torture/execute/pr43220.c execution, -O3 -g
UNRESOLVED: gcc.c-torture/execute/pr43220.c execution, -Os
UNTESTED: gcc.dg/struct/wo_prof_escape_arg_to_local.c execution test
UNRESOLVED: tr1/5_numerical_facilities/random/uniform_int/cons/default.cc execution test
UNRESOLVED: tr1/5_numerical_facilities/random/uniform_int/cons/range.cc execution test
UNRESOLVED: tr1/6_containers/array/capacity/empty.cc execution test
UNRESOLVED: tr1/6_containers/array/capacity/max_size.cc execution test
UNTESTED: tr1/6_containers/array/capacity/size.cc execution test
UNRESOLVED: newlib.iconv/iconvnm.c execution
UNRESOLVED: newlib.iconv/iconvru.c execution
UNRESOLVED: newlib.iconv/iconvjp.c execution
UNRESOLVED: newlib.locale/UTF-8.c output
UNTESTED: newlib.search/hsearchtest.c execution
--- Steve Kilbane 2010-07-22 03:41:33
The log shows that it's not a connection failure, but that the script isn't
expecting to get a question back when setting the breakpoint on abort.
--- Steve Kilbane 2010-07-22 08:07:24
These all fail in the same way. I can see that toolchain-regtest is trying to
avoid this, with gdb-init-commands containing "set breakpoint pending
off", but I don't know why that isn't always sufficient. *Sometimes* it is
- in the g++ log, at line 8078, where "break abort" first fails,
there's no prompt wrt pending - but later on, it isn't, and the prompts screw
However, this is a test problem, not a toolchain problem.
--- Robin Getz 2010-07-22 15:02:45
If its a test issue - feel free to drop the priority to something appropriate.
--- Steve Kilbane 2010-07-29 04:33:58
Dropped to Medium.
--- Stuart Henderson 2011-06-22 09:31:31
this looks like a less dramatic version of [#6624], so assigning to me.
--- Stuart Henderson 2011-06-22 10:21:55
A bit of research has shown this is a bug in dejagnu. Since the bug is causing
more and more problems, i suggest we upgrade to the latest version.
We're currently using ~1.4.4 (released in 2004), but 1.5 came out this year.
Grace/Sonic, is it possible to have your testing machines updated to this new
version? I've just tested 1.5 and it got through the elf-jtag gcc tests in
about 27 minutes.
This newer version *still* hasn't got the remote_setenv changes however, so you
would need to apply the attached patch after you've installed it.
Let me know if you want full instructions on how to install it.
--- Sonic Zhang 2011-06-22 23:03:36
OK. We will update to dejugnu 1.5 on regression machines.
--- Stuart Henderson 2011-06-23 05:38:12
--- Stuart Henderson 2011-06-23 06:49:31
Setting to fixed for now.
--- Mingquan Pan 2011-06-30 23:19:01
Yes, by updating dejagnu to 1.5, jtag testing can run finished on stamp 537
results are like:
### New: binutils-2.21.sum in
=== binutils Summary ===
# of expected passes 77
# of unsupported tests 5
### New: g++-4.3.sum in
=== g++ Summary ===
# of expected passes 17128
# of unexpected failures 164
# of expected failures 92
# of unresolved testcases 149
# of unsupported tests 183
### New: gas-2.21.sum in
=== gas Summary ===
# of expected passes 160
# of expected failures 1
### New: gcc-4.3.sum in
=== gcc Summary ===
# of expected passes 49063
# of unexpected failures 171
# of expected failures 89
# of unresolved testcases 76
# of untested testcases 35
# of unsupported tests 450
### New: gdb-6.6.sum in
=== gdb Summary ===
# of expected passes 9446
# of unexpected failures 92
# of expected failures 42
# of known failures 53
# of unresolved testcases 6
# of untested testcases 19
# of unsupported tests 35
### New: ld-2.21.sum in
=== ld Summary ===
# of expected passes 183
# of expected failures 9
### New: libstdc++-4.3.sum in
=== libstdc++ Summary ===
# of expected passes 2407
# of unexpected failures 1114
# of expected failures 54
# of unresolved testcases 1070
# of unsupported tests 482
### New: newlib-4.3.sum in
=== newlib Summary ===
# of expected passes 21
# of unexpected failures 3
*** It took 7h40m23s to complete 30 Jun 2011
So close this bug.
--- Mingquan Pan 2011-06-30 23:31:39
Hi,stuart, is the result the same as yours?
Since It finishes the gcc jtag testing in about 2 hours without your patch. And
it is the normal results we used to get.
I post the gcc log.
--- Mingquan Pan 2011-07-08 00:42:38
I apply the your patch to dejagnu 1.5, since it looks remote_env is used in
libmudflap testing while jtag testing happened to skip this one.
--- Stuart Henderson 2011-07-19 07:13:08
Hi Grace, just to confirm, are you happy with the way it is testing now? or is
there something you'd still like me to look at?
File Name File Type File Size Posted By
gcc-4.3.log.gz application/x-gzip 1594354 Mingquan Pan
deja.patch application/octet-stream 1391 Stuart Henderson
log_537.tar.bz2 application/x-bzip2 1627265 Vivi Li
561_example.tar.bz2 application/x-bzip2 125920 Vivi Li