Compilation options and vfprintf

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

 

In my .lss file I see this huge function vfprintf.   What is generating this and how can I get rid of it?

 

Looking at my compilation options I see all this that I have been using for years but really have no idea what any of it is for or if I need it

 

-Wall

-gdwarf -2

-std=gnu99

-Os

-funsigned -char

-funsigned -bitfields

-fpack -struct

-fshort -enums

 

 

Update:

In the Custom Compilations Options,  there is an entry for [Linker Options], when I click it  -Vl, -u,vfprintf   appears.  Well this looks like the source, what is this for??

 

Last Edited: Wed. Oct 8, 2014 - 09:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's not a compilation option that's doing it, it is a linker option, specifically -Wl,-u, vfprintf 

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

Right, you must have missed my last sentence.    I would still like to know what all the options are for....is there some reference document

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

http://www.nongnu.org/avr-libc/u...

 

Quote:

Since the full implementation of all the mentioned features becomes fairly large, three different flavours of vfprintf() can be selected using linker options. The default vfprintf() implements all the mentioned functionality except floating point conversions. A minimized version of vfprintf() is available that only implements the very basic integer and string conversion facilities, but only the # additional option can be specified using conversion flags (these flags are parsed correctly from the format specification, but then simply ignored). This version can be requested using the following compiler options:

   -Wl,-u,vfprintf -lprintf_min

If the full functionality including the floating point conversions is required, the following options should be used:

   -Wl,-u,vfprintf -lprintf_flt -lm

Limitations:

  • The specified width and precision can be at most 255.

Notes:

  • For floating-point conversions, if you link default or minimized version of vfprintf(), the symbol ? will be output and double argument will be skiped. So you output below will not be crashed. For default version the width field and the "pad to left" ( symbol minus ) option will work in this case.
  • The hh length modifier is ignored (char argument is promouted to int). More exactly, this realization does not check the number of h symbols.
  • But the ll length modifier will to abort the output, as this realization does not operate long long arguments.
  • The variable width or precision field (an asterisk * symbol) is not realized and will to abort the output.

 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Thu. Oct 9, 2014 - 01:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wonder how that linker option got in there.  Its been there for years and I have been carrying around the function all this time which I have never used.

I removed it, and the code reduced around 1.5K bytes.   Which is huge!

 

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

no idea what any of it is for or if I need it

They're googleable.  Of the top of my head:

 

-Wall  - enable all warnings.

-gdwarf -2  - generate "dwarf-2" style debugging information.  This causes the .o and .elf files to contain additional info used by the debugger, but should not have any (much?) effect on the actual binary.

-std=gnu99   - enables C99 language constructs with gnu extensions.

-Os  - optimize for code size.

-funsigned-char  - Make "char" be unsigned by default.  (somewhat controversial and potentially not backward compatible with older C programs, but not something that should bloat code.)

-funsigned-bitfields - same thing for bitfields in a structure.  Less controversial and problematic, I think.

-fpack-struct - pack structures - don't add fillers to cause "special" alignment for larger datatypes.  Irrelevant on avr, but can be really important on 32bit cpus.

-fshort-enums - enums become a data type that is as small as can support the range of the enum, rather than always being ints.  I think.

 

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

I wonder how that linker option got in there. 

At some time you dabbled with printf(%f) I'm guessing. To enable that you pass -Wl,-u,vfprintf and -lprintf_flt to the linker. I'd check you makefile and see if you also have -lprintf_flt there too. It won't actually matter as long as you don't call printf() but it's just "messy" leaving links against things you don't need. It also means that if you do use any forum of printf() you will be using the "big one" rather than the standard one. On the other hand perhaps it was because you were trying to use the small printf()? (printf_min)

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

I set up the project back in 2009 and never looked at the config settings again.   I may have copied the settings from some post here,, or maybe they are defaults.

I have no specified make file.(this is all through Studio 4.18)

There is one other linker option "-lm", which I guess has something to do with math functions.   Which is odd to me, isn't that why you would put this statement in your code to make it nice and visible: #include <math.h>

Last Edited: Thu. Oct 9, 2014 - 12:19 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

-lm is always a good choice until you reach later compiler version (not sure if it was 4.7 or 4.8). The fact is that GCC has some float math stuff built into the standard libc but it's written (in C) for 32/64 bit PCs and is either inefficient or just plain wrong for 8bit AVR. So there's a library (libm.a) mostly in hand crafted AVR assembler that is accurate, small and fast. So you should always link with libm.a to use it (if you use float) in preference to libc.a. As always it doesn't actually hurt to -l against a library you don't use. But if you do use float it's fairly vital. In a later version of the avr-gcc compiler driver things were changed to always include an implied -lm anyway.

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

In the library window, there are two settings:

libprintf_flt.a    - I use my own print functions, so I don't see that I need this  (its just always has been there)

libm.a   (I do use floats, I may put this here for this reason)

 

The Avr-gcc is dated WinAVR-20100110   10/1/2010?

 

 

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

Yes that's Jan 2010 version (4.3.3). Atmel's current offering is 4.8.1 - quite an improvement.

 

As I say you do want -lm with such an old version of the compiler. In fact I'd say it was vital if you do use float.

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

The sequence of the linker flags is also important, at least when using the library found at http://download.savannah.gnu.org.... (I am using it because its libc also implements the API found in time.h, whereas the one that Atmel supplies does not.) I had to change the sequence in the linker project properties of AS6.2 such that libm and libprintf_flt come first and libc comes last. If I put libc first I get the question mark instead of my float variable. I think what happens is that the linker finds the printf function first in libc and then does not bother to substitute it with the one found in libprintf_flt.

 

See also similar findings discussed at http://stackoverflow.com/questio....