[U-Boot] Building for da830 fails

[U-Boot] Building for da830 fails

[Sudhakar Rajashekhara]

Hi,

I am using U-Boot from http://git.denx.de/?p=u-boot.git;a=summary and trying to build for da830. But my build fails with following
error:

[...]
/../lib/gcc/arm-none-linux-gnueabi/4.4.1 -lgcc -Map u-boot.map -o u-boot
../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(bpabi.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'

I am using gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202). I also tried with gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203), but
there also I am seeing the same error. I am using "da830evm_config" as the configuration for building. 

Has anyone seen this kind of error while building U-Boot for ARM based architecture?

Regards,
Sudhakar

[U-Boot] Building for da830 fails

[Nick Thompson]

On 07/05/10 12:57, Sudhakar Rajashekhara wrote:
> Hi,
> 
> I am using U-Boot from http://git.denx.de/?p=u-boot.git;a=summary and trying to build for da830. But my build fails with following
> error:
> 
> [...]
> /../lib/gcc/arm-none-linux-gnueabi/4.4.1 -lgcc -Map u-boot.map -o u-boot
> ../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(bpabi.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
> ../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
> ../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
> 
> I am using gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202). I also tried with gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203), but
> there also I am seeing the same error. I am using "da830evm_config" as the configuration for building. 
> 
> Has anyone seen this kind of error while building U-Boot for ARM based architecture?

I just pulled the latest main line source and ran:

% CROSS_COMPILE=arm-none-linux-gnueabi- ./MAKEALL da830evm
Configuring for da830evm board...
/opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(bpabi.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
/opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
/opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
make: *** [u-boot] Error 1
/opt/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-size: './u-boot': No such file

This did not happen when I last updated on March 22nd and
I have not updated my tools at all.

Nick.

[U-Boot] Building for da830 fails

[Nick Thompson]

On 07/05/10 15:14, Nick Thompson wrote:
> On 07/05/10 12:57, Sudhakar Rajashekhara wrote:
>> Hi,
>>
>> I am using U-Boot from http://git.denx.de/?p=u-boot.git;a=summary and trying to build for da830. But my build fails with following
>> error:
>>
>> [...]
>> /../lib/gcc/arm-none-linux-gnueabi/4.4.1 -lgcc -Map u-boot.map -o u-boot
>> ../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(bpabi.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
>> ../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
>> ../lib/gcc/arm-none-linux-gnueabi/4.4.1/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
>>
>> I am using gcc version 4.4.1 (Sourcery G++ Lite 2010q1-202). I also tried with gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203), but
>> there also I am seeing the same error. I am using "da830evm_config" as the configuration for building. 
>>
>> Has anyone seen this kind of error while building U-Boot for ARM based architecture?
> 
> I just pulled the latest main line source and ran:
> 
> % CROSS_COMPILE=arm-none-linux-gnueabi- ./MAKEALL da830evm
> Configuring for da830evm board...
> /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(bpabi.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
> /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
> /opt/CodeSourcery/Sourcery_G++_Lite/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.3/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): undefined reference to `__aeabi_unwind_cpp_pr0'
> make: *** [u-boot] Error 1
> /opt/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-linux-gnueabi-size: './u-boot': No such file
> 
> This did not happen when I last updated on March 22nd and
> I have not updated my tools at all.

Sorry to reply to self. I ran a git bisect session and I get:

52dbac69c27dee67a4c051b1055d93b0ac4e2062 is the first bad commit
commit 52dbac69c27dee67a4c051b1055d93b0ac4e2062
Author: Timur Tabi <timur@freescale.com>
Date:   Tue Apr 13 13:16:02 2010 -0500

    fix print_size printing fractional gigabyte numbers on 32-bit platforms
    
    In print_size(), the math that calculates the fractional remainder of a number
    used the same integer size as a physical address.  However, the "10 *" factor
    of the algorithm means that a large number (e.g. 1.5GB) can overflow the
    integer if we're running on a 32-bit system.  Therefore, we need to
    disassociate this function from the size of a physical address.
    
    Signed-off-by: Timur Tabi <timur@freescale.com>

:040000 040000 2469aed20d27e8d444f749bea2d99fb85d66a52a fee73c34d4eb4d9db3b8640909e519131e5222bf M   lib

Is this the first use of long long on ARM...?

Nick.

[U-Boot] Building for da830 fails

[Timur Tabi]

Nick Thompson wrote:

> Is this the first use of long long on ARM...?

Ugh, I hope not.  vsprintf.c uses ULL.

It appears that the compiler itself supports ULL, but it's trying to link in
support that your toolchain doesn't have.

I don't know what __aeabi_unwind_cpp_pr0 is, but it doesn't look like it's
related to integers.

Also, this patch fixes a real bug in print_size(), so we can't just back it out.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] Building for da830 fails

[Wolfgang Denk]

Dear Timur Tabi,

In message <4BE42D45.9020100@freescale.com> you wrote:
> 
> I don't know what __aeabi_unwind_cpp_pr0 is, but it doesn't look like it's
> related to integers.

__aeabi_unwind_cpp_pr0 is part of the stack unwinding support for ARM;
we can probably just copy the Linux kernel's code which looks pretty
much straightforward:

	/* Dummy functions to avoid linker complaints */
	void __aeabi_unwind_cpp_pr0(void)
	{
	};
	EXPORT_SYMBOL(__aeabi_unwind_cpp_pr0);


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"I refuse to have a battle of wits with an unarmed person."

[U-Boot] Building for da830 fails

[Timur Tabi]

Nick Thompson wrote:
> Is this the first use of long long on ARM...?

include/asm-arm/types.h has this:

#if defined(__GNUC__)
__extension__ typedef __signed__ long long __s64;
__extension__ typedef unsigned long long __u64;
#endif

So try replacing "unsigned long long" with "__u64" in print_size() and see
if that helps.

It must have something to do with __extension__.

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] Building for da830 fails

[Wolfgang Denk]

Dear Nick Thompson,

In message <4BE42048.7000701@ge.com> you wrote:
>
> This did not happen when I last updated on March 22nd and
> I have not updated my tools at all.

Then you are in an excellent position to run git bisect and find out
which exact commit is responsible for the changed behaviour.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A little suffering is good for the soul.
	-- Kirk, "The Corbomite Maneuver", stardate 1514.0

[U-Boot] Building for da830 fails

[Scott McNutt]

Wolfgang Denk wrote:
> In message <4BE42048.7000701@ge.com> you wrote:
>> This did not happen when I last updated on March 22nd and
>> I have not updated my tools at all.
> 
> Then you are in an excellent position to run git bisect and find out
> which exact commit is responsible for the changed behaviour.

I am observing a similar issue ... but with USE_PRIVATE_LIBGCC=yes :

lib/libgeneric.a(display_options.o): In function `print_size':
/home/smcnutt/27xx/u-boot.git/lib/display_options.c:66: undefined 
reference to `__udivdi3'
/home/smcnutt/27xx/u-boot.git/lib/display_options.c:69: undefined 
reference to `__umoddi3'
/home/smcnutt/27xx/u-boot.git/lib/display_options.c:70: undefined 
reference to `__udivdi3'

... which I believe is due to:

commit 52dbac69c27dee67a4c051b1055d93b0ac4e2062
Author: Timur Tabi <timur@freescale.com>
Date:   Tue Apr 13 13:16:02 2010 -0500

--Scott

[U-Boot] Building for da830 fails

[Timur Tabi]

Scott McNutt wrote:
> lib/libgeneric.a(display_options.o): In function `print_size':
> /home/smcnutt/27xx/u-boot.git/lib/display_options.c:66: undefined 
> reference to `__udivdi3'
> /home/smcnutt/27xx/u-boot.git/lib/display_options.c:69: undefined 
> reference to `__umoddi3'
> /home/smcnutt/27xx/u-boot.git/lib/display_options.c:70: undefined 
> reference to `__udivdi3'

Man, I knew ARM sucked, but I didn't know it was this bad :-)

I was going to suggestion replacing the division operations with calls to
lldiv(), but we're actually doing a 64-by-64 bit division here:

n = size / d;

which means that in order to support support printing 64-bit numbers on ARM,
we might need to completely rewrite print_size() to avoid division on 64-bit
numbers.

Wolfgang, do you have any suggestions?

-- 
Timur Tabi
Linux kernel developer at Freescale

[U-Boot] Building for da830 fails

[Nick Thompson]

On 07/05/10 16:30, Timur Tabi wrote:
> Scott McNutt wrote:
>> lib/libgeneric.a(display_options.o): In function `print_size':
>> /home/smcnutt/27xx/u-boot.git/lib/display_options.c:66: undefined 
>> reference to `__udivdi3'
>> /home/smcnutt/27xx/u-boot.git/lib/display_options.c:69: undefined 
>> reference to `__umoddi3'
>> /home/smcnutt/27xx/u-boot.git/lib/display_options.c:70: undefined 
>> reference to `__udivdi3'
> 
> Man, I knew ARM sucked, but I didn't know it was this bad :-)
> 
> I was going to suggestion replacing the division operations with calls to
> lldiv(), but we're actually doing a 64-by-64 bit division here:
> 
> n = size / d;
> 
> which means that in order to support support printing 64-bit numbers on ARM,
> we might need to completely rewrite print_size() to avoid division on 64-bit
> numbers.
> 
> Wolfgang, do you have any suggestions?
> 

I'm not sure if it is the correct way to "fix" this issue, But I have
submitted a patch in "[U-Boot] [PATCH] Avoid use of divides in print_size."

It allows ARM to rebuild again (here at least), but really it modifies
the function to use bit shifts as an optimisation over calling lengthy div
library functions. This side steps the linker issue.

It you have chance to test or review it I would be grateful. I tested the
code on x86 Linux PC, not by running it in U-Boot.

Nick.

[U-Boot] Building for da830 fails

[Wolfgang Denk]

Dear Timur Tabi,

In message <4BE43218.2060209@freescale.com> you wrote:
>
> > /home/smcnutt/27xx/u-boot.git/lib/display_options.c:66: undefined 
> > reference to `__udivdi3'
> > /home/smcnutt/27xx/u-boot.git/lib/display_options.c:69: undefined 
> > reference to `__umoddi3'
> > /home/smcnutt/27xx/u-boot.git/lib/display_options.c:70: undefined 
> > reference to `__udivdi3'
> 
> Man, I knew ARM sucked, but I didn't know it was this bad :-)

Heh. Wait. So far we don't even deal with things like caches ;-)

> which means that in order to support support printing 64-bit numbers on ARM,
> we might need to completely rewrite print_size() to avoid division on 64-bit
> numbers.

This actually makes little sense to me. Avoiding this here will just
make the problem pop up somewhare else later.

> Wolfgang, do you have any suggestions?

Not really. The thing is that I don't see any such problem:


Not really. The thing is that I don't see any such problem:

$ ./MAKEALL da830evm
Configuring for da830evm board...
   text    data     bss     dec     hex filename
 155610    4876  295320  455806   6f47e /work/wd/tmp-da830evm/u-boot

--------------------- SUMMARY ----------------------------
Boards compiled: 1
----------------------------------------------------------

Seems to be a toolchain issue. [ELDK rulez :-)]


Ah. With "USE_PRIVATE_LIBGCC=yes" I see this one:

	undefined reference to `__aeabi_uldivmod'

Note that this is __aeabi_uldivmod, not __udivdi3.


Which version of compiler / which tool chain are you using?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Sorry, but my karma just ran over your dogma.

[U-Boot] Building for da830 fails

[Nick Thompson]

On 10/05/10 22:17, Wolfgang Denk wrote:
> In message <4BE43218.2060209@freescale.com> you wrote:

>> which means that in order to support support printing 64-bit numbers on ARM,
>> we might need to completely rewrite print_size() to avoid division on 64-bit
>> numbers.
> 
> This actually makes little sense to me. Avoiding this here will just
> make the problem pop up somewhare else later.

True, but the extra library (and abi workaround) bloat is not necessary in
this particular case.

The proper fix is to either insist on a toolchain that supports 64bit divides,
or avoid using features not available in all toolchains that you wish to support.

In the later case, rewriting the function would be a good idea wouldn't it?

The eabi stub you submitted is only good as long as C++ and exceptions are not
used by U-Boot. Exceptions in particular are a powerful way to clean up error
handling code - can we ever say never?

Regards,
Nick.

[U-Boot] Building for da830 fails

[Wolfgang Denk]

Dear Nick,

In message <4BE91C64.9050402@ge.com> you wrote:
>
> True, but the extra library (and abi workaround) bloat is not necessary in
> this particular case.

I agree that we can avoid the 64 bit division here - at the cost of
code that becomes much more difficult to read and understand.

Look at code like this:

+	f = size & ((1ULL << d) - 1);
...
-	if(size % d) {
-		m = (10 * (size - (n * d)) + (d / 2) ) / d;
+	if (f) {
+		m = (10ULL * f + (1 << (d - 1))) >> d;


We make things more easy for the compiler at the cost of making it
way more difficult for us humans.  I think this is a move in the wrong
direction.  Normally we try to go exactly the opposite direction.

> The proper fix is to either insist on a toolchain that supports 64bit divides,

I think we should indeed be able to rely on the tool chain providing
such functions. Of course we will try to support broken ones as far
as possible, but not there is a limit - for example, when we risk
hurting ourself.

> or avoid using features not available in all toolchains that you wish to support.

We never claimed to support "all toolchains" - for example, recent
versions of U-Boot cannot be compiled any more with gcc-2.95.x - but
is this really an issue?  I don't think so.

> In the later case, rewriting the function would be a good idea wouldn't it?

I am not really convinced.  Readability and maintainability are
precious properties of code.

> The eabi stub you submitted is only good as long as C++ and exceptions are not
> used by U-Boot. Exceptions in particular are a powerful way to clean up error
> handling code - can we ever say never?

No, we cannot. But we do :-)


<asbestos underwear>

Here we go:

We will never use C++ code for the implementation of U-Boot.

</asbestos underwear>

:-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
To program is to be.

[U-Boot] Building for da830 fails

[Nick Thompson]

On 11/05/10 11:39, Wolfgang Denk wrote:
> Dear Nick,
> 
> In message <4BE91C64.9050402@ge.com> you wrote:
>>
>> True, but the extra library (and abi workaround) bloat is not necessary in
>> this particular case.
> 
> I agree that we can avoid the 64 bit division here - at the cost of
> code that becomes much more difficult to read and understand.
> 
> Look at code like this:

Yes, I wrote (some of) it :-)

> 
> +	f = size & ((1ULL << d) - 1);
> ...
> -	if(size % d) {
> -		m = (10 * (size - (n * d)) + (d / 2) ) / d;
> +	if (f) {
> +		m = (10ULL * f + (1 << (d - 1))) >> d;
> 
> 
> We make things more easy for the compiler at the cost of making it
> way more difficult for us humans.  I think this is a move in the wrong
> direction.  Normally we try to go exactly the opposite direction.

I've certainly made your point here. It's taken me 3 version to make it work,
but, maybe with with a little commenting, I think that's readable. I'm not
sure that:

	n = size / d;

	if(size % d) {
		m = (10 * (size - (n * d)) + (d / 2) ) / d;
		...

is really any more readable is it?

Me: What is '(size - (n * d))'? Oh, its just '(size % d)'. Why is it
calculating that twice???

Maybe I'm just allergic to divides - especially when working with variables 
containing powers of two. That's what I get for working on ARM processors for
so long...

How about:

	n = size >> d
	f = size & ((1ULL << d) - 1);

	/* If there's a remainder, deal with it */
	if (f) {
		roundup = 1 << (d - 1); /* 0.5 << d */
		m = (10ULL * f + roundup) >> d;
		...

?

[...]

>> or avoid using features not available in all toolchains that you wish to support.
> 
> We never claimed to support "all toolchains" - for example, recent
> versions of U-Boot cannot be compiled any more with gcc-2.95.x - but
> is this really an issue?  I don't think so.

I didn't say "all toolchains", but "all toolchains that you wish to support".
In this case, both MontaVista and CodeSourcery's latest ARM compilers don't work.

Should you treat the cause or the symptom? Personally, I prefer the former. The
eabi compat function feels more like the latter.

In the interests of not holding back other CPU's though, I guess I can live with
it.

[...]

>> The eabi stub you submitted is only good as long as C++ and exceptions are not
>> used by U-Boot. Exceptions in particular are a powerful way to clean up error
>> handling code - can we ever say never?
> 
> No, we cannot. But we do :-)
>
>
> <asbestos underwear>

Blimey. I can hear the chafing from here ;-)

Regards,
Nick.

[U-Boot] Building for da830 fails

[Scott McNutt]

Wolfgang Denk wrote:
> Ah. With "USE_PRIVATE_LIBGCC=yes" I see this one:
> 
> 	undefined reference to `__aeabi_uldivmod'
> 
> Note that this is __aeabi_uldivmod, not __udivdi3.
> 
> 
> Which version of compiler / which tool chain are you using?

gcc 4.1.2

--Scott