Bug 84530 - Bad stacks on PowerPC
Summary: Bad stacks on PowerPC
Status: CLOSED WONTFIX
Alias: None
Product: eCos
Classification: Retired
Component: Kernel (Show other bugs)
(Show other bugs)
Version: CVS
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Jonathan Larmour
QA Contact: Jonathan Larmour
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-02-18 15:16 UTC by Gary Thomas
Modified: 2007-04-18 16:51 UTC (History)
0 users

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: ---


Attachments (Terms of Use)

Description Gary Thomas 2003-02-18 15:16:48 UTC
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:

Comment 1 Jonathan Larmour 2003-02-18 17:37:45 UTC
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 

Comment 2 Alex Schuilenburg 2003-06-20 16:18:51 UTC
This bug has moved to http://bugs.ecos.sourceware.org/show_bug.cgi?id=84530


Note You need to log in before you can comment on or make changes to this bug.