avr32-gcc - how to disable 'built-in' libraries

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello guys,

is there any way to prevent the avr32-gcc compiler using 'built-in' library functions like memcpy?

Actually I would like to use purely my own code in a study project.

An example: the compiler wants to initialize a local struct by calling memcpy.

typedef struct
{
tUI8 left;
tUI8 top;
tUI8 right;
tUI8 bottom;
}tRect;

void my_func(...)
{
tRect tmp_rect = {1U, 1U, 3U, 3U};

draw(0U, tmp_rect);
...

Can I force the compiler somehow to choose another initialization method?

Anyway why does the compiler suppose that calling a subroutine is the most efficient way to handle four simple bytes? Could it be an alignment issue?

Thank you very much for your help in advance.

Best regards,
Menahem

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Menahem,

in more than 95% of all cases I'd say "let the compiler do his job" or I'd ask:
"are you sure that you're able to do it better?". If so, I'd assume that build-in functions are declared weak (you may provide some disassembled code or check yourself with objdump which versions are actually used in your code). As result you should be able to implement your own versions.

Did you have a look into the gcc's user manual? There do exist different link options like -fno-builtin, -fno-builtin-function. I'm not aware of avr32-gcc behavior so it's up to you to check for details.

-sb

PS: I really doubt that the compiler uses memcpy for above variable initialization. How do you think that this is the case?!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Sambrown,

first of all many thanks for your help.

Actually I am quite sure that the compiler does his job better than me. :)

I have no problem with linking, I could disable the standard library and use my own routines instead.

But when I try to initialize my rect as a local struct I get the followings:

**** Build of configuration Default for project AVR_PL ****

C:\Menahem\ECLIPSE_PRJ\AVR_PL\make.bat all
Start build process
AVR32/GNU C Compiler version: (AVR_32_bit_GNU_Toolchain_3.4.0_332) 4.4.3
AVR32/GNU Assembler version: GNU assembler (AVR_32_bit_GNU_Toolchain_3.4.0_332) 2.22
AVR32/GNU Linker version: (AVR_32_bit_GNU_Toolchain_3.4.0_332) 4.4.3
____________________________________________________________________________________
Compile: source/opsys/os_task.c
source/opsys/os_task.c:39: warning: conflicting types for built-in function 'memcpy'
____________________________________________________________________________________
Build: AVR_PL
text data bss dec hex filename
4348 20 16832 21200 52d0 AVR_PL.elf

**** Build Finished ****

Side note: I had to insert a dummy memcpy function in the source, that's why the warning above.

And I found this in my lss file:

...
void task_1ms(void)
{
80000a10: eb cd 40 80 pushm r7,lr
80000a14: 20 1d sub sp,4
C:\Menahem\ECLIPSE_PRJ\AVR_PL/source/opsys/os_task.c:45
//static tBOOL led_on = TRUE;
static tUI32 timer = 0U;
tRect rect = {32U,16U,63U,31U};
80000a16: 30 4a mov r10,4
80000a18: fe cb 08 84 sub r11,pc,2180
80000a1c: 1a 97 mov r7,sp
80000a1e: 1a 9c mov r12,sp
80000a20: cf 6f rcall 80000a0c
C:\Menahem\ECLIPSE_PRJ\AVR_PL/source/opsys/os_task.c:50

"sub r11,pc,2180" refers to a section where the 32, 16, 63, 31 values can be found.

80000194 :
80000194: 20 10 3f 1f .?.

Anyway I'll try those options you mentioned.

Thank you again and best wishes,
Menahem

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The "use your own libraries" issue is different from "change the optimization parameters that cause the compiler to use libc functions like memcpy to do internal structure initialization"

It ought to be a common problem...

Hmm. Try "-fno-builtin", though it may not work:
http://stackoverflow.com/questio...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've tried it and you are right:
just as it was explained under the topic you linked even in a freestanding environment the gcc requires some of these basic routines by all means.

By using the -fno-builtin option the compiler no more refers to memcpy as a built-in function (does not throw a warning when I implement a dummy one with a totally incorrect parameter definition*), however still calls it.

*Hmm, it sounds not so good at all. In this case I cannot implement my own version of these functions (especially not with different parameterization or functionality) as I won't notice when/where the compiler wants to call them - with horrible consequences. (Or should I try to implement them as strictly as possible and check the lss file regularly?)

After all I can live with that, in most cases (e.g. my earlier example) it can be simply avoided.

Thank you very much, Gentlemen.
BR,
Menahem

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Anyway why does the compiler suppose that calling a subroutine is the most efficient way to handle four simple bytes?

memcpy() would frequently be VERY optimized for each architecture, even for short copies. On an 8bit AVR, the obvious alternative of a bunch of load/store operations is NOT very efficient in either space or time. (I don't know from avr32...)

Implementing a fully-functional memcpy() on your own isn't difficult, especially if you're not so concerned with maximum performance. Back in the days before LGPL and more careful licensing of libc, a company I worked for had implemented ALL of the internally-called gcc function with separate non-viraly licensed code.