arm-unknown-linux-gnueabi ABI selection

[Yann E. MORIN]

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