Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

2011-10-14 Thread Georg-Johann Lay
Boyapati, Anitha schrieb: I am completely in line with Eric: Your debugger will have to get smarter and not the compiler get dumb again. Johann As it was put, it is more of a performance question than about the correctness of it. I am not sure what exactly the issue is, but you are

Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

2011-10-13 Thread Boyapati, Anitha
making it optional using a switch like 'mrcall'. Thoughts? Anitha === From: Anatoly Sokolov Subject:Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3 Date: Sun, 20 Aug 2006 14:29:46 +0400 Hello. Attached

Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

2011-10-13 Thread Boyapati, Anitha
=atmel@nongnu.org] On Behalf Of Boyapati, Anitha Sent: Thursday, October 13, 2011 1:18 PM To: AVR-GCC-list@nongnu.org Subject: Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3 Hi All, I have couple of comments on this patch, which I think are important discussing with the avr-gcc community

Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

2011-10-13 Thread Weddington, Eric
] RTL prologue/epilogue ver.3 Comment -2: I think this patch severely affects the step in/step out feature of debugger like AVR Studio (here after referred to as AS). AS depends on 'rcall'/'ret' instruction sequences to recognize a function call and step into. If a matching 'ret

Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

2011-10-13 Thread Georg-Johann Lay
Boyapati, Anitha schrieb: Hi All, I have couple of comments on this patch, which I think are important discussing with the avr-gcc community. Comment - 1: Has any one verified prologue for functions using global variables? I think this patch generates incorrect prologue for such

Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

2011-10-13 Thread Weddington, Eric
: Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3 I think this patch severely affects the step in/step out feature of debugger like AVR Studio (here after referred to as AS). AS depends on 'rcall'/'ret' instruction sequences to recognize a function call and step into. If a matching 'ret

Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

2011-10-13 Thread Georg-Johann Lay
Weddington, Eric schrieb: Subject: Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3 I think this patch severely affects the step in/step out feature of debugger like AVR Studio (here after referred to as AS). AS depends on 'rcall'/'ret' instruction sequences to recognize a function

Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

2011-10-13 Thread Weddington, Eric
-Original Message- From: Georg-Johann Lay [mailto:a...@gjlay.de] Sent: Thursday, October 13, 2011 12:10 PM To: Weddington, Eric Cc: Boyapati, Anitha; AVR-GCC-list@nongnu.org Subject: Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3 For the compiler, assume: void

Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

2011-10-13 Thread Georg-Johann Lay
Weddington, Eric a écrit: There will probably have to be some info in the DWARF debug info for the debugger to track... The information is all there, it just has to be used. But maybe the real problem is located in ./gcc/config/avr/elf.h: #undef PREFERRED_DEBUGGING_TYPE #define

Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

2011-10-13 Thread Weddington, Eric
-Original Message- From: Georg-Johann Lay Sent: Thursday, October 13, 2011 3:31 PM To: AVR-GCC-list@nongnu.org Cc: Weddington, Eric; Boyapati, Anitha Subject: Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3 Weddington, Eric a écrit: There will probably have to be some

Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

2011-10-13 Thread Boyapati, Anitha
-Original Message- From: Georg-Johann Lay [mailto:a...@gjlay.de] Sent: Thursday, October 13, 2011 10:14 PM To: Boyapati, Anitha Cc: AVR-GCC-list@nongnu.org Subject: Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3 Boyapati, Anitha schrieb: Hi All, I have couple of comments

Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

2011-10-13 Thread Boyapati, Anitha
I am completely in line with Eric: Your debugger will have to get smarter and not the compiler get dumb again. Johann As it was put, it is more of a performance question than about the correctness of it. I am not sure what exactly the issue is, but you are right that one cannot rely on