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] |
Michael, All, Trying to catch up... On Friday 29 August 2008 09:08:13 Michael Abbott wrote: > I'm rebuilding now with something along these lines. I think this code in > arch/arm/functions is wrong: > > > case "${CT_ARCH_ABI},${CT_ARCH_ARM_EABI}" in > > > *,) ;; > > > aapcs,y) > > > CT_DoLog DEBUG "'--with-abi=aapcs' is in fact '-mabi=aapcs-linux' when used in CFLAGS." > > > CT_ARCH_ABI_CFLAGS="-mabi=aapcs-linux" > > > ;; > > > ,y) > > > CT_DoLog WARN "Forcing ABI to 'aapcs-linux' for use with EABI." > > > CT_ARCH_WITH_ABI="--with-abi=aapcs" > > > CT_ARCH_ABI_CFLAGS="-mabi=aapcs-linux" > > > ;; > > > *,y) > > > CT_DoLog ERROR "ABI='${CT_ARCH_ABI}' not supported for EABI." > > > CT_Abort "If you know you are right, please edit 'arch/arm/functions' in crosstool-NG sources." > > > ;; > > > esac What's wrong with that? If you say that the values set in CFLAGS and in WITH_ABI are wrong, that's all I could come up with that gave a booting kernel and busybox. Guessing the right combination was a pain, because I could find documentation for all those settings neither in the gcc documentation, nor on the net after about a two-hour search... If you have pointers, explanations, I'm a taker! :-) If you think the case-esac tests are wrong, see below... > The simplest solution, I think, would be to add the line > CT_ARCH_WITH_ABI="--with-abi=aapcs" Although you might sound disturbed, this is already done. If you read the docs/overview.txt, you'll notice that CT_ARCH_WITH_ABI defaults to "--with-abi=${CT_ARCH_ABI}", which value is exactly aapcs in this case, while CT_ARCH_ABI_CFLAGS defaults to "-mabi=${CT_ARCH_ABI}" which is aapcs, and is IMHO wrong, because I think it should be "-mabi=aapcs-linux". But again, I can be wrong here... Also, CT_DoArchValues is called from CT_DoBuildTargetTuple, wich sets the defaults just prior to calling CT_DoArchValues. Thus, CT_DoArchValues just overides whatever was not correct in the defaults. > to the "aapcs,y)" branch, but it would probably be cleaner to decide > whether CT_ARCH_ABI is allowed to be set at all. Eg: > > if [ "$CT_ARCH_ARM_ABI" = y ]; then Should read CT_ARCH_ARM_EABI, yes? ---^ > case "$CT_ARCH_ABI" in > aapcs) ;; > ) ;; > *) CT_Abort "oh dear" ;; > esac > CT_ARCH_WITH_ABI="--with-abi=aapcs" > CT_ARCH_ABI_CFLAGS="-mabi=aapcs-linux" > fi Well, maybe more explicit than the current code, but does exactly the same, except it acts as if there had been not defaults. > I don't think CT_ARCH_ABI is effectively used anywhere else, in which case > it needs to go in the bin altogether, in which case this code becomes a > *lot* simpler. The only other place I can see CT_ARCH_ABI being used is > in CT_DoBuildTargetTuple (scripts/functions) in the following (elided > and reformatted for clarity): > > unset ... CT_ARCH_ABI ... Wrong, re-read the code again, please. The variable that gets unset is CT_ARCH_WITH_ABI, and thus the conditional block can actually be executed. ^^^^^ > [ "${CT_ARCH_ABI}" ] && { > CT_ARCH_ABI_CFLAG="-mabi=${CT_ARCH_ABI}"; > CT_ARCH_WITH_ABI="--with-abi=${CT_ARCH_ABI}"; } > > Very odd. The unset means the following block of code is never executed. > Am I missing something, or is there a whole block of code ready for the > bin here? Not going to the bin, I'm afraid... :-) > If I'm seeing things right it looks as if we can scrap CT_ARCH_ABI > altogether and replace the arch/arm/functions code above with > if [ "$CT_ARCH_ARM_ABI" = y ]; then > CT_ARCH_WITH_ABI="--with-abi=aapcs" > CT_ARCH_ABI_CFLAGS="-mabi=aapcs-linux" > fi Don't think so, as I explained. On the other hand, I know that docs/overview.txt is not visible enough, really is a long lecture, and that it can be enhance. When I initially wrote it, I didn't think of it as the documentation for crosstool-NG, but just as a kind of document for myself where I could throw ideas and implementation details like I would on the corner of a sheet of paper. Turned out it now serves as the only documentation for crosstool-NG, but I had no time and wilingness to rewrite it, save for the occasional updates to follow the code (I'm always a bit late at updating it, also). Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ | | --==< ^_^ >==-- `------------.-------: X AGAINST | /e\ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | """ conspiracy. | `------------------------------^-------^------------------^--------------------' -- 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] |