Re: [avr-gcc-list] Re: Patch Fix PR35013, PR27192
On Wednesday 16 April 2008 14:02, Andy H wrote: RFC A problem has come up trying to fix function pointer arthmetic bugs. [...] (It is difficult to understand all quickly.) A question: Is it safety to use common indirect call of function with avr6 at present moment? It is interesting, as indirect call is used in Avr-libc's EEPROM functions now. I have try a small program. Seems, the result is wrong (Binutils is 2.18, see avr-libc-dev discussion). Thanks, Dmitry. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] A Question Of Optmization
Ruud Vlaming wrote: Yeah, I think it is not as strange as it might seem. If you say -O0 the compiler will do exactly what you asked him to do. And this is what you intended. But if you let the compiler optimize, it recognizes that your variable TimerTick is set to 10 and will never change. So it will just make sure the location reserved for the variable is correctly filled, and then will loop forever. You must tell the compiler explicitly the variable TimerTick may be changed by a 'backdoor'. Try volatile TimerTick = 10; Ruud. Your answer here (after the little correction in your second post) is of course correct - he's missing the volatile. However, your explanation is not entirely accurate. I don't know if my rant here applies to you (Ruud), but it is hopefully informative to the OP (Karl) at least. It's a very common misunderstanding to think that -O0 tells the compiler to do exactly what the program asks, and turning on optimisation tells the compiler it can do smart tricks with your code. In fact, the compiler will *always* do *exactly* what your program code asks (baring bugs in the compiler, of course). Optimisation flags are really no more than hints - they will not affect the correctness of your program if you have written your code according to the language C and the way C compilers are required to implement that language. The flags let you fine-tune tradeoffs such as space and speed, or test or avoid experimental compiler features. But using -O0 is asking the compiler to be intentionally crippled and simple-minded as a possible aid to finding out what's wrong in your program. You are not *telling* the compiler to restrict itself in this way, merely *asking* it - a compiler can correctly return tightly optimised code when given a -O0 flag. You are not asking it to interpret your code in any other way, and the compiler is still free to remove any parts of your source code that it is sure will never run, or any variables that are never used. All you are doing is asking it not to try so hard to find such code. So while problems on the lines of it works with -O0, but not -Os or -O2 are almost always solved by putting volatile in the right place, it is important to remember that the source code with the missing volatile is wrong, even if it happens to work with -O0. It's not a case of you need volatile to make the code work with optimisations - it's a case of you need volatile to make the code correct. mvh., David ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] RE: Patch Fix PR35013, PR27192
-Original Message- From: Andy H [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 15, 2008 9:02 PM To: AVR-GCC Cc: Anatoly Sokolov; Weddington, Eric Subject: Re: Patch Fix PR35013, PR27192 3) Give up and dont permit any arithmetic. (Perhaps error or warning would still be needed) I really don't like this option, plus doing do would be a regression compared to 3.4.x. We had workable function pointer arithmetic there. I have a valid reason to do pointer arithmetic: using a bootloader that modifies itself. The bootloader would copy itself from the lower half of bootloader memory area to the upper half of the bootloader area, then call itself in the upper half. The bootloader had subroutines, so to access them involved taking a function pointer, adding an offset, then dereferenced them and do an indirect function call. It worked great. So this feature, while rare, is needed. Eric ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] [AVR gcc link error] relocation truncated to fit: R_AVR_13_PCREL ...
Hello, I get and install the last version of WinAVR (April 08 -GCC 4.3.0). I get this relocation truncated to fit: R_AVR_13_PCREL error during the link operation. I'm working with AVR Studio 4.12 I've read i should add -lm to the linker command to avoid this...but no success :( So i need your help to avoid this problem! Excuse my english ;) thanks for your help. Best regards emmanuel NB: My source code had no change between the WinAvr changing operation. The las winAvr installed was the 2006-04-21 one (GCC 3.4.6) and the link operation worked well (without -lm) Here is the build result: /avr-gcc.exe -mmcu=atmega128 -lm -minit-stack=0xFF0 -Wl,-Map=LCD.map main.o font8.o font74.o font62.o font54.o font48.o font46.o font36.o font72.o font24.o font12.o font106.o LCD128128fct.o lcd1font.o string_display_FR-EN.o usart.o eeprom.o Copernicus.o SP I16M.o GPS.o tactique.o ligne_depart.o SMG.o chrono_timer.o flash16M.o ADC.o angle_virement.o waypoint.o route.o USB16M.o histo_speed.o stats.o navigation_display.o sound.o display.o -LC:\WinAVR-20080411\lib -o LCD.elf c:/winavr-20080411/bin/../lib/gcc/avr/4.3.0/../../../../avr/lib/avr51\libc.a(fp_arccos.o): In function `__fp_arccos': (.text.fplib+0x24): *relocation truncated to fit: R_AVR_13_PCREL* against symbol `__subsf3' defined in .text section in c:/winavr-20080411/bin/../lib/gcc/avr/4.3.0/avr51\libgcc.a(_addsub_sf.o) c:/winavr-20080411/bin/../lib/gcc/avr/4.3.0/../../../../avr/lib/avr51\libc.a(square.o): In function `square': (.text.fplib+0x4): *relocation truncated to fit: R_AVR_13_PCREL* against symbol `__mulsf3' defined in .text section in c:/winavr-20080411/bin/../lib/gcc/avr/4.3.0/avr51\libgcc.a(_mul_sf.o) c:/winavr-20080411/bin/../lib/gcc/avr/4.3.0/../../../../avr/lib/avr51\libc.a(fp_powsodd.o): In function `__fp_powsodd': (.text.fplib+0x10): *relocation truncated to fit: R_AVR_13_PCREL* against symbol `__mulsf3' defined in .text section in c:/winavr-20080411/bin/../lib/gcc/avr/4.3.0/avr51\libgcc.a(_mul_sf.o) c:/winavr-20080411/bin/../lib/gcc/avr/4.3.0/../../../../avr/lib/avr51\libc.a(fp_powsodd.o): In function `__fp_powsodd': (.text.fplib+0x20): *relocation truncated to fit: R_AVR_13_PCREL* against symbol `__mulsf3' defined in .text section in c:/winavr-20080411/bin/../lib/gcc/avr/4.3.0/avr51\libgcc.a(_mul_sf.o) / -- Emmanuel Bourien Imartec ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] [AVR gcc link error] relocation truncated to fit: R_AVR_13_PCREL ...
Emmanuel Bourien schreef: Hello, I get and install the last version of WinAVR (April 08 -GCC 4.3.0). I get this relocation truncated to fit: R_AVR_13_PCREL error during the link operation. I'm working with AVR Studio 4.12 I've read i should add -lm to the linker command to avoid this...but no success :( So i need your help to avoid this problem! Excuse my english ;) thanks for your help. Best regards emmanuel Your are almost there You need to add -lm at the end of the linker step. See http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_libm HTH, Wouter ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] A Question Of Optmization
David Brown wrote: In fact, the compiler will *always* do *exactly* what your program code asks ... Although the general thrust of your argument is correct, this statement may not be true, depending on how the reader interprets what your program code asks. The language definition requires the compiler to produce code which *has the same final effect* as what you have written, but in the interests of optimization, it is permitted to deviate from doing each and every thing you have asked it to do. It is thinking that the compiler must do exactly what you have asked that leads people to omit the volatile keyword in the first place. The volatile keyword tells the compiler that things happen to or are caused by a variable that would otherwise be unknown to the compiler when it translates a unit of code. This is an indication that the compiler cannot evaluate the final effect of access to that variable during the translation. Therefore, it translates each access exactly as it is written. In fact, then, you can only be sure that the compiler will *always* do *exactly* what your program code asks if your variables are volatile. You are right that fiddling with optimization flags is not required to have the same effect and is not the way to fix the problem. I think the important thing here is to read the manual for your compiler as this won't be specified by the language standard. Graham. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] [AVR gcc link error] relocation truncated to fit: R_AVR_13_PCREL ...[resolved]
That's it! My error was that I added -lm to the linker options but not at the end! So that's okay now Thanks a lot Wouter. Wouter van Gulik a écrit : Emmanuel Bourien schreef: Hello, I get and install the last version of WinAVR (April 08 -GCC 4.3.0). I get this relocation truncated to fit: R_AVR_13_PCREL error during the link operation. I'm working with AVR Studio 4.12 I've read i should add -lm to the linker command to avoid this...but no success :( So i need your help to avoid this problem! Excuse my english ;) thanks for your help. Best regards emmanuel Your are almost there You need to add -lm at the end of the linker step. See http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_libm HTH, Wouter -- Emmanuel Bourien Imartec 52 Rue Diamant - Porte 5 40600 Biscarrosse FRANCE Tel/Fax: +33 (0)5-58-82-07-65 visit our new web site: www.imartec.com ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Patch Fix PR35013, PR27192
Andy H schreef: RFC A problem has come up trying to fix function pointer arthmetic bugs. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35013 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27192 I created patch to solve this, but Anatoly has found a problem. Without patch we had func returning word address and (func + 2) returning byte address. This occurred because AVR backend did not recognise (func+2) as program memory and did not use linker directive gs(func+2). With patch we get func and func+2 both returning word address. Which solved the bugs reported. Now if such a word pointer undergoes further arithmetic in c, then it will, of course, be adjusting it by words. The problem that Anatoly discovered is that optimization can break this. His example involved volatile pointers but it will happen on more realistic cases. For example if we create pointers to Foo, Foo+2, Foo+4, optimization will try and use one pointer to create values of other pointers. So we will get word address of Foo offset by words - or word address of Foo offset by bytes! This just depends if the offset calculation is done in gcc or the linker. Ag! Just for my understanding. The programpointer calculation is thus translated to datapointer calculation? There probably is no way of telling GCC we are dealing with different pointer types here? Since GCC can not handle different memory types at all. To fix is not simple. The following are ideas only - please add some more 1) One way to to get linker to perform maths on gs() using word offsets. gs(foo+2) would be word address of foo+ 2 words. Then it would not matter if gcc or linker performed maths. I do not know if this is possible or what problems this might create. 2) We could avoid using gs() and get function address as byte address + byte offset. This would require extra run-time code for function pointer calls (to divide by two). It is useful in that same pointers could be used to read bytes from program memory. 3) Give up and dont permit any arithmetic. (Perhaps error or warning would still be needed) 4) Like (1) but use new directive gsw() to permit this method? 5) Like (2) but use attribute to permit this method? 6) Get gcc to recognize constant pointer maths and exclude it from linker gs() 7) Get gcc to recognize constant pointer maths and pass to linker as gs(Foo) + n instead of gs(Foo+n) - if this is possible. Please add to discussion. So they main point is to keep the knowledge that the add is in words not bytes. Right? Is it not possible to do all programspace addition on byte level, until the linker? Which converts them to words? e.g. foo+2 becomes foo+linker_know_this_is_2_words. Wouter ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] Default location for .indent.pro in WinAVR?
One option is to set the environment variable INDENT_PROFILE to the location of one's default .indent.pro for GNU Indent, but I'd like to know where the program searches by default? It doesn't seem to be: C:\Documents and Settings\dkelly -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Patch Fix PR35013, PR27192
The solution is to have linker and gcc do the same maths. Or gcc only do the maths. So we do not mix. Then it will be predictable. But this also depends if we can manage ok with just words OR just bytes - as may be avaialble as a solution. Andy -Original Message- From: Wouter van Gulik [EMAIL PROTECTED] To: Andy H [EMAIL PROTECTED] Cc: AVR-GCC avr-gcc-list@nongnu.org Sent: Wed, 16 Apr 2008 10:52 am Subject: Re: [avr-gcc-list] Re: Patch Fix PR35013, PR27192 Andy H schreef: RFC A problem has come up trying to fix function pointer arthmetic bugs. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35013 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27192 I created patch to solve this, but Anatoly has found a problem. Without patch we had func returning word address and (func + 2) returning byte address. This occurred because AVR backend did not recognise (func+2) as program memory and did not use linker directive gs(func+2). With patch we get func and func+2 both returning word address. Which solved the bugs reported. Now if such a word pointer undergoes further arithmetic in c, then it will, of course, be adjusting it by words. The problem that Anatoly discovered is that optimization can break this. His example involved volatile pointers but it will happen on more realistic cases. For example if we create pointers to Foo, Foo+2, Foo+4, optimization will try and use one pointer to create values of other pointers. So we will get word address of Foo offset by words - or word address of Foo offset by bytes! This just depends if the offset calculation is done in gcc or the linker. Ag! Just for my understanding. The programpointer calculation is thus translated to datapointer calculation? There probably is no way of telling GCC we are dealing with different pointer types here? Since GCC can not handle different memory types at all. To fix is not simple. The following are ideas only - please add some more 1) One way to to get linker to perform maths on gs() using word offsets. gs(foo+2) would be word address of foo+ 2 words. Then it would not matter if gcc or linker performed maths. I do not know if this is possible or what problems this might create. 2) We could avoid using gs() and get function address as byte address + byte offset. This would require extra run-time code for function pointer calls (to divide by two). It is useful in that same pointers could be used to read bytes from program memory. 3) Give up and dont permit any arithmetic. (Perhaps error or warning would still be needed) 4) Like (1) but use new directive gsw() to permit this method? 5) Like (2) but use attribute to permit this method? 6) Get gcc to recognize constant pointer maths and exclude it from linker gs() 7) Get gcc to recognize constant pointer maths and pass to linker as gs(Foo) + n instead of gs(Foo+n) - if this is possible. Please add to discussion. So they main point is to keep the knowledge that the add is in words not bytes. Right? Is it not possible to do all programspace addition on byte level, until the linker? Which converts them to words? e.g. foo+2 becomes foo+linker_know_this_is_2_words. Wouter ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] A Question Of Optmization
Graham Davies wrote: David Brown wrote: In fact, the compiler will *always* do *exactly* what your program code asks ... Although the general thrust of your argument is correct, this statement may not be true, depending on how the reader interprets what your program code asks. The language definition requires the compiler to produce code which *has the same final effect* as what you have written, but in the interests of optimization, it is permitted to deviate from doing each and every thing you have asked it to do. It is thinking that the compiler must do exactly what you have asked that leads people to omit the volatile keyword in the first place. That's really what I meant - as far as it is possible to observe your system, the code generated by the compiler does exactly what your program asks. But I think you've explained it better than I did - my wording was open to misinterpretation. The volatile keyword tells the compiler that things happen to or are caused by a variable that would otherwise be unknown to the compiler when it translates a unit of code. This is an indication that the compiler cannot evaluate the final effect of access to that variable during the translation. Therefore, it translates each access exactly as it is written. In fact, then, you can only be sure that the compiler will *always* do *exactly* what your program code asks if your variables are volatile. My point was that the compiler is actually doing exactly what you ask it even if it optimises out code or data. Using volatile does not change whether the compiler generates code that does exactly what your program asks for (since the compiler will always generate such code) - rather, it changes the meaning of your source code. You get different generated code because you asked for different code, not because you asked the compiler to view it differently or optimise differently. As I said above, I'm not sure I was very clear in my post - your explanation here should help others. You are right that fiddling with optimization flags is not required to have the same effect and is not the way to fix the problem. I think the important thing here is to read the manual for your compiler as this won't be specified by the language standard. Absolutely - you can't know your compiler and target too well in embedded programming. Someone pointed out to me that this sort of discussion is somewhat off-topic for this mailing list. I hope it is helpful to some people, however - newcomers to avr-gcc often have trouble with things like volatile, because avr-gcc has much more advanced optimisations than most other avr compilers. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: Patch Fix PR35013, PR27192
On Thursday 17 April 2008 00:17, Andy wrote:
Indirect calls - ie simple function pointers are safe!
It is only when you try and do some arithmetic with them that there is
potential problem. The only reason to use arithmetic is for ASM related
manipulations. (but very useful!)
For example , (excuse syntax mistakes)
void foo(void) {}
(void * p1) (void);
p1 = foo; //NO PROBLEM
[...]
Doubtful is avr6 case with binutils.
Look, please, the program below. It uses only simple function
pointers, no arithmetic.
Thanks,
Dmitry.
/* avr-gcc 4.4-20080404 + binutils 2.18 produce incorrect code:
the foo4() function stores 0 value to 'vp' variable.
Options: -W -Wall -Os -mmcu=atmega2560
*/
#define BIGCODE() asm volatile (.rept 3\n\tnop\n\t.endr)
void (* volatile vp) (void);
__attribute__((noinline)) void foo1 (void) { BIGCODE(); vp = foo1; }
__attribute__((noinline)) void foo2 (void) { BIGCODE(); vp = foo2; }
__attribute__((noinline)) void foo3 (void) { BIGCODE(); vp = foo3; }
__attribute__((noinline)) void foo4 (void) { BIGCODE(); vp = foo4; }
int main ()
{
foo1 ();
foo2 ();
foo3 ();
foo4 ();
return 0;
}
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] RE: Patch Fix PR35013, PR27192
I think I have found a simple fix. I changed gcc so that offsets added to assembler symbols are doubled. So in c when we use foo+2 this gets send to assembler/linker as gs(foo+4). This has the effect that offsets or arithmetic are consistently in words - on a word pointer. (which makes more sense) Now it does not matter if optimisation creates p=foo+2 OR p=foo, p=p+2 as the result will be the same. I attach test program I used to check several variant and it worked. Apart from normal warning messages about linker stubs. There also lst and lss files you can look at what gets send to assembler and code produced. I've attached patch - but have not checked for elegance! See if this breaks! Andy 1.file bug27192.c 2__SREG__ = 0x3f 3__SP_H__ = 0x3e 4__SP_L__ = 0x3d 5__tmp_reg__ = 0 6__zero_reg__ = 1 7.global __do_copy_data 8.global __do_clear_bss 16.Ltext0: 17.global putchar_exit_c 19putchar_exit_c: 20.LFB3: 21.LM1: 22.LVL0: 23/* prologue: function */ 24/* frame size = 0 */ 25.LM2: 26 82BF out 82-0x20,r24 27.LM3: 28 0002 80E0 ldi r24,lo8(0) 29 0004 90E0 ldi r25,hi8(0) 30.LVL1: 31/* epilogue start */ 32 0006 0895 ret 33.LFE3: 35.section.init8,ax,@progbits 36.global init_exit_c 38init_exit_c: 39.LFB4: 40.LSM0: 41/* prologue: naked */ 42/* frame size = 0 */ 43.LSM1: 44 80E0 ldi r24,lo8(gs(putchar_exit_c)) 45 0002 90E0 ldi r25,hi8(gs(putchar_exit_c)) 46 0004 9093 sts (file_exit_c+8)+1,r25 47 0008 8093 sts file_exit_c+8,r24 48.LSM2: 49 000c 1092 sts (file_exit_c+10)+1,__zero_reg__ 50 0010 1092 sts file_exit_c+10,__zero_reg__ 51.LSM3: 52 0014 82E0 ldi r24,lo8(2) 53 0016 8093 sts file_exit_c+3,r24 54.LSM4: 55 001a 1092 sts (file_exit_c+12)+1,__zero_reg__ 56 001e 1092 sts file_exit_c+12,__zero_reg__ 57.LSM5: 58 0022 80E0 ldi r24,lo8(file_exit_c) 59 0024 90E0 ldi r25,hi8(file_exit_c) 60 0026 9093 sts (__iob+2)+1,r25 61 002a 8093 sts __iob+2,r24 62 002e 9093 sts (__iob+4)+1,r25 63 0032 8093 sts __iob+4,r24 64/* epilogue start */ 65.LSM6: 66.LFE4: 68.text 69.global exit 71exit: 72.LFB5: 73.LM4: 74.LVL2: 75/* prologue: naked */ 76/* frame size = 0 */ 77.LM5: 78 0008 8FBD out 79-0x20,r24 79/* epilogue start */ 80.LM6: 81.LFE5: 83.global abort 85abort: 86.LFB6: 87.LM7: 88/* prologue: naked */ 89/* frame size = 0 */ 90.LM8: 91 000a 81E0 ldi r24,lo8(1) 92 000c 89BD out 73-0x20,r24 93/* epilogue start */ 94.LM9: 95.LFE6: 97.global bar 99bar: 100.LFB7: 101.LM10: 102/* prologue: function */ 103/* frame size = 0 */ 104.LM11: 105/* #APP */ 106 ; 62 bug27192.c 1 107 000e nop 108 ; 0 2 109.LM12: 110 ; 63 bug27192.c 1 111 0010 nop 112 ; 0 2 113.LM13: 114 ; 64 bug27192.c 1 115 0012 nop 116 ; 0 2 117.LM14: 118 ; 65 bug27192.c 1 119 0014 nop 120 ; 0 2 121.LM15: 122 ; 66 bug27192.c 1 123 0016 nop 124 ; 0 2 125/* epilogue start */ 126.LM16: 127/* #NOAPP */ 128 0018 0895 ret 129.LFE7: 131.global init 133init: 134.LFB8: 135.LM17: 136/* prologue: function */ 137
Re: [avr-gcc-list] RE: Patch Fix PR35013, PR27192
On the face of it this sounds like a good idea, and is simple -- enough so that even I understand what you are trying to do and I don't know the internals of GCC. This may be a dumb question... Is this going to have any impact on PROGMEM variables, or any other calculations done with pointers to constant data stored in flash? -dave Andy H wrote: I think I have found a simple fix. I changed gcc so that offsets added to assembler symbols are doubled. So in c when we use foo+2 this gets send to assembler/linker as gs(foo+4). This has the effect that offsets or arithmetic are consistently in words - on a word pointer. (which makes more sense) Now it does not matter if optimisation creates p=foo+2 OR p=foo, p=p+2 as the result will be the same. I attach test program I used to check several variant and it worked. Apart from normal warning messages about linker stubs. There also lst and lss files you can look at what gets send to assembler and code produced. I've attached patch - but have not checked for elegance! See if this breaks! Andy 1.file bug27192.c 2__SREG__ = 0x3f 3__SP_H__ = 0x3e 4__SP_L__ = 0x3d 5__tmp_reg__ = 0 6__zero_reg__ = 1 7.global __do_copy_data 8.global __do_clear_bss 16.Ltext0: 17.global putchar_exit_c 19putchar_exit_c: 20.LFB3: 21.LM1: 22.LVL0: 23/* prologue: function */ 24/* frame size = 0 */ 25.LM2: 26 82BF out 82-0x20,r24 27.LM3: 28 0002 80E0 ldi r24,lo8(0) 29 0004 90E0 ldi r25,hi8(0) 30.LVL1: 31/* epilogue start */ 32 0006 0895 ret 33.LFE3: 35.section.init8,ax,@progbits 36.global init_exit_c 38init_exit_c: 39.LFB4: 40.LSM0: 41/* prologue: naked */ 42/* frame size = 0 */ 43.LSM1: 44 80E0 ldi r24,lo8(gs(putchar_exit_c)) 45 0002 90E0 ldi r25,hi8(gs(putchar_exit_c)) 46 0004 9093 sts (file_exit_c+8)+1,r25 47 0008 8093 sts file_exit_c+8,r24 48.LSM2: 49 000c 1092 sts (file_exit_c+10)+1,__zero_reg__ 50 0010 1092 sts file_exit_c+10,__zero_reg__ 51.LSM3: 52 0014 82E0 ldi r24,lo8(2) 53 0016 8093 sts file_exit_c+3,r24 54.LSM4: 55 001a 1092 sts (file_exit_c+12)+1,__zero_reg__ 56 001e 1092 sts file_exit_c+12,__zero_reg__ 57.LSM5: 58 0022 80E0 ldi r24,lo8(file_exit_c) 59 0024 90E0 ldi r25,hi8(file_exit_c) 60 0026 9093 sts (__iob+2)+1,r25 61 002a 8093 sts __iob+2,r24 62 002e 9093 sts (__iob+4)+1,r25 63 0032 8093 sts __iob+4,r24 64/* epilogue start */ 65.LSM6: 66.LFE4: 68.text 69.global exit 71exit: 72.LFB5: 73.LM4: 74.LVL2: 75/* prologue: naked */ 76/* frame size = 0 */ 77.LM5: 78 0008 8FBD out 79-0x20,r24 79/* epilogue start */ 80.LM6: 81.LFE5: 83.global abort 85abort: 86.LFB6: 87.LM7: 88/* prologue: naked */ 89/* frame size = 0 */ 90.LM8: 91 000a 81E0 ldi r24,lo8(1) 92 000c 89BD out 73-0x20,r24 93/* epilogue start */ 94.LM9: 95.LFE6: 97.global bar 99bar: 100.LFB7: 101.LM10: 102/* prologue: function */ 103/* frame size = 0 */ 104.LM11: 105/* #APP */ 106 ; 62 bug27192.c 1 107 000e nop 108 ; 0 2 109.LM12: 110 ; 63 bug27192.c 1 111 0010 nop 112 ; 0 2 113.LM13: 114 ; 64 bug27192.c 1 115 0012 nop 116 ; 0 2 117.LM14: 118 ; 65 bug27192.c 1 119 0014 nop 120 ; 0 2 121.LM15:
