Minor fixes

Fixes #12

Ugfx yield

add #define CONFIG_ESP32_WIFI_RX_BUFFER_NUM 25 刣

Fixes the execution of py files with globals vars

Update from adafruit/main

Add LCD Module

If two tasks try to start sleeping at the same time,
the SingletonGenerator will be in use, thus we need
to allocate a new temporary handler on the heap.

As the singleton isn't that single any more, it gets renamed.

Found by taskgroup test micropython#12.

If two tasks try to start sleeping at the same time,
the SingletonGenerator will be in use, thus we need
to allocate a new temporary handler on the heap.

As the singleton isn't that single any more, it gets renamed.

Found by taskgroup test micropython#12.

If two tasks try to start sleeping at the same time,
the SingletonGenerator will be in use, thus we need
to allocate a new temporary handler on the heap.

As the singleton isn't that single any more, it gets renamed.

Found by taskgroup test micropython#12.

Although the original motivation given for the workaround[1] is correct, nlr.o
and nlrthumb.o are linked with a small enough distance that the problem does
not occur, and the workaround isn't necessary. The distance between the b
instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the
±2046 byte range addressable by an unconditional branch instruction in Thumb mode.

The workaround induces a relocation in the text section (textrel), which
isn't supported everywhere, notably not on musl-libc, where it causes a
crash on start-up. With the workaround removed, micropython works on an ARMv5T
Linux built with musl-libc.


[1]: commit dd376a2

Author: Damien George <damien.p.george@gmail.com>
Date:   Fri Sep 1 15:25:29 2017 +1000

    py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2).

    "b" on Thumb might not be long enough for the jump to nlr_push_tail so it
    must be done indirectly.

[2]: Excerpt from objdump -d micropython:

000095c4 <nlr_push_tail>:
    95c4:       b510            push    {r4, lr}
    95c6:       0004            movs    r4, r0
    95c8:       f02d fd42       bl      37050 <mp_thread_get_state>
    95cc:       6943            ldr     r3, [r0, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#20]
    95d2:       2000            movs    r0, #0
    95d4:       bd10            pop     {r4, pc}

000095d6 <nlr_pop>:
    95d6:       b510            push    {r4, lr}
    95d8:       f02d fd3a       bl      37050 <mp_thread_get_state>
    95dc:       6943            ldr     r3, [r0, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#8]
    9604:       e7de            b.n     95c4 <nlr_push_tail>

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct, nlr.o
and nlrthumb.o are linked with a small enough distance that the problem does
not occur, and the workaround isn't necessary. The distance between the b
instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the
±2046 byte range addressable by an unconditional branch instruction in Thumb mode.

The workaround induces a relocation in the text section (textrel), which
isn't supported everywhere, notably not on musl-libc, where it causes a
crash on start-up. With the workaround removed, micropython works on an ARMv5T
Linux system built with musl-libc.


[1]: commit dd376a2

Author: Damien George <damien.p.george@gmail.com>
Date:   Fri Sep 1 15:25:29 2017 +1000

    py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2).

    "b" on Thumb might not be long enough for the jump to nlr_push_tail so it
    must be done indirectly.

[2]: Excerpt from objdump -d micropython:

000095c4 <nlr_push_tail>:
    95c4:       b510            push    {r4, lr}
    95c6:       0004            movs    r4, r0
    95c8:       f02d fd42       bl      37050 <mp_thread_get_state>
    95cc:       6943            ldr     r3, [r0, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#20]
    95d2:       2000            movs    r0, #0
    95d4:       bd10            pop     {r4, pc}

000095d6 <nlr_pop>:
    95d6:       b510            push    {r4, lr}
    95d8:       f02d fd3a       bl      37050 <mp_thread_get_state>
    95dc:       6943            ldr     r3, [r0, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#8]
    9604:       e7de            b.n     95c4 <nlr_push_tail>

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct,
nlr.o and nlrthumb.o are linked with a small enough distance that the
problem does not occur, and the workaround isn't necessary. The distance
between the b instruction and its target (nlr_push_tail) is just 64
bytes[2], well within the ±2046 byte range addressable by an
unconditional branch instruction in Thumb mode.

The workaround induces a relocation in the text section (textrel), which
isn't supported everywhere, notably not on musl-libc, where it causes a
crash on start-up. With the workaround removed, micropython works on an
ARMv5T Linux system built with musl-libc.


[1]: commit dd376a2

Author: Damien George <damien.p.george@gmail.com>
Date:   Fri Sep 1 15:25:29 2017 +1000

    py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2).

    "b" on Thumb might not be long enough for the jump to nlr_push_tail so
    it must be done indirectly.

[2]: Excerpt from objdump -d micropython:

000095c4 <nlr_push_tail>:
    95c4:       b510            push    {r4, lr}
    95c6:       0004            movs    r4, r0
    95c8:       f02d fd42       bl      37050 <mp_thread_get_state>
    95cc:       6943            ldr     r3, [r0, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#20]
    95d2:       2000            movs    r0, #0
    95d4:       bd10            pop     {r4, pc}

000095d6 <nlr_pop>:
    95d6:       b510            push    {r4, lr}
    95d8:       f02d fd3a       bl      37050 <mp_thread_get_state>
    95dc:       6943            ldr     r3, [r0, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#8]
    9604:       e7de            b.n     95c4 <nlr_push_tail>

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct,
nlr.o and nlrthumb.o are linked with a small enough distance that the
problem does not occur, and the workaround isn't necessary. The distance
between the b instruction and its target (nlr_push_tail) is just 64
bytes[2], well within the ±2046 byte range addressable by an
unconditional branch instruction in Thumb mode.

The workaround induces a relocation in the text section (textrel), which
isn't supported everywhere, notably not on musl-libc[3], where it causes
a crash on start-up. With the workaround removed, micropython works on an
ARMv5T Linux system built with musl-libc.


[1]: commit dd376a2

Author: Damien George <damien.p.george@gmail.com>
Date:   Fri Sep 1 15:25:29 2017 +1000

    py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2).

    "b" on Thumb might not be long enough for the jump to nlr_push_tail so
    it must be done indirectly.

[2]: Excerpt from objdump -d micropython:

000095c4 <nlr_push_tail>:
    95c4:       b510            push    {r4, lr}
    95c6:       0004            movs    r4, r0
    95c8:       f02d fd42       bl      37050 <mp_thread_get_state>
    95cc:       6943            ldr     r3, [r0, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#20]
    95d2:       2000            movs    r0, #0
    95d4:       bd10            pop     {r4, pc}

000095d6 <nlr_pop>:
    95d6:       b510            push    {r4, lr}
    95d8:       f02d fd3a       bl      37050 <mp_thread_get_state>
    95dc:       6943            ldr     r3, [r0, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#8]
    9604:       e7de            b.n     95c4 <nlr_push_tail>

[3]: https://www.openwall.com/lists/musl/2020/09/25/4

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct,
nlr.o and nlrthumb.o are linked with a small enough distance that the
problem does not occur, and the workaround isn't necessary. The distance
between the b instruction and its target (nlr_push_tail) is just 64
bytes[2], well within the ±2046 byte range addressable by an
unconditional branch instruction in Thumb mode.

The workaround induces a relocation in the text section (textrel), which
isn't supported everywhere, notably not on musl-libc[3], where it causes
a crash on start-up. With the workaround removed, micropython works on an
ARMv5T Linux system built with musl-libc.

This commit changes nlrthumb.c to use a direct jump by default, but
leaves the long jump workaround as an option for those cases where it's
actually needed.


[1]: commit dd376a2

Author: Damien George <damien.p.george@gmail.com>
Date:   Fri Sep 1 15:25:29 2017 +1000

    py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2).

    "b" on Thumb might not be long enough for the jump to nlr_push_tail so
    it must be done indirectly.

[2]: Excerpt from objdump -d micropython:

000095c4 <nlr_push_tail>:
    95c4:       b510            push    {r4, lr}
    95c6:       0004            movs    r4, r0
    95c8:       f02d fd42       bl      37050 <mp_thread_get_state>
    95cc:       6943            ldr     r3, [r0, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#20]
    95d2:       2000            movs    r0, #0
    95d4:       bd10            pop     {r4, pc}

000095d6 <nlr_pop>:
    95d6:       b510            push    {r4, lr}
    95d8:       f02d fd3a       bl      37050 <mp_thread_get_state>
    95dc:       6943            ldr     r3, [r0, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#8]
    9604:       e7de            b.n     95c4 <nlr_push_tail>

[3]: https://www.openwall.com/lists/musl/2020/09/25/4

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct,
nlr.o and nlrthumb.o are linked with a small enough distance that the
problem does not occur, and the workaround isn't necessary. The distance
between the b instruction and its target (nlr_push_tail) is just 64
bytes[2], well within the ±2046 byte range addressable by an
unconditional branch instruction in Thumb mode.

The workaround induces a relocation in the text section (textrel), which
isn't supported everywhere, notably not on musl-libc[3], where it causes
a crash on start-up. With the workaround removed, micropython works on an
ARMv5T Linux system built with musl-libc.

This commit changes nlrthumb.c to use a direct jump by default, but
leaves the long jump workaround as an option for those cases where it's
actually needed.


[1]: commit dd376a2

Author: Damien George <damien.p.george@gmail.com>
Date:   Fri Sep 1 15:25:29 2017 +1000

    py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2).

    "b" on Thumb might not be long enough for the jump to nlr_push_tail so
    it must be done indirectly.

[2]: Excerpt from objdump -d micropython:

000095c4 <nlr_push_tail>:
    95c4:       b510            push    {r4, lr}
    95c6:       0004            movs    r4, r0
    95c8:       f02d fd42       bl      37050 <mp_thread_get_state>
    95cc:       6943            ldr     r3, [r0, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#20]
    95d2:       2000            movs    r0, #0
    95d4:       bd10            pop     {r4, pc}

000095d6 <nlr_pop>:
    95d6:       b510            push    {r4, lr}
    95d8:       f02d fd3a       bl      37050 <mp_thread_get_state>
    95dc:       6943            ldr     r3, [r0, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#8]
    9604:       e7de            b.n     95c4 <nlr_push_tail>

[3]: https://www.openwall.com/lists/musl/2020/09/25/4

Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

If two tasks try to start sleeping at the same time,
the SingletonGenerator will be in use, thus we need
to allocate a new temporary handler on the heap.

As the singleton isn't that single any more, it gets renamed.

Found by taskgroup test micropython#12.

Signed-off-by: Matthias Urlichs <matthias@urlichs.de>

Although the original motivation given for the workaround[1] is correct,
nlr.o and nlrthumb.o are linked with a small enough distance that the
problem does not occur, and the workaround isn't necessary. The distance
between the b instruction and its target (nlr_push_tail) is just 64
bytes[2], well within the ±2046 byte range addressable by an
unconditional branch instruction in Thumb mode.

The workaround induces a relocation in the text section (textrel), which
isn't supported everywhere, notably not on musl-libc[3], where it causes
a crash on start-up. With the workaround removed, micropython works on an
ARMv5T Linux system built with musl-libc.

This commit changes nlrthumb.c to use a direct jump by default, but
leaves the long jump workaround as an option for those cases where it's
actually needed.


[1]: commit dd376a2

Author: Damien George <damien.p.george@gmail.com>
Date:   Fri Sep 1 15:25:29 2017 +1000

    py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2).

    "b" on Thumb might not be long enough for the jump to nlr_push_tail so
    it must be done indirectly.

[2]: Excerpt from objdump -d micropython:

000095c4 <nlr_push_tail>:
    95c4:       b510            push    {r4, lr}
    95c6:       0004            movs    r4, r0
    95c8:       f02d fd42       bl      37050 <mp_thread_get_state>
    95cc:       6943            ldr     r3, [r0, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#20]
    95d2:       2000            movs    r0, #0
    95d4:       bd10            pop     {r4, pc}

000095d6 <nlr_pop>:
    95d6:       b510            push    {r4, lr}
    95d8:       f02d fd3a       bl      37050 <mp_thread_get_state>
    95dc:       6943            ldr     r3, [r0, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#8]
    9604:       e7de            b.n     95c4 <nlr_push_tail>

[3]: https://www.openwall.com/lists/musl/2020/09/25/4

Signed-off-by: J. Neuschäfer <j.ne@posteo.net>

Although the original motivation given for the workaround[1] is correct,
nlr.o and nlrthumb.o are linked with a small enough distance that the
problem does not occur, and the workaround isn't necessary. The distance
between the b instruction and its target (nlr_push_tail) is just 64
bytes[2], well within the ±2046 byte range addressable by an
unconditional branch instruction in Thumb mode.

The workaround induces a relocation in the text section (textrel), which
isn't supported everywhere, notably not on musl-libc[3], where it causes
a crash on start-up. With the workaround removed, micropython works on an
ARMv5T Linux system built with musl-libc.

This commit changes nlrthumb.c to use a direct jump by default, but
leaves the long jump workaround as an option for those cases where it's
actually needed.


[1]: commit dd376a2

Author: Damien George <damien.p.george@gmail.com>
Date:   Fri Sep 1 15:25:29 2017 +1000

    py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2).

    "b" on Thumb might not be long enough for the jump to nlr_push_tail so
    it must be done indirectly.

[2]: Excerpt from objdump -d micropython:

000095c4 <nlr_push_tail>:
    95c4:       b510            push    {r4, lr}
    95c6:       0004            movs    r4, r0
    95c8:       f02d fd42       bl      37050 <mp_thread_get_state>
    95cc:       6943            ldr     r3, [r0, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#20]
    95d2:       2000            movs    r0, #0
    95d4:       bd10            pop     {r4, pc}

000095d6 <nlr_pop>:
    95d6:       b510            push    {r4, lr}
    95d8:       f02d fd3a       bl      37050 <mp_thread_get_state>
    95dc:       6943            ldr     r3, [r0, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#8]
    9604:       e7de            b.n     95c4 <nlr_push_tail>

[3]: https://www.openwall.com/lists/musl/2020/09/25/4

Signed-off-by: J. Neuschäfer <j.ne@posteo.net>

Although the original motivation given for the workaround[1] is correct,
nlr.o and nlrthumb.o are linked with a small enough distance that the
problem does not occur, and the workaround isn't necessary. The distance
between the b instruction and its target (nlr_push_tail) is just 64
bytes[2], well within the ±2046 byte range addressable by an
unconditional branch instruction in Thumb mode.

The workaround induces a relocation in the text section (textrel), which
isn't supported everywhere, notably not on musl-libc[3], where it causes
a crash on start-up. With the workaround removed, micropython works on an
ARMv5T Linux system built with musl-libc.

This commit changes nlrthumb.c to use a direct jump by default, but
leaves the long jump workaround as an option for those cases where it's
actually needed.

[1]: commit dd376a2

Author: Damien George <damien.p.george@gmail.com>
Date:   Fri Sep 1 15:25:29 2017 +1000

    py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2).

    "b" on Thumb might not be long enough for the jump to nlr_push_tail so
    it must be done indirectly.

[2]: Excerpt from objdump -d micropython:

000095c4 <nlr_push_tail>:
    95c4:       b510            push    {r4, lr}
    95c6:       0004            movs    r4, r0
    95c8:       f02d fd42       bl      37050 <mp_thread_get_state>
    95cc:       6943            ldr     r3, [r0, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#20]
    95d2:       2000            movs    r0, #0
    95d4:       bd10            pop     {r4, pc}

000095d6 <nlr_pop>:
    95d6:       b510            push    {r4, lr}
    95d8:       f02d fd3a       bl      37050 <mp_thread_get_state>
    95dc:       6943            ldr     r3, [r0, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#8]
    9604:       e7de            b.n     95c4 <nlr_push_tail>

[3]: https://www.openwall.com/lists/musl/2020/09/25/4

Signed-off-by: J. Neuschäfer <j.ne@posteo.net>

Although the original motivation given for the workaround[1] is correct,
nlr.o and nlrthumb.o are linked with a small enough distance that the
problem does not occur, and the workaround isn't necessary. The distance
between the b instruction and its target (nlr_push_tail) is just 64
bytes[2], well within the ±2046 byte range addressable by an
unconditional branch instruction in Thumb mode.

The workaround induces a relocation in the text section (textrel), which
isn't supported everywhere, notably not on musl-libc[3], where it causes
a crash on start-up. With the workaround removed, micropython works on an
ARMv5T Linux system built with musl-libc.

This commit changes nlrthumb.c to use a direct jump by default, but
leaves the long jump workaround as an option for those cases where it's
actually needed.

[1]: commit dd376a2

Author: Damien George <damien.p.george@gmail.com>
Date:   Fri Sep 1 15:25:29 2017 +1000

    py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2).

    "b" on Thumb might not be long enough for the jump to nlr_push_tail so
    it must be done indirectly.

[2]: Excerpt from objdump -d micropython:

000095c4 <nlr_push_tail>:
    95c4:       b510            push    {r4, lr}
    95c6:       0004            movs    r4, r0
    95c8:       f02d fd42       bl      37050 <mp_thread_get_state>
    95cc:       6943            ldr     r3, [r0, micropython#20]
    95ce:       6023            str     r3, [r4, #0]
    95d0:       6144            str     r4, [r0, micropython#20]
    95d2:       2000            movs    r0, #0
    95d4:       bd10            pop     {r4, pc}

000095d6 <nlr_pop>:
    95d6:       b510            push    {r4, lr}
    95d8:       f02d fd3a       bl      37050 <mp_thread_get_state>
    95dc:       6943            ldr     r3, [r0, micropython#20]
    95de:       681b            ldr     r3, [r3, #0]
    95e0:       6143            str     r3, [r0, micropython#20]
    95e2:       bd10            pop     {r4, pc}

000095e4 <nlr_push>:
    95e4:       60c4            str     r4, [r0, micropython#12]
    95e6:       6105            str     r5, [r0, micropython#16]
    95e8:       6146            str     r6, [r0, micropython#20]
    95ea:       6187            str     r7, [r0, micropython#24]
    95ec:       4641            mov     r1, r8
    95ee:       61c1            str     r1, [r0, micropython#28]
    95f0:       4649            mov     r1, r9
    95f2:       6201            str     r1, [r0, micropython#32]
    95f4:       4651            mov     r1, sl
    95f6:       6241            str     r1, [r0, micropython#36]   @ 0x24
    95f8:       4659            mov     r1, fp
    95fa:       6281            str     r1, [r0, micropython#40]   @ 0x28
    95fc:       4669            mov     r1, sp
    95fe:       62c1            str     r1, [r0, micropython#44]   @ 0x2c
    9600:       4671            mov     r1, lr
    9602:       6081            str     r1, [r0, micropython#8]
    9604:       e7de            b.n     95c4 <nlr_push_tail>

[3]: https://www.openwall.com/lists/musl/2020/09/25/4

Signed-off-by: J. Neuschäfer <j.ne@posteo.net>