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 call and >>> step into. If a matching 'ret' is not found, the debugger gets >>> confused. >>> Currently, the problem is worked around but has much lower >>> performance. >> The debugger has to cope with that. There are two ways of doing that: >> >> 1) Analysing the prologue and knowing what sequences the compiler >> might generate. >> > > On further thought about that, it's actually pretty simple to determine > when an rcall is used in the context of a function prologue; It shows up > as "rcall 0", which is extremely unlikely that that form will ever be > used for a real subroutine call. (In fact, I can't think of any > situation where "rcall 0" could be used as a real subroutine call, but > maybe somebody has a real counter-example that could be generated by the > compiler.)
In lingcc.S there is DEFUN __umulhisi3 mul A0, B0 movw C0, r0 mul A1, B1 movw C2, r0 mul A0, B1 rcall 1f mul A1, B0 1: add C1, r0 adc C2, r1 clr __zero_reg__ adc C3, __zero_reg__ ret ENDF __umulhisi3 This self-call is not a rcall .+0 but close to it because there is just a MUL in between. But that's assembler ... For the compiler, assume: void __attribute__((noreturn,noinline)) b (void); void a (void) { b(); } void b (void) { while (1); } avr-gcc ab.c -S -Os -fno-toplevel-reorder a: rcall b b: .L3: rjmp .L3 But there is symbol information for b despite rcall .+0 BTW: I am just working on a patchlet to print {R|[E]I}JMP for noreturn functions. Johann _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list