Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 84530 - Bad stacks on PowerPC
Summary: Bad stacks on PowerPC
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: eCos
Classification: Retired
Component: Kernel
Version: CVS
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jonathan Larmour
QA Contact: Jonathan Larmour
URL:
Whiteboard:
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:
Clone Of:
Environment:
Last Closed: 2003-06-20 16:18:51 UTC


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.