I am trying to add a version number to my program, to be located at an
absolute flash address.
But it looks like I can't get avr-objcopy to copy the section that I have
put this data in.
I have in my .C file:
asm(" .section .version,\"x\"\n"
"optboot_version: .word " MAKEVER(OPTIBOOT_M
Using the ubuntu 11 install of avr-gcc/etc (4.5.3) I'm having a problem where
avr-objdump is not including any intermingled source code for the
main() function
of the optiboot .elf or .o files. The same .elf file with
(supposedly) the same version
of binutils (GNU objdump (GNU Binutils) 2.20.1.201
well, based on my experiences so far, I was expecting an answer of the
form "that's this issue here, even though the description doesn't
sound anything alike", or "you fool! objdump was never intended to
disassemble the .init9 subsection!"
___
AVR-GCC-li
Ah. Encouraging noises!
This seems stranger than y'all think...
I DO get disassembly; I've just lost the source intermingling. And
only for main(); once the disassembly gets to latter functions, the
source comes back (main() is the only function put in the .init9
section.)
I'll play with some of
Ok. By default the code is compiled with "-g", which is giving me the
described behavior. I get that same behavior with "-gstabs"...
If I use "-ggdb" OR "-gdwarf-2", I get correct behavior.
(Isn't -ggdb the default?)
___
AVR-GCC-list mailing list
AV
> How does it compile if you change the C code to this?:
> [manually factoring out the common code]
Yes, that will fix this particularly obvious instance, but it looks
like gcc is failing to factor out common code like this in less
obvious places as well...
(Hmm. It behaves differently (correctl
On Jan 26, 2012, at 2:10 PM, Georg-Johann Lay wrote:
> I tested the code with avr-gcc 4.5 and command line options -Os -mmcu=atmega8
>
> With the attributes, the object size is 54 bytes.
> Without the attributes the object size is 64 bytes.
With 4.5.3 ? Whatever this issue is, it apparently snuc
> 1. If you complain of missed optimisations, you should post the command line
> switches you have used, the -Ox switch at least.
Yes. Sorry. Corrected recently.
> 2. Don't use the naked attribute if you don't understand its implications -
> here, main uses stack frame which has not been creat
Oops. I have been forgeting to make sure to cc the list. And using the wrong
from address as well... So I'm going to dump some of the older messages; they
may be a repeat for some of you.
On Jan 27, 2012, at 3:23 AM, Georg-Johann Lay wrote:
>> 4.5.3 ? Whatever this issue is, it apparently s
See also
https://docs.google.com/file/d/0B6dMB5dovDUZRlhzdlZWTk9mTWc/edit?usp=sharing
(this is gcc-optimize-bug.txt)
I have this relatively straighforward implementation of a a couple of pins
worth of software PWM:
void pwmcycle(void)
{
unsigned char pwm1, pwm2, pwm3, pwm4, pwm5, level_delay;
Historically, from the avr-gcc 4.3.2 compiler used in Arduino, though
several intermediate versions, the compiler has become more and more
aggressive about in-lining "small" functions, and has done an
increasingly bad job of detecting "small" on AVRs (perhaps it bases
its decisions on "intermediate
Hmm. Particularly interesting is this series of "Considering"
paragraphs. about 42 all together (one for each call to move3Servos()
in loop()?)
Considering void move3Servos(Servo, float, Servo, float, Servo, float,
float) with 87 size
to be inlined into void loop() in oiOSoul.ino:3
Hmm. So I looked at the various command-line parameters other than
-fno-inline-small-functions.
>> max-inline-insns-singleSeveral ... This only affects functions declared
>> inline and methods implemented in a class declaration (C++). The default
>> value is 400.
>> max-inline-insns-autoWhen yo
Another interesting data point or two:
1) This goes back to at least 4.7
2) It's not avr-specific (as you might begin to suspect, given
previous discussion.)
I can get the same sort of bad behavior out of gcc for x86:
BillW-MacOSX-2<10405> /sw/lib/gcc4.7/bin/g++-fsf-4.7 -c -Os -w foo.cpp
-fno-inli
I've submitted https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65740
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
They can't be "depended upon" to work, but those examples have had their
code generated carefully examined to ensure that they do work.
Several of the examples are also in the .init3 section, which executes
essentially before C is set up, so they're somewhat free to do what they
want. Some other
Discovered on Arduino (4.9.2-atmel3.5.4) (
http://forum.arduino.cc/index.php?topic=556674.0 )
So I have this pretty trivial avr-gcc program:
#include
void serialEvent() __attribute__((weak));
void loop();
void serialEventRun(void)
{
#ifndef OMITBUG
if (serialEvent) serialEvent();
#endif
}
in
3
;
#else
PORTB = 1;
#endif
#endif
}
On Fri, Jul 6, 2018 at 6:10 PM, Bill Westfield wrote:
> Discovered on Arduino (4.9.2-atmel3.5.4) ( http://forum.arduino.cc/index.
> php?topic=556674.0 )
> So I have this pretty trivial avr-gcc program:
>
> #include
>
> void
18 matches
Mail list logo
