Nils Soderman wrote:
> Hello out there!
> I am trying to compile, with uint64_t variables, diverse algorithms...
> Getting error "undefined reference to `__udivdi3'"
> Have been trying with math.h and trying  to find the strings udivdi3 and
> umoddi3  in .h-files. No such luck!
> Can someone help me, please?
> Nils from Sweden

These are functions calls that the compiler generates to do 64bit
arithmetic operations (because they are not atomic instructions on a
32bit processor). The functions are provided by libgcc.a. You must
explicitly link this library if you have used the -nostdlibs option. You
do this with the linker option -lgcc.

Note that header files are not generally where functions 'live' they
usually merely declare functions. You need the declarations so the
compiler 'knows' hot to generate calls to them (and so it can check your
calls are valid). The functions you are having trouble with are
'internal' compiler helper functions, the code generator creates the
calls to them, for code like:

long long x = 10 ;
long long y = 3 ;
long long z = x / 3 ; // generates call to __udivdi3

Conceptually, no function is called, so no header is provided for
__udivdi3 etc. - you would not call them explicitly in your code.

Clifford

Clifford Slocombe wrote:
> Nils Soderman wrote:
>> Hello out there!
>> I am trying to compile, with uint64_t variables, diverse algorithms...
>> Getting error "undefined reference to `__udivdi3'"
>> Have been trying with math.h and trying  to find the strings udivdi3 and
>> umoddi3  in .h-files. No such luck!
>> Can someone help me, please?
>> Nils from Sweden
>
> These are functions calls that the compiler generates to do 64bit
> arithmetic operations (because they are not atomic instructions on a
> 32bit processor). The functions are provided by libgcc.a. You must
> explicitly link this library if you have used the -nostdlibs option. You
> do this with the linker option -lgcc.
>
> Note that header files are not generally where functions 'live' they
> usually merely declare functions. You need the declarations so the
> compiler 'knows' hot to generate calls to them (and so it can check your
> calls are valid). The functions you are having trouble with are
> 'internal' compiler helper functions, the code generator creates the
> calls to them, for code like:
>
> long long x = 10 ;
> long long y = 3 ;
> long long z = x / 3 ; // generates call to __udivdi3
>
> Conceptually, no function is called, so no header is provided for
> __udivdi3 etc. - you would not call them explicitly in your code.
>
> Clifford

ThankYou Clifford, for your answer!
As can be seen in the attached makefile the linker is using the
libgcc.a. But still producing the error "undefined reference to
`__udivdi3'" and others!
My code:
#include "AT91SAM7X256.h"
#include "Board.h"

#include "stdio.h"
#include <math.h>
#include <stdarg.h>
#include <stdlib.h>

#include <inttypes.h>

//+++++++++++++++++++++++++++++++++++++++++++++++++

void  CalculateDDSfractions ( UINT AD9834RefFrequency )
{
#define  help2to28times10  0xA0000000
  uint64_t  helpRefFq = AD9834RefFrequency;
  uint64_t  helpFraction;

  helpFraction = help2to28times10;

        helpRefFq /= 10;
        helpFraction /= helpRefFq;
  helpFraction /= ( helpRefFq / 10000000 );
};

+++++++++++++++++++++++++++++++++++++++++++
Usuing UINT instead of uint64_t produces:
..linking
arm-elf-ld -v -Map main.map -Tlinkconfig_RAM.cmd -o main.out crt.o
main.o timerisr.o timersetup.o isrsupport.o lowlevelinit.o blinker.o
TWI_ctrl.o commands.o display.o HandleDDS.o menu.o buttons.o SPI_ctrl.o
eepromhandler.o a2dmodule.o Smeter.o
-L%,E:/Program/yagarto/lib/gcc/arm-elf/4.1.1/libgcc.a -lc
GNU ld version 2.17
HandleDDS.o: In function `CalculateDDSfractions':
F:\ARMdev\WorkSpaceSF4G\QROlleNG_RAM/HandleDDS.c:430: undefined
reference to `__udivsi3'
F:\ARMdev\WorkSpaceSF4G\QROlleNG_RAM/HandleDDS.c:431: undefined
reference to `__udivsi3'
make: *** [main.out] Error 1


Oh, I really want to solve this!
Best regards
Nils S

You need to link libgcc.a after libc.a since the libc.a has
dependencies on libgcc.a but not the other way around.

arm-elf-ld [...] -lgcc -lc [...]

An alternative is to use an linker iteration group:

arm-elf-ld [...] -( -lgcc -lc -) [...]

but this is less efficient and should rather be used to resolve circular
dependencies rather than as a substitute for simply getting the link
order correct.

One wonders why you need an explicit path for libgcc.a but not for
libc.a? -lgcc should be all that is necessary. And the "-L%" what is
that - an ill-formed macro not expanded perhaps?


Clifford

Clifford Slocombe wrote:
> You need to link libgcc.a after libc.a since the libc.a has
> dependencies on libgcc.a but not the other way around.
>
> arm-elf-ld [...] -lgcc -lc [...]
>
> An alternative is to use an linker iteration group:
>
> arm-elf-ld [...] -( -lgcc -lc -) [...]
>
> but this is less efficient and should rather be used to resolve circular
> dependencies rather than as a substitute for simply getting the link
> order correct.
>
> One wonders why you need an explicit path for libgcc.a but not for
> libc.a? -lgcc should be all that is necessary. And the "-L%" what is
> that - an ill-formed macro not expanded perhaps?
>
>
> Clifford

THANK YOU Clifford!
I changed the link command to :
  $(LD) $(LFLAGS) -o main.out $(OBJECTS) -L$(EXTRA_LIBDIRS) -lc -lgcc
which solved the problem! I found "-L%,$(EXTRA_LIBDIRS)" somewhere, have
been using it for a year!!!
Thank you again!
Best regards
Nils S

Nils Soderman wrote:
> I found "-L%,$(EXTRA_LIBDIRS)" somewhere, have
> been using it for a year!!!

In a makefile, % is used as a wildcard for pattern matching. It is
difficult to see how it may have been intended to work here, but tha
fact that it appears in the output indicates that it has not been
expanded to anything useful. Make also has an automatic variable @%
defining "The target member name, when the target is an archive member."
according to the documentation. I am not sure what that means, but I
don't think that it is useful here either.

Note that posting the build log was the fastest way to get a definitive
answer (since my initial 'guess' was inaccurate).

Clifford

I just noticed something else about your original build log. You
specified the libgcc.a file in a -L option (presumably by way of the
EXTRA_LIBDIRS macro). -L specifies search paths for archives not the
archive itself. EXTRA_LIBDIRS in your case should be used only for
directories (folders) not the libraries themselves.

You either specify the archive alone with a fully qualified path or use
a -l (lower-case L) option to find an archive in any path specified by
-L. So you were never actually linking libgcc.a in any case, regardless
of the link order.

When using -l, the 'lib' prefix and '.a' extension are assumed - hence
-lgcc for libgcc.a.

Clifford

Clifford Slocombe wrote:
> I just noticed something else about your original build log. You
> specified the libgcc.a file in a -L option (presumably by way of the
> EXTRA_LIBDIRS macro). -L specifies search paths for archives not the
> archive itself. EXTRA_LIBDIRS in your case should be used only for
> directories (folders) not the libraries themselves.
>
> You either specify the archive alone with a fully qualified path or use
> a -l (lower-case L) option to find an archive in any path specified by
> -L. So you were never actually linking libgcc.a in any case, regardless
> of the link order.
>
> When using -l, the 'lib' prefix and '.a' extension are assumed - hence
> -lgcc for libgcc.a.
>
> Clifford

Thanks again!
makefile is like magic for me, me beeing mainly a hardware guy! But I
will learn...???
Best regards
Nils S