Rockbox mail archiveSubject: Re: Segfault with Faster MDCT patch and -fPIC
Re: Segfault with Faster MDCT patch and -fPIC
From: Dave Hooper <dave_at_beermex.com>
Date: Fri, 17 Sep 2010 12:08:38 +0100
If I remember correctly, gcc was not clever enough to maintain the ordering
constraints needed by the ldmia/stmia calls, so I needed to assign the
registers manually to prevent generating bad code (by the way x86 shouldn't
use this file at all so compilation issues wouldn't show up on your build).
I had thought that register("r10") would ensure the code-generation step
preserves existing value of r10 - is that not the case? If not then it
sounds like we need to stack all registers at entry/unstack on exist from
all functions that use the TRANSFORM macros. I'd kinda assumed that gcc
would just do this by default though. If not, maybe there's another syntax
or idiom that lets us specify an explicit register AND have gcc ensure its
original value is preserved on function prolog/epilog.
> On Fri, 17 Sep 2010 10:34:06 +0100
> Dave Hooper <dave_at_beermex.com> wrote:
>> That's very interesting indeed. I too observed a segfault when trying
>> to use the fastermdct patch on top of a libtremor used by an MPD
>> server but couldn't pinpoint the reason. That's one of the reasons
>> this patch hasn't hit upstream Tremor.
>> I know the code well but that line seems very mysterious (I.e.
>> harmless - it should work unless something has corrupted the
>> stack/address pointer, I think).
>> Can any arm gurus see if I am misusing any registers in a way that
>> prevents shared library usage, or anything along those lines?
> From a very quick look on google, ARM seems to need r10 as PIC
> register, and at least some TRANSFORM_* macros assign variables to r10
> Why isn't 'register FFTSample x' enough?
> Attached patch remove explicit naming of registers, and is also updated
> to Tremor svn. I just tried a build on x86 but not on ARM.
> Can you see if it works?
>> > Unfortunately, I don't have gdb built for this platform (I managed
> You could post the preprocessed source, output of gcc -E and gcc -S,
> Rafaël Carré
Received on 2010-09-17