Bug 84530
| Summary: | Bad stacks on PowerPC | ||
|---|---|---|---|
| Product: | [Retired] eCos | Reporter: | Gary Thomas <gary> |
| Component: | Kernel | Assignee: | Jonathan Larmour <jifl-bugzilla> |
| Status: | CLOSED WONTFIX | QA Contact: | Jonathan Larmour <jifl-bugzilla> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | CVS | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-06-20 16:18:51 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
From further discussion on ecos-discuss: Gary D. Thomas wrote: > On Tue, 2003-02-18 at 09:27, Jonathan Larmour wrote: > >> I know you've identified the stack checking as the reason, but it's not really the cause (other than GDB's stack guesswork), so there's still another interesting issue with this: the stub shouldn't barf. There's meant to be code to catch this (see cyg_hal_exception_handler() in hal/powerpc/arch/current/src/hal_misc.c - look at the stuff at the top about __mem_fault_handler). >> >> If it correctly caught the exception the backtrace would likely work using GDB's admittedly ramshackle heuristics. *That's* the problem, not the stack checking itself. >> >> I'll add this to the bug. > > > > I agree that GDB should not barf - certainly that's a problem. > > However, I think that the stack checking code is breaking the > EABI and putting stuff on the stack that is, in essence, invalid. > The PowerPC ABIs really suck (thanks, IBM) in that there needs > to be some space (I don't recall how much) *above* the stack > that belongs to the current frame. This means that the last > stack frame (the ending one, hopefully) can't have those > 0xDEADBEEF markers immediately adjacent (IIRC). > We should probably look at the ABI and make sure that what we > do with the stack for checking is legal. Well if there's a problem it's with the HAL. HAL_THREAD_INIT_CONTEXT is called _after_ all the padding is added, and it's that which should add any relevant space. For the powerpc, it already leaves CYGARC_PPC_STACK_FRAME_SIZE which is a whole 56 bytes (which looking at the eABI I saw, looks like overkill). However I also note that area isn't initialized to anything. But then we'd see it without the stack frame checking enabled either. Jifl This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id=84530 |
Description of problem: Enabling CYGFUN_KERNEL_THREADS_STACK_MEASUREMENT causes the stack frames to confuse GDB. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Build a PowerPC application with CYGFUN_KERNEL_THREADS_STACK_MEASUREMENT 2. Stop at a breakpoint or ^C 3. GDB 'bt' command will fail Actual results: Expected results: Additional info: