Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

link error variable term used where not expected #2

Open
parisseb opened this issue Feb 16, 2023 · 15 comments
Open

link error variable term used where not expected #2

parisseb opened this issue Feb 16, 2023 · 15 comments
Assignees
Labels
bug Something isn't working

Comments

@parisseb
Copy link

parisseb commented Feb 16, 2023

While trying to link KhiCAS, I get the error below that I have no idea how to deal with (I did not write assembly code, therefore the FAQ does not apply "You probably have assembly code that was not placed in a linker section, see Assembly Constants").
Source code to reproduce: https://www-fourier.univ-grenoble-alpes.fr/~parisse/ti/khicas.tgz

Thanks for any hint!

========= error log ===========
mkdir -p 'bin'
echo [linking] bin/DEMO.bin
[linking] bin/DEMO.bin
/home/parisse/CEdev/bin/fasmg -v1 '/home/parisse/CEdev/meta/ld.alm' -i 'DEBUG := 0' -i 'HAS_PRINTF := 1' -i 'HAS_LIBC := 1' -i 'HAS_LIBCXX := 1' -i 'PREFER_OS_CRT := 0' -i 'PREFER_OS_LIBC := 1' -i 'include "/home/parisse/CEdev/examples/khicas/app_tools/linker_script"' -i 'range .bss $D052C6 : $D13FD8' -i 'provide __stack = $D1A87E' -i 'locate .header at $0'  -i 'source "obj/icon.src", "/home/parisse/CEdev/lib/crt/crt0.src", "obj/lto.src"' -i 'library "/home/parisse/CEdev/lib/libload/fatdrvce.lib", "/home/parisse/CEdev/lib/libload/fileioc.lib", "/home/parisse/CEdev/lib/libload/fontlibc.lib", "/home/parisse/CEdev/lib/libload/graphx.lib", "/home/parisse/CEdev/lib/libload/keypadc.lib", "/home/parisse/CEdev/lib/libload/msddrvce.lib", "/home/parisse/CEdev/lib/libload/srldrvce.lib", "/home/parisse/CEdev/lib/libload/usbdrvce.lib"' -i 'provide __app_name = "DEMO"' -i 'provide __app_version = "1"' -i 'provide __app_desc = "shell"'  bin/DEMO.bin
flat assembler  version g.jmhx
/home/parisse/CEdev/meta/ld.alm [1570]:
	
macro ? [1297]:
	read source
:read? [14] (CALM)
assemble :temp [1]:
	include?! 'app_tools/app.src'
app_tools/app.src [64]:
	dl relocation
dl? [19] (CALM)
assemble :temp [1]:
	@ez80.word long?, current
macro @ez80.word [16]:
	@ez80.word size, value
@ez80.word [8] (CALM)
Error: variable term used where not expected.
make: *** [/home/parisse/CEdev/meta/makefile.mk:291 : bin/DEMO.bin] Erreur 2
/bin/cp: impossible d'évaluer 'bin/DEMO.8*': Aucun fichier ou dossier de ce type
@adriweb
Copy link
Member

adriweb commented Feb 16, 2023

repro'd on latest toolchain, and it happens only when using app_tools.

@adriweb adriweb added the bug Something isn't working label Feb 16, 2023
@adriweb adriweb transferred this issue from CE-Programming/toolchain Feb 17, 2023
@adriweb
Copy link
Member

adriweb commented Nov 30, 2023

To give more context to this:

  • We were able to repro a (this?) linking issue with a build of KhiCAS using the latest compiler which fixed other things.
    ... which currently (without app_tools) outputs a 8.9 MB lto.bc, and 4.7 MB .bin. :
/Users/adriweb/CEdev/meta/ld.alm [1568] macro ? [1295] :read? [14] app_tools/app.src [64]:
    dl relocation
dl? [19] macro @ez80.word [16] @ez80.word [1] (CALM)
Error: variable term used where not expected.
make: *** [bin/DEMO.bin] Error 2
  • This issue doesn't happen with a sample code that has a very large dummy array (referenced somewhere so it doesn't get optimized out) like :
    static const uint8_t filler[2500000] = {0};, so I guess the issue is only happening when there's actual code all over the place.
    (For the record, I generated and successfully tested (on CEmu anyway) a 2.9 MB app and it ran fine, so the OS doesn't have a hardcoded limitation somewhere, or at least it's higher)

@commandblockguy
Copy link
Member

Poking around a bit, the first symbol that's causing this issue is __GLOBAL__sub_I_first.cc, so I'm guessing this is an issue with sections related to static object initialization/destruction. They're kinda a weird edge case and the toolchain's linker script handles them differently than other sections, and I haven't actually tested them yet. I'll look into how to make that work.

@commandblockguy
Copy link
Member

It seems like it would take some changes to the crt to get .init_array working properly. I'm inclined to just write this off as a "known limitation" for the time being, considering how rare usage of .init_array seems to be. For the code provided, it should be fairly easy to work around this considering there's only a single .init_array item, and all it does is register a no-op destructor for init_gmp_memory_instance, by just moving the init_gmp_memory_instance inside of the #ifdef HAVE_LIBGC block.

@parisseb
Copy link
Author

parisseb commented Jan 3, 2024

Thanks, I modified first.cc to avoid this linking error (with #ifndef USE_GMP_REPLACEMENTS since GMP is not used). However I still get thousends of errors at link time

flat assembler  version g.k4v8
/home/parisse/CEdev/meta/ld.alm [1568]:
	
macro ? [1583]:
	output.hex section.base?
:output.hex [7] (CALM)
Error: cannot subdivide variable term.
/home/parisse/CEdev/meta/ld.alm [1568]:
	
macro ? [1583]:
	output.hex section.base?
:output.hex [7] (CALM)
Error: variable term used where not expected.
/home/parisse/CEdev/meta/ld.alm [1568]:
	
...

@commandblockguy
Copy link
Member

That's strange, I'm able to compile it successfully. Do you have the debug map enabled in the makefile? If so, try turning that off and see if it still gives the same error.

@parisseb
Copy link
Author

parisseb commented Jan 3, 2024

I'm unsure, but it seems not, I see OUTPUT_MAP = NO in app_tools/makefile. If you have a successfull compile, maybe the easiest is that you send me a working archive.

@adriweb
Copy link
Member

adriweb commented Jan 3, 2024

I'm also able to build it successfully now (I'm running the latest toolchain and app_tools, maybe that's why?).
(the linking step does take a while, 7min 07s here, so be warned)

However it's a bit too big for now: 3 857 172 bytes .8ek file, so it's not testable as-is. It would need to be 850k lighter... at least.

@parisseb
Copy link
Author

parisseb commented Jan 3, 2024

I have updated my linux version to the latest nightly update (https://github.com/CE-Programming/toolchain/releases), also updated app.src in app_tools, I still get all these errors. I'm using -Oz (not -Os). Can you describe the precise OS/version you are using?

@adriweb
Copy link
Member

adriweb commented Jan 3, 2024

I've built it on my mac running the latest macOS but that doesn't matter anyway. I used -Oz too.
I realize I have a slightly older fasmg ("version g.jya9") but I don't think this matters either.

Did you make clean and make app -j ?

@parisseb
Copy link
Author

parisseb commented Jan 3, 2024

Still no luck.

ls -l ~/CEdev/bin/
total 226268
-rwxr-xr-x 1 parisse parisse   979152 14 déc.  22:29 cedev-config
-rwxr-xr-x 1 parisse parisse  6081048 14 déc.  22:28 cemu-autotester
-rwxr-xr-x 1 parisse parisse    40152 14 déc.  22:29 convbin
-rwxr-xr-x 1 parisse parisse    62848 14 déc.  22:29 convfont
-rwxr-xr-x 1 parisse parisse   417920 14 déc.  22:29 convimg
-rwxr-xr-x 1 parisse parisse 78772240 13 déc.  20:01 ez80-clang
-rwxr-xr-x 1 parisse parisse 78763696 29 oct.  14:43 ez80-clang.old
-rwxr-xr-x 1 parisse parisse  4376976 13 déc.  18:54 ez80-link
-rwxr-xr-x 1 parisse parisse 26193976 15 févr.  2023 ez80-lto
-rwxr-xr-x 1 parisse parisse 35830104 15 févr.  2023 ez80-lto2
-rwxr-xr-x 1 parisse parisse    70710 14 déc.  22:28 fasmg

ez80-lto seems outdated, where can I update it?

@adriweb
Copy link
Member

adriweb commented Jan 3, 2024

ez80-lto/lto2 aren't actually needed or used.

@parisseb
Copy link
Author

parisseb commented Jan 3, 2024

I also tried on windows, same error.

@commandblockguy
Copy link
Member

Here's a tarball of my working compile: khicas.tar.gz
I'm using the latest toolchain version.

@parisseb
Copy link
Author

parisseb commented Jan 3, 2024

Thanks, it now works! The issue was in the makefile where #include $(shell cedev-config --makefile) was not commented.
I will now try to shrink the code size, by removing the plotting/geometry commands, since the output is too large for emulator testing. Once this is done, there will still remain some work to support loading large app on the real calculator...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Development

No branches or pull requests

3 participants