WINAVR - 20100110, critical bugs known ?

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

Is there a way to see, if critical bugs are present on the actual WINAVR - 20100110 ?

- AVR GNU Compiler Collection (GCC) 4.3.3
- avr-libc 1.6.7cvs

I meant such bugs, which cause no warnings and no errors but generate real false code :!:

Not such bugs, which generate only unoptimized, but functional code.
And not bugs related to the Atmel AVR-toolchain (avr-libc 1.7.0).

Since I have seen, that a new WINAVR was announced.
So I wonder, if it was only for improvement or also to solve critical bugs.

Until now, I got the impression, that all my code generated with the actual WINAVR - 20100110 was correct compiled.

Peter

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

Quote:

Since I have seen, that a new WINAVR was announced.
So I wonder, if it was only for improvement or also to solve critical bugs.

As has been stated, in the thread announcing that the WinAVR core task force (i.e. Eric Weddington et al) would do a new release, the first priority is to fix such "real bugs", and then if resources permit fix annoying stuff, less.than-optimal-code-generation etc.

Avr-libc has a bug tracker at Savannah (go to the avr-libc home page and you will get a link to the Savannah pages). Not sure if that is where avr-gcc also is handled. If one of the knights in shining armour comes by they will likely let us know..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

1)WinAVR doesn't consider using more that 100% ram an error. There's not even a warning. That's a bug in my book. All kinds of memory corruption occur if the code is used anyway.

2)It is quite easy to get a stack overflow if you don't leave enough ram free. For my programs that is about 500 bytes.

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

Quote:

1)WinAVR doesn't consider using more that 100% ram an error. There's not even a warning. That's a bug in my book. All kinds of memory corruption occur if the code is used anyway.

But that's under your control in the linker script?!
Quote:

2)It is quite easy to get a stack overflow if you don't leave enough ram free. For my programs that is about 500 bytes.

Are you suggesting that the compiler should generate run time stack checking for code running on an 8bit micro? I don't think so!

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

Re 1) So, you'd need some way to state the amount of available memory, and tell the toolchain about it. Anyway, I suppose it would be much easier to implement some kind of warning/error in avr-size rather than in the tool chain as such (i.e. in avr-ld).

Re 2) Are you asking for the tool chain to warn/err at compile time for a stack overflow at run time? While not unfeasible, determining the required amount of stack mechanically is not easy. (I suppose most people do it lagrely by "rule-of-thumb" and similar.) There has been threads about this here at AVRfreaks in the past. I would be surprised if this makes it into the avr-gcc tool chain.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Re Re 1)
After compiling and linking with avrstudio there is a summary of memory usage. That stated (forgot exact number, fixed program months ago, faulty sourcecode no longer available):
AVR Memory Usage
----------------
Device: atmega328p
Program: 16060 bytes (49.0% Full)
(.text + .data + .bootloader)
Data: 2097 bytes (102.4% Full)
(.data + .bss + .noinit)
EEPROM: 177 bytes (17.3% Full)
(.eeprom)
That must mean the compiler was aware of the device specs and usage above 100% could have been reported as error (unless the summary is made by avrstudio, and then avrstudio could make a fuzz about it.)
Took me hours of debugging before I noticed the 102% ram usage..

2)Runtime stack checking would be a nice feature to have for debugging purposes. (even if only in the simulator) Having to check if the program crashes after every line of code that is added beyond a certain point is tiring.

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

I've concocted a rudimentary utility which allows to check the mapfile for size/placement of named sections, and this could be used for checking the RAM too. It throws an error when a configured limit is "violated" so could be used in makefiles. It works out of the mapfile because some of the information appears to be lost in .elf (namely, the .progmem section must not get beyond the 64kB line, but there may be others).

It even does some static stack usage analysis, but a severely limited one, read the rather long list of limitations.

JW

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

Quote:

That must mean the compiler was aware of the device specs and usage above

The output you are talking about does not come from the compiler, but from the avr-size utility I was talking about. For it to tell you about the usage, you tell it what device it should assume. Look at the line(s) above the output you quote and you will see the invocation of avr-size, incl the specification of AVR model.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Quote:

Took me hours of debugging before I noticed the 102% ram usage..

Then, like I say, fix this in the linker script. As it stands all of 48,88,168,328 (and some others) share a single linker script so the max memory is set to a stupidly large figure to cover all of them (and possibly larger future devices - 648 perhaps?). The linker polices the .text and .data/.bss sizes but as they are so large it never hits the limit. So use a 328 specific linker script with the figures for flash, RAM and eeprom set to the actual sizes of the device and then you will get an "section overflow" error from the linker if you break the bounds.

BTW I guess you know that "Data:" shouldn't really be over about 75-80% as you need some room for stack

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

Quote:

BTW I guess you know that "Data:" shouldn't really be over about 75-80% as you need some room for stack


"some"?!?
Quote:

2)It is quite easy to get a stack overflow if you don't leave enough ram free. For my programs that is about 500 bytes.

Wow--I strive to keep a flat model and few/small automatic variables to keep stack usage minimal on these >>MICROcontroller<< apps. So alboni's style must be much different than mine. alboni--do you have nested interrupts with extensive ISRs? That usually eats up a chunk of stack space. A recursive algorithm that goes quite deep? A very structured program with many tiers? Lots of local/automatic storage?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Must have recursive code with a big local variable or parameter?

The largest known prime number: 282589933-1

Without adult supervision.

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

Quote:
Took me hours of debugging before I noticed the 102% ram usage.

Been thee done that, but now I always look at the output stats & check for warnings as well! An ignored warning will often bite you in the arse!

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?