OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

2004-11-08 Andrew Cagney <cagney@gnu.org> 

* PROBLEMS: Delete no-longer applicable problems.
This commit is contained in:
Andrew Cagney 2004-11-08 15:34:04 +00:00
parent c37653e73f
commit 3c8fa3070d
2 changed files with 4 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
gdb/ChangeLog
View File

@ -1,3 +1,7 @@
2004-11-08 Andrew Cagney <cagney@gnu.org>
* PROBLEMS: Delete no-longer applicable problems.
2004-11-07 Andrew Cagney <cagney@redhat.com>
Daniel Jacobowitz <dan@debian.org>
Roland McGrath <roland@redhat.com>

52
gdb/PROBLEMS
View File

@ -24,30 +24,6 @@ And replace it with:
if false ; then
build/1458: compile failed on hpux11
GDB has build problems on HP/UX 11 with some versions of the HP
Ansi C compiler. (GCC works fine).
The problem happens when compiling intl/bindtextdom.c.
The error is:
cc: "gettextP.h", line 50: error 1000: Unexpected symbol: "SWAP".
cc: panic 2017: Cannot recover from earlier errors, terminating.
*** Error exit code 1
This is a problem with the 'inline' keyword in gettextP.h.
The workaround is to disable 'inline' before building gdb:
export ac_cv_c_inline=no
This problem happens only with some versions of the HP Ansi C compiler.
Versions A.11.01.25171.GP and B.11.11.28706.GP have both been observed
to work; version B.11.11.04 gets the build error and needs the
workaround.
This problem might also happen with other C compilers.
*** Misc
gdb/1560: Control-C does not always interrupt GDB.
@ -112,34 +88,6 @@ implement virtual base classes. gcc 2.x generated just one object code
function with a hidden parameter, but gcc 3.x conforms to a multi-vendor
ABI for C++ which requires multiple object code functions.
*** Signal handlers
On many systems an attempt to single-step a system-call instruction
results in two or more instructions being executed (the system-call,
and one or more instructions following).
When attempting to single-step through a signal trampoline, this
problem may result the program unintentionally running to completion,
or re-execute the faulting instruction, or even corrupting the program
counter.
Ref: PR breakpoints/1702.
*** Stack backtraces
GDB's core code base has been updated to use a new backtrace
mechanism. This mechanism makes it possible to support new features
such DWARF 2 Call Frame Information (which in turn makes possible
backtraces through optimized code).
Since this code is new, it is known to still have a few problems:
gdb/1505: [regression] gdb prints a bad backtrace for a thread
When backtracing a thread, gdb does not stop when it reaches the
outermost frame, instead continuing until it hits garbage. This is
sensitive to the operating system and thread library.
*** Threads
threads/1650: manythreads.exp