RE: [avr-gcc-list] fdevopen() uses calloc?

[Dave Hylands]

Hi J.C.,

I pulled fdevopen.o out of libc.a. It has the following symbols in it:

         U __do_clear_bss
         U __do_copy_data
00000006 C __iob
0000003e a __SP_H__
0000003d a __SP_L__
0000003f a __SREG__
00000000 a __tmp_reg__
00000001 a __zero_reg__
         U calloc
00000000 T fdevopen
00000090 t Letext

Lower case letters represent static variables. U is undefined symbols
(i.e. things that this object file needs). Uppercase letters (other than
U) represent symbols that this object file provides for other objects to
use.

I'm pretty sure that the __iob is the one that's causing fdevopen.o to
be linked in. When you pull in ANY symbol from an object file, the
ENTIRE object file gets pulled in.

So to provide a replacement, you'll need to replace everything that
fdevopen.o provides. The easiest way to do this would be to examine the
source.

--
Dave Hylands
Vancouver, BC, Canada
http://www.DaveHylands.com/


> -----Original Message-----
> From: J.C. Wren [mailto:address@hidden 
> Sent: Tuesday, January 20, 2004 11:04 PM
> To: address@hidden
> Subject: [avr-gcc-list] fdevopen() uses calloc?
> 
> 
> fdevopen() is using calloc(), which pulls in a lot of extra code.  Is 
> there any reason this couldn't use a static, instead? 
> 
> I wrote my own fdevopen function (slightly different name), but the 
> linker is still pulling in fdevopen(), even though I can find no 
> references to it.  Why would this be?  If I name my function 
> fdevopen(), 
> the linker gets all whiney about the size changing between my .o file 
> and the libc file. 
> 
> To write mine, I had to cheat and copy over stdio_private.h, 
> which is a 
> major hack.  What I'd like is an fdevopen() variant that 
> allows passing 
> a user provided block of memory.  Unfortunately, this has to 
> be of size 
> FILE, which is opaque, so we don't know how large a block of 
> memory to 
> declare. 
> 
> In lieu of fdevopen() using a static buffer, can fdevopen() be a weak 
> reference so at least overriding it doesn't cause the 
> compiler to get upset?
> 
>     --jc
> 
> _______________________________________________
> avr-gcc-list mailing list
> address@hidden 
> http://www.avr1.org/mailman/listinfo/avr-gcc-> list
> 
>