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


On Mon, Apr 11, 2011 at 11:59 PM, Titus von Boxberg <titus@v9g.de> wrote:
>
> Am 11.04.2011 um 17:54 schrieb Bryan Hundven:
>
>>
>> On Apr 11, 2011 4:19 AM, "Titus von Boxberg" <titus@v9g.de> wrote:
>> >
>> > 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
>>
>> Again. I don't see any problem here with crosstool-ng.
>> Maybe this conversation belongs on gcc-help@
> Bryan,
>
> I can only guess why you cannot see the problem.

Assumption makes an ass out of you and umption.

> This might be a combination of
> - you misinterpret the main subject of the list as ct-ng@sourceware.org

I did not misinterpret. This ml is for cross-compiling gcc.
Soon crosstool-ng will have it's own mailing list and this kind of
noise will go away.

> - you misinterpret the goal of ct-ng as "reliably produce a cross tool chain whose
> Âcomponents return an exit code of 0 given syntactical correctness of the input".
> - you overlooked my original question "is there a knob to turn off that behaviour",
> Âwhich - as far as I understand - definitely would belong to ct-ng.

I saw that question and did not respond to it, because I did not know.

> - I already answered my question ("no, there is no such knob, it's hardwired")
> Âin case someone might be interested, and you did not see that answer.
> - You overlooked that a big deal of ct-ng is about to patch toolchain sources into
> Âreliably useable shape, thus my patches might interest others as well.

The patch might be useful to others as well as ct-ng.
But is removing -many for e500/e500mc/603e correct? I meant to suggest
to verify with gcc-help@
Not trying to insult you. Sorry for not being clear.
Maybe it would be better fixed upstream then patched in crosstool-ng?

My understanding of crosstool-ng is that it is a build system for the
components of source code that make up a cross toolchain. There are a
few types of cross toolchains (native, cross-native, cross,
cross-canadian, and cross-back. I'm sure there are stranger
combinations) where patches are needed to aid that type of build as
well as different build procedures/semantics.

From what I understand by talking with Yann is that it is a pain to
port patches forward to newer versions of these source components. If
the patches could be verified when we port the patches forward to
newer source components, and possibly accepted upstream, then the
number of patches to port forward become less daunting and more
specific to different types of cross toolchains.
I have tried to verify a few of the patches myself with no response.
Maybe I am asking the wrong people.

Ian Lance Taylor wrote (http://www.airs.com/blog/archives/492) about
the problems of creating cross-compilers (which crosstool-ng was
referenced), and I think that verifying patches in crosstool-ng (and
other projects, like buildroot, oe, etc...) with the source component
developers might help to bridge the testing gap with these source
components in a cross-compiler.

The harder part being that it is not always trivial to figure out if a
build issue is a problem with the source components or a build
environment issue.

> - you cannot grasp that a toolchain is inherently unreliable when the compiler
> Âdeliberately accepts (inline assembly) instructions that cannot be executed
> Â(here, refer back to point 2).
>
> HTH
>
> Regards
> Titus
>
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>
>

I have no intention or desire to insult your intelligence or to say
that I know it all. Always learning by validating my knowledge.
I am merely trying to help.

-Bryan

--
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]