Re: backtrace() from a pthread on ARM

[lxusr <gnanasekar dot r29 at gmail dot com>]

I am facing a similar problem wherein if I do a bt I see corrupted stack
whenever clone gets called(ARM target). Can you please tell me what is the
fix you applied to resolve the problem?

Sekar

Matt Fischer-2 wrote:
> 
> On Tue, May 12, 2009 at 11:09 AM, Andreas Schwab <schwab@linux-m68k.org>
> wrote:
>> Matt Fischer <mattfischer84@gmail.com> writes:
>>
>>> On a lot of the architectures (including m68k), it looks like it does.
>>>  Problem is that since ARM has actively moved away from requiring a
>>> frame pointer in their ABI, as Daniel mentioned, you can't be sure at
>>> the time of the clone() call whether you should be modifying r11 at
>>> all.
>>
>> Since r11 is not used for argument passing and the child part of the
>> clone call never returns modifying the register shouldn't be a problem,
>> is it?
>>
>> Andreas.
>>
>> --
>> Andreas Schwab, schwab@linux-m68k.org
>> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
>> "And now for something completely different."
>>
> 
> I thought of that after I sent the email above.  It does seem like
> that wouldn't have any negative side effects, at least in my limited
> understanding of how all of this machinery works.
> 
> At the very least, I'm going to try making that change locally, which
> ought to fix the problem we're seeing.  Would mainline be interested
> in a patch, or is this just labeled as undefined behavior that
> shouldn't be messed with?
> 
> --Matt
> 
> 

-- 
View this message in context: http://old.nabble.com/backtrace%28%29-from-a-pthread-on-ARM-tp23490538p33492571.html
Sent from the Sourceware - libc-ports mailing list archive at Nabble.com.