Hi,
I saw the update, thanks.
I have a very complex case with many case of setjmp and longjmp, and
it still fails.. same code works recompiled to run on linux.. but the
problem may be something else that only occurs on the avr, I can't
blame it on setjmp/longjmp yet. I will investigate it if I
> > I shall fix this bug (mismatch of longjmp() to Avr-gcc's API)
> > at the nearest week-end.
Done, without any optimization.
Dmitry.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
On 5/13/09, Dmitry K. wrote:
> On Thursday 14 May 2009 14:03, Dmitry K. wrote:
>> And some optimization is needed to exclude pop/push sequences.
>
> I shall fix this bug (mismatch of longjmp() to Avr-gcc's API)
> at the nearest week-end.
>
Great. Sorry for all my confusion/
Sean
_
On Thursday 14 May 2009 14:03, Dmitry K. wrote:
> And some optimization is needed to exclude pop/push sequences.
I shall fix this bug (mismatch of longjmp() to Avr-gcc's API)
at the nearest week-end.
Dmitry.
___
AVR-GCC-list mailing list
AVR-GCC-list
On Thursday 14 May 2009 09:31, you wrote:
[...]
> I like that solution. Is this correct?
>
> Index: setjmp.S
> ===
> RCS file: /sources/avr-libc/avr-libc/libc/stdlib/setjmp.S,v
> retrieving revision 1.7
> diff -u -r1.7 setjmp.S
> ---
On Thursday 14 May 2009 09:23, Anatoly Sokolov wrote:
Thanks!
What about to copy yours mail into Avr-libc doc?
[...]
> Calling the bootloader code from application code and
> calling application from bootloader is PROHIBITED, allowed only jump from
> application code to reset vector of bootload
In any case, the rules of EIND usage must be documented.
The avr-gcc/avr-ld internally use the EIND for indirect function call, case
statement optimization (tablejump) and -mcall-prologues optimization. The
EIND always should contain "hh8(pm(start of .trampolines section))" value,
i.e. 0 when a
On Thursday 14 May 2009 07:42, Sean D'Epagnier wrote:
[...]
> Also, there is the issue of longjmp setting EIND and not restoring it.
> It gets a little tricky with interrupts that can potentially set EIND
> as well.
Yes, the longjmp() sets EIND. It is impossible to restore EIND,
as the EIJMP is
Hi
On 5/13/09, Anatoly Sokolov wrote:
>
>
> avr-libc/crt1/gcrt1.S :
>
> .section .init0,"ax",@progbits
> .weak __init
> ; .func __init
> __init:
> ...
> #ifdef __AVR_3_BYTE_PC__
> ldi r16, hh8(pm(__vectors))
> out _SFR_IO_ADDR(EIND), r16
> #endif/* _
- Original Message -
From: "Sean D'Epagnier"
To: "Anatoly Sokolov"
Cc: "Weddington, Eric" ;
Sent: Wednesday, May 13, 2009 6:35 PM
Subject: Re: [avr-gcc-list] mcall-prologues completely broken for >128k
On 5/13/09, Anatoly Sokolov wrote
On 5/13/09, Anatoly Sokolov wrote:
> Hi.
>
>
>> On 5/12/09, Weddington, Eric wrote:
>>> I don't understand what you're doing here.
>>>
>>> You've completely removed EIJMP from gcc.
>>>
>>
>> That is correct. It is better for gcc not to use this instruction.
>>
>
> This prevent using indirect fun
Hi.
On 5/12/09, Weddington, Eric wrote:
I don't understand what you're doing here.
You've completely removed EIJMP from gcc.
That is correct. It is better for gcc not to use this instruction.
This prevent using indirect function call in bootloader code for >128KB
FLASH devices.
Ana
Sunday, May 10, 2009 12:26 AM
>> To: Weddington, Eric
>> Cc: avr-gcc-list@nongnu.org; Anatoly Sokolov
>> Subject: Re: [avr-gcc-list] mcall-prologues completely broken
>> for >128k
>>
>> Hi,
>>
>> Here are some patches. Please take a look and tell me
dington, Eric
> Cc: avr-gcc-list@nongnu.org; Anatoly Sokolov
> Subject: Re: [avr-gcc-list] mcall-prologues completely broken
> for >128k
>
> Hi,
>
> Here are some patches. Please take a look and tell me if what I did
> with setjmp makes any sense. I don't really use lon
Hi,
Here are some patches. Please take a look and tell me if what I did
with setjmp makes any sense. I don't really use longjmp so it's not
fully tested, and it is only to handle a case which is very difficult
to create.
I have tested the gcc patch and my program is working very well now.
The
eddington=atmel@nongnu.org
>> [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.
>> org] On Behalf Of Sean D'Epagnier
>> Sent: Saturday, May 09, 2009 1:36 PM
>> To: avr-gcc-list@nongnu.org
>> Subject: [avr-gcc-list] mcall-prologues completely broken fo
g
> Subject: [avr-gcc-list] mcall-prologues completely broken for >128k
>
> Hi, I originally thought my extensive used of the gcc extension
> "Address labels" was the cause of my problems. After inspection of
> the assembly I realized that they worked perfectly via
Hi, I originally thought my extensive used of the gcc extension
"Address labels" was the cause of my problems. After inspection of
the assembly I realized that they worked perfectly via the trampoline
mechanism.. so what was the problem?
I found that prologue_saves calls eijmp at the end, which
18 matches
Mail list logo
