Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

looking for _divsi3

looking for _divsi3

2005-06-21 by roelofth

Hi all,

As a new member I would like to ask you a question.

I'm getting these error's from arm-elf-ld :

div_error.o: In function `foo':
div_error.c:(.text+0x18): undefined reference to `__divsi3'

Now I know that these functions are in libgcc.a
and apparently the compiler includes that :

roelofh@compraq:~/$ arm-elf-gcc -print-libgcc-file-name
/usr/local/arm/lib/gcc/arm-elf/3.4.4/libgcc.a

So it knows where the library is.

But the following still generates error's :

#include "lpc2292.h"

#define true 1
#define false 0

#define xtal 12000

typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned long uint32_t;

void foo(uint16_t baudrate)
{
        uint16_t temp16;
        uint32_t temp32;
        union bitrate_divisor
        {
                uint16_t divisor_word;
                uint8_t divisor_byte[2];
        } bdrate;
        uint8_t multiplier;
        uint8_t vpbdivider;

        multiplier=5;
        vpbdivider=2;

        temp32=(uint32_t)(multiplier*xtal*1000);
        temp32=temp32/vpbdivider;
        temp16=temp32/(16*baudrate);
        // temp16 should hold the value 195
        bdrate.divisor_word=temp16;
        u0dll=bdrate.divisor_byte[0];
        u0dlm=bdrate.divisor_byte[1];
}


int main(void)
{
        foo(9600);

        while(true)
        {
        }
}


This is what I use to compile and link :

arm-elf-gcc -mcpu=arm7tdmi -DROM_RUN -Os -std=gnu99 -I. -c
-mapcs-frame -Wall div_error.c -o div_error.o
arm-elf-ld -Tlpc2292-rom-v2.ld -Map=div_error.map div_error.o crt0.o
--output div_error.elf


Including math.h did not work.

I downloaded and compiled the sources, with newlib 1.13,
from rod.info.

Any and all comments, remarks and suggetions will be
very much appreciated.

Thank you.

roelof

RE : [lpc2000] looking for _divsi3

2005-06-21 by Yannick Hildenbrand

Hello,
 
I had the same kind of problem, nearly for the same reasons. If you take
a look at the ARM7 instruction set, you will notice that there is no
division instruction. Only the multiplication is available.
 
So, when your code contains divisions, like the one you do for computing
the divisor latch value, the compiler calls library functions located,
as you wrote, in the libgcc.a archive. The __divsi3 makes the job with
the help of software emulation.
 
The message you get comes from the linker. It doesn’t find the related
entry because you probably omitted to include libgcc.a in the files
specification for the linker. The linker command line shows that you
have a linker script (lpc2292-rom-v2.ld). Check if libgcc.a appears in
it. Another possibility is what I did.
 
*     In the linker command, add ‘–Llibpath –lgcc’ in the option list,
where libpath is the path where the libgcc.a archive resides.
 
This was helpful for me with GCC 4.0.0 but should also work with
GCC3.4.4.
 
Let me know …
 
Regards.
 
Duke
 
-----Message d'origine-----
De : lpc2000@yahoogroups.com [mailto:lpc2000@yahoogroups.com] De la part
de roelofth
Envoyé : mardi 21 juin 2005 18:28
À : lpc2000@yahoogroups.com
Objet : [lpc2000] looking for _divsi3
 
Hi all,

As a new member I would like to ask you a question.

I'm getting these error's from arm-elf-ld :

div_error.o: In function `foo':
div_error.c:(.text+0x18): undefined reference to `__divsi3'

Now I know that these functions are in libgcc.a
and apparently the compiler includes that :

roelofh@compraq:~/$ arm-elf-gcc -print-libgcc-file-name
/usr/local/arm/lib/gcc/arm-elf/3.4.4/libgcc.a

So it knows where the library is.

But the following still generates error's :

#include "lpc2292.h"

#define true 1
#define false 0

#define xtal 12000

typedef unsigned char uint8_t;
typedef unsigned short uint16_t;
typedef unsigned long uint32_t;

void foo(uint16_t baudrate)
{
        uint16_t temp16;
        uint32_t temp32;
        union bitrate_divisor
        {
                uint16_t divisor_word;
                uint8_t divisor_byte[2];
        } bdrate;
        uint8_t multiplier;
        uint8_t vpbdivider;

        multiplier=5;
        vpbdivider=2;

        temp32=(uint32_t)(multiplier*xtal*1000);
        temp32=temp32/vpbdivider;
        temp16=temp32/(16*baudrate);
        // temp16 should hold the value 195
        bdrate.divisor_word=temp16;
        u0dll=bdrate.divisor_byte[0];
        u0dlm=bdrate.divisor_byte[1];
}


int main(void)
{
        foo(9600);

        while(true)
        {
        }
}


This is what I use to compile and link :

arm-elf-gcc -mcpu=arm7tdmi -DROM_RUN -Os -std=gnu99 -I. -c
-mapcs-frame -Wall div_error.c -o div_error.o
arm-elf-ld -Tlpc2292-rom-v2.ld -Map=div_error.map div_error.o crt0.o
--output div_error.elf


Including math.h did not work.

I downloaded and compiled the sources, with newlib 1.13,
from rod.info.

Any and all comments, remarks and suggetions will be
very much appreciated.

Thank you.

roelof





  _____  

Yahoo! Groups Links
*         To visit your group on the web, go to:
http://groups.yahoo.com/group/lpc2000/
  
*         To unsubscribe from this group, send an email to:
lpc2000-unsubscribe@yahoogroups.com
<mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe> 
  
*         Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service <http://docs.yahoo.com/info/terms/> . 


[Non-text portions of this message have been removed]

Re: RE : [lpc2000] looking for _divsi3

2005-06-22 by roelof t Hooft

--- In lpc2000@yahoogroups.com, "Yannick Hildenbrand"
<duke.whisky@f...> wrote:
> Hello,
>  
> I had the same kind of problem, nearly for the same reasons. If you take
> a look at the ARM7 instruction set, you will notice that there is no
> division instruction. Only the multiplication is available.

Hmmm, just like a DSP, has one function but not the opposite.


> The message you get comes from the linker. It doesn't find the related
> entry because you probably omitted to include libgcc.a in the files
> specification for the linker. The linker command line shows that you
> have a linker script (lpc2292-rom-v2.ld). Check if libgcc.a appears in
> it.

I was hoping to avoid the linker script :-)
But still checked it for a reference to libgcc.a, none found.
Now I have to read about this linker script thingie, is
there somewhere a "linker script for dummies" ?


> Another possibility is what I did.
>
> *     In the linker command, add `–Llibpath –lgcc' in the option list,
> where libpath is the path where the libgcc.a archive resides.

I allready tried that, makes no difference.
If I give ld the wrong path or library name it will complain
to me about not finding the library.
Even with no -L and -l options on the command line it will
include libgcc.

To me it looks like the compiler knows where to go for the
"function" but when it gets there it finds no reference to
it, like this error "undefined reference to `__udivsi3'"
Some more google to do I guess.

Thank you for responding.

roelof
  


#LFLAGS=-Tlpc2292-rom-v2.ld -Map=MiniGator.map --cref
-L/usr/local/arm/lib/gcc/arm-elf/3.4.4/ -lgcc
LFLAGS=-Tlpc2292-rom-v2.ld -Map=MiniGator.map --cref

Re: [lpc2000] looking for _divsi3

2005-06-24 by 42Bastian Schick

roelof

> This is what I use to compile and link :
>
> arm-elf-gcc -mcpu=arm7tdmi -DROM_RUN -Os -std=gnu99 -I. -c
> -mapcs-frame -Wall div_error.c -o div_error.o
> arm-elf-ld -Tlpc2292-rom-v2.ld -Map=div_error.map div_error.o crt0.o
> --output div_error.elf

Do not link with ld, use gcc for all. gcc knows where to search the 
libraries.

And BTW: I'd suggest to use Thumb mode. You'll mostly find it runs at same 
speed,
with less footprint.

-- 
42Bastian Schick

Re: looking for _divsi3

2005-06-27 by roelof t Hooft

Hi,

Just a followup on my own message.
First thanks to yannick and bastian.

The whole thing compiles just ok by
using arm-alf-gcc to link.

The following is the makefile I use :

STARTUP=crt0_test

MCU=arm7tdmi
OPT=s

AFLAGS=-mcpu=$(MCU) -DROM_RUN -I.
CFLAGS=-mcpu=$(MCU) -O$(OPT) -std=gnu99
LFLAGS=-Tlpc2292-rom-v2.ld -nostartfiles
-Wl,-Map=MiniGator.map,--cref,-nostdlib -s

CC=arm-elf-gcc
LNKR=arm-elf-ld
OBCP=arm-elf-objcopy

all:
        $(CC) $(CFLAGS) -c MiniGator.c -o MiniGator.o
        $(CC) $(CFLAGS) -c mg_system.c -o mg_system.o
        $(CC) $(CFLAGS) -c mg_ucuart.c -o mg_ucuart.o
        $(CC) $(AFLAGS) -c $(STARTUP).S -o crt0.o
        $(CC) $(LFLAGS) -o MiniGator *.o
        $(OBCP) -O ihex MiniGator MiniGator.hex

clean:
        rm -f MiniGator.hex
        rm -f *.o
        rm -f MiniGator.elf
        rm -f MiniGator.map


Thank you,

roelof

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.