This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: powerpc gcc option -many passed to assembler


Am Mo, 11.04.2011, 11:19 schrieb Bryan Hundven:
> On Thu, Mar 31, 2011 at 6:13 AM, Titus von Boxberg <titus@v9g.de> wrote:
>> Hi,
>>
>> just in case someone is interested:
>> Calling as with option -many is hardcoded in gcc.
>>
>> A colleague found those links which might be helpful
>> for seeing the "reasoning" behind:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21091
>> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01244.html
>> http://gcc.gnu.org/ml/gcc-patches/2004-05/msg01247.html
>> http://sources.redhat.com/ml/binutils/2004-05/msg00376.html
>> http://sources.redhat.com/ml/binutils/2004-05/msg00357.html
>>
>> The problem I had was that the compiler/assemler accepts
>> e.g. dcbzl for an e500v2 which leads to a SIGILL.
>
> Neat. I've not seen this one yet.
> Do you have some example code or a test-case I could try that cause the SIGILL?

asm("dcbzl 3,13");

>
>> The solution for me is up to now
>> - to patch away -many in gcc
>> - to allow sync / eieio (in addition to equivalent msync/mbar) in as
>> Â?for e500 because otherwise you cannot compile almost nothing
>> Â?of the tool chain.
>>
>> Aditionally, in binutils 2.20 there is the mistake that
>> an e500 was believed to be an e500mc (but this has apparently
>> been corrected in 2.21).
>
> With logs located at: http://bryanhundven.com/ct-ng/powerpc-e500v2-linux-gnuspe/
>
> ...I built a gcc-4.5.1/binutils-2.21/eglibc-2.12 toolchain, and I was
> able to build u-boot (HEAD:17e967b) for P2020RDB board and the linux
> kernel. I didn't notice any issues.
>
> Maybe I do not fully understand the issue you are seeing.
What issue do you mean here?
The problem I had is explained above: It is false permissiveness
of the assembler when invoked by the compiler.
Building a tool chain has not been the problem.

BTW: The patched toolchain I'm using seems to work fine (up to now ;-)

Regards
Titus



--
For unsubscribe information see http://sourceware.org/lists.html#faq


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]