mpy_ld.py: Unsupported relocation when using cos/sin functions

[jonnor]

Checks

• I agree to follow the MicroPython Code of Conduct to ensure a safe and respectful space for everyone.

• I've searched for existing issues matching this bug, and didn't find any.

Port, board and/or hardware

esp32/xtensawin and armv7emsp

MicroPython version

MicroPython 1.22.2 from git

Reproduction

1. Have a dynamic native module using sinf/cosf functions

Note, you have to include the object files from libm and libgcc manually in the Makefile. This means extracting the .o files from the archives, and then adding them to SRC_O make variable. See this for an example:
https://github.com/emlearn/emlearn-micropython/blob/bd85ae1fade99b34a626c9fcaae0aa4f2ec87803/src/emlfft/Makefile

ifeq ($(ARCH), xtensawin)
    LIBM_O := lib_a-sf_cos.o lib_a-sf_sin.o lib_a-ef_rem_pio2.o lib_a-kf_cos.o lib_a-kf_sin.o lib_a-sf_fabs.o lib_a-kf_rem_pio2.o lib_a-sf_scalbn.o lib_a-sf_floor.o
endif
ifeq ($(ARCH), armv7emsp)
    LIBM_O := libm_a-sf_cos.o libm_a-sf_sin.o libm_a-ef_rem_pio2.o libm_a-kf_cos.o libm_a-kf_sin.o libm_a-sf_fabs.o libm_a-kf_rem_pio2.o libm_a-sf_scalbn.o libm_a-sf_floor.o
endif

ifeq ($(ARCH), armv7emsp)
	SOFTFP_O := _arm_addsubdf3.o _arm_muldivdf3.o _arm_muldivdf3.o _arm_truncdfsf2.o
endif
ifeq ($(ARCH), xtensawin)
	SOFTFP_O := _floatsidf.o _muldf3.o _divdf3.o _truncdfsf2.o
endif

2. Try to build the module

Expected behaviour

Linking succeeds without errors, module is functional.

Alternatively: Error and/or documentation provides hints as to the possible reasons why this could happen, and ways of resolving.

Observed behaviour

Exception when linking. With ARCH=xtensawin

  File "/home/jon/projects/micropython/tools/mpy_ld.py", line 572, in do_relocation_text
    assert 0, r_info_type
AssertionError: 11

On ARCH=armv7emsp

  File "/home/jon/projects/micropython/tools/mpy_ld.py", line 572, in do_relocation_text
    assert 0, r_info_type
AssertionError: 2

Additional Information

arm-none-eabi-gcc --version
arm-none-eabi-gcc (Arch Repository) 13.2.0

xtensa-esp32-elf-gcc --version
xtensa-esp32-elf-gcc (crosstool-NG esp-2022r1) 11.2.0

Error log for xtensawin. ARM is the same, just the relocation value differs

python3 /home/jon/projects/micropython/tools/mpy_ld.py '-vvv' --arch xtensawin --qstrs build/emlfft.config.h -o build/emlfft.native.mpy _floatsidf.o _muldf3.o _divdf3.o _truncdfsf2.o lib_a-sf_cos.o lib_a-sf_sin.o lib_a-ef_rem_pio2.o lib_a-kf_cos.o lib_a-kf_sin.o lib_a-sf_fabs.o lib_a-kf_rem_pio2.o lib_a-sf_scalbn.o lib_a-sf_floor.o build/fft.o
qstr vals: __del__, emlfft, new, run
sections:
  00000004 GOT size=140
  00000090 LIT size=204
  0000015c .text size=61
  0000019c .text size=511
  0000039c .text size=531
  000005b0 .text size=164
  00000654 .text size=141
  000006e4 .text size=152
  0000077c .text size=559
  00000000 .rodata size=920
  000009ac .text size=180
  00000a60 .text size=147
  00000af4 .text size=11
  00000b00 .text size=1355
  00000398 .rodata size=56
  0000104c .text size=220
  00001128 .text size=165
  000011d0 .text size=992
  00000000 .bss size=80
  000003d0 .rodata.str1.1 size=168
  000015b0 .text.unlikely size=6
  00000478 .data.rel.ro size=40
  000004a0 .data.rel.ro.local size=24
GOT: 00000004
  00000000 mp_fun_table -> .external+00000000
  00000004 mp_native_qstr_table -> .external.qstr_table+00000000
  00000008 mp_fun_table+0x10c -> .external+00000000
  0000000c __ieee754_rem_pio2f -> .text+0000077c
  00000010 __kernel_cosf -> .text+000009ac
  00000014 __kernel_sinf -> .text+00000a60
  00000018 fabsf -> .text+00000af4
  0000001c __kernel_rem_pio2f -> .text+00000b00
  00000020 scalbnf -> .text+0000104c
  00000024 floorf -> .text+00001128
  00000028 eml_error_valid -> .text+00001214
  0000002c __floatunsidf -> .text+0000015c
  00000030 __muldf3 -> .text+00000280
  00000034 __divdf3 -> .text+0000048c
  00000038 __truncdfsf2 -> .text+000005b0
  0000003c cosf -> .text+00000654
  00000040 sinf -> .text+000006e4
  00000044 eml_fft_fill -> .text+00001248
  00000048 check_extract_array -> .text+000014a0
  0000004c eml_fft_forward -> .text+0000134c
  00000050 .rodata+0x0 -> .rodata+00000000
  00000054 .rodata+0x80 -> .rodata+00000080
  00000058 .rodata+0x2c -> .rodata+000003c4
  0000005c .rodata.str1.1+0x0 -> .rodata.str1.1+000003d0
  00000060 eml_error_strs -> .data.rel.ro.local+000004a0
  00000064 .rodata.str1.1+0x13 -> .rodata.str1.1+000003e3
  00000068 .rodata.str1.1+0x1c -> .rodata.str1.1+000003ec
  0000006c .rodata.str1.1+0x32 -> .rodata.str1.1+00000402
  00000070 .rodata.str1.1+0x45 -> .rodata.str1.1+00000415
  00000074 .data.rel.ro+0x20 -> .data.rel.ro+00000498
  00000078 .data.rel.ro+0x10 -> .data.rel.ro+00000488
  0000007c .data.rel.ro+0x18 -> .data.rel.ro+00000490
  00000080 .data.rel.ro+0x0 -> .data.rel.ro+00000478
  00000084 fft_type -> .bss+00000010
  00000088 fft_locals_dict_table -> .bss+00000000
LIT: 00000090
  00000000 = 00080000
  00000004 = 7ff00000
  00000008 = 001fffff
  0000000c = 38000000
  00000010 = 7fffffff
  00000014 = 3f490fd8
  00000018 = 00000000
  0000001c = 7f7fffff
  00000020 = 4016cbe3
  00000024 = 3fc90f80
  00000028 = 3fc90fd0
  0000002c = 37354443
  00000030 = 37354400
  00000034 = 2e85a308
  00000038 = 43490f80
  0000003c = 3f22f984
  00000040 = 3f000000
  00000044 = 2e85a300
  00000048 = 248d3132
  0000004c = 43800000
  00000050 = 3e900000
  00000054 = 3f800000
  00000058 = 31ffffff
  0000005c = ad47d74e
  00000060 = 310f74f6
  00000064 = b493f27c
  00000068 = 37d00d01
  0000006c = bab60b61
  00000070 = 3d2aaaab
  00000074 = 3e999999
  00000078 = 2f2ec9d3
  0000007c = b2d72f34
  00000080 = 3638ef1b
  00000084 = b9500d01
  00000088 = 3c088889
  0000008c = be2aaaab
  00000090 = 3e2aaaab
  00000094 = 3b800000
  00000098 = 3e000000
  0000009c = 41000000
  000000a0 = 4c000000
  000000a4 = ffff3cb0
  000000a8 = 0da24260
  000000ac = 7149f2ca
  000000b0 = f149f2ca
  000000b4 = 807fffff
  000000b8 = 8da24260
  000000bc = 33000000
  000000c0 = 007fffff
  000000c4 = 54442d18
  000000c8 = 401921fb
_floatsidf.o: .text relocations via .rela.text:
_muldf3.o: .text relocations via .rela.text:
  00000274 LIT -> 00000090
  00000283 LIT -> 00000094
  0000029d LIT -> 00000098
_divdf3.o: .text relocations via .rela.text:
  000003f8 LIT -> 00000090
  0000047d LIT -> 00000090
  0000048f LIT -> 00000094
  000004aa LIT -> 00000098
_truncdfsf2.o: .text relocations via .rela.text:
  000005b3 LIT -> 0000009c
  000005f4 LIT -> 00000094
lib_a-sf_cos.o: .text relocations via .rela.text:
  00000657 LIT -> 000000a0
  0000065f LIT -> 000000a4
  00000664 LIT -> 000000a8
  0000066a LIT -> 000000ac
  00000683 GOT __ieee754_rem_pio2f -> 00000010
Traceback (most recent call last):
  File "/home/jon/projects/micropython/tools/mpy_ld.py", line 1076, in <module>
    main()
  File "/home/jon/projects/micropython/tools/mpy_ld.py", line 1072, in main
    do_link(args)
  File "/home/jon/projects/micropython/tools/mpy_ld.py", line 1043, in do_link
    link_objects(env, len(native_qstr_vals))
  File "/home/jon/projects/micropython/tools/mpy_ld.py", line 833, in link_objects
    do_relocation_text(env, sec.addr, r)
  File "/home/jon/projects/micropython/tools/mpy_ld.py", line 572, in do_relocation_text
    assert 0, (r_info_type, s.name, s.entry)
AssertionError: (11, '__ieee754_rem_pio2f', Container({'st_name': 10, 'st_value': 0, 'st_size': 0, 'st_info': Container({'bind': 'STB_GLOBAL', 'type': 'STT_NOTYPE'}), 'st_other': Container({'visibility': 'STV_DEFAULT'}), 'st_shndx': 'SHN_UNDEF'}))

[jonnor]

I am aware that I am pushing the mpy_ld.py / dynamic module support quite hard here, compared to usual. But some tips as to what might be the issue here would be very welcomed. So that maybe we can improve the support.

I am providing here the .o files for the __ieee754_rem_pio2f (for xtensawin and armv7emsp). I have poked a bit with readelf/objdump, but don't really know how to interpret the relocations - and why this symbol is different from any others...
micropython-reloc-rem_pio2.zip

[jonnor]

Renamed issue to highlight relevance. I am pretty sure this would happen whenever sin/cos or sinf/cosf are used. It would happen also if there just exists some code calling these functions - even these code paths are not actually used. Because there seems to be no dead-code stripping done by mpy_ld.py.