ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] libc backtrace and crash handlers


From: seh
Subject: Re: [Ltib] libc backtrace and crash handlers
Date: Thu, 26 Aug 2010 04:23:47 -0400
User-agent: SquirrelMail/1.4.19

Hi Kareem,

The first thing you could do is to re-configure LTIB (./ltib -c) and see
if there's an alternative toolchain that you can use which already has
this patch.

Failing that, see if there is a suitable toolchain available from
CodeSourcery's site.  You can install this and refer to it in LTIB by
using "custom toolchain".  If that works,  it can be more fully integrated
(I can help).

If you really need to use the toolchain you have now and you want to patch
it, the it's best to re-build the toolchain with the patch added.  The
source rpm for all the toolchains are available on the GPP, the have the
same name as the binary, except the extension is .src.rpm instead of
.i386.rpm.  The process would be to install the srpm, update the .spec
file with the new patch referenced, re-build, install and test.  I can't
fully describe it here.  This should be build using the toolchain build
environment we mandated (an old machine) so it can work on most Linux
distros.  Zee2 have such a machine setup, but I don't have time available
to do this (Zee2's toolchain guy could do this under contract though)

It's probably worth reporting to Freescale and asking them if they have a
fix/replacement toolchain (they may do).  Please report back to this list
if you hear anything.

You can build glibc stand-alone in LTIB, but I've rarely done this and
would not be confident to recommend this.  The issue is isolating any
leakage from the toolchain's glibc.

Regards, Stuart

>
> On 2010-08-24, at 14:09 , Stuart Hughes wrote:
>
>> Hi Kareem,
>>
>> The libc in LTIB is from the toolchain.  Normally this will be eglibc,
>> which is effectively glibc.
>>
>> What do you mean by a backtrace? do you mean a core file?  If so you may
>> need to change your ulimit settings, for example:
>>
>> # ulimit -c unlimited
>
>
> I think I may have found it: the stack frame is offset compared to what is
> expected by glibc.  Here's the thread and a patch:
>
> http://sourceware.org/ml/libc-ports/2006-06/msg00018.html
>
> Question becomes: how can I patch eglibc for this change and include it
> with my builds?
>
> -kms
>
>
> --
> Kareem Shehata
> address@hidden
> Aeryon Labs Inc
> 519-489-6726 x254
>
>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]