This is the mail archive of the ecos-bugs@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Issue 1000699] except1 test: infinite backtrace on ARM


http://bugs.ecos.sourceware.org/show_bug.cgi?id=1000699


Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jifl@ecoscentric.com        |john@dallaway.org.uk
          Component|Debugging                   |ConfigTool




--- Comment #3 from Jonathan Larmour <jifl@ecoscentric.com>  2009-02-26 14:33:05 ---
Theoretically we could add call_exception_handler to the list of functions
where we forcibly stop backtraces. But remember that that hack^H^H^H^Hfix is
not meant to be perfect, but is there to simplify life. And other HALs use
other names for the exception handler VSR. We have to live with the fact that
GDB unfortunately occasionally gets it wrong. So I suggest the configtool
should be able to cope, regardless.

I think Sergei's proposal sounds best. I would have suggested using "set
backtrace limit" except that, as we know from eCosCentric-land, older GDB has a
buggy implementation of that.

The value can be something large like 50 or even 100. All that really matters
is that it's finite and likely to stop within the normal sorts of timeout.

So in that context, ping pong back to John :-).

Jifl


-- 
Configure issuemail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the issue.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]