hth313 / Calypsi-tool-chains

Overview of the Calypsi tool chain and open source support packages
16 stars 0 forks source link

"internal error: labeling failed" when trying to write function address to memory #37

Closed ProxyPlayerHD closed 1 month ago

ProxyPlayerHD commented 5 months ago

i've been somewhat trying to see if i could get FreeRTOS running on a 65816. but sadly ran into some issues when compiling the port.c file.

i started commenting out functions and later indivitual lines to see which one was causing the problem (is it be possible to have internal errors report the last line number it was working on to make this step easier in the future?)

and i found that it gave me that error in a function that sets up the stack for a newly created task (ie write status register, entry point for execution, etc), more specifically on the line that writes the address of the task's function to the stack/memory. i isolated the function and all it required into a seperate C file, so you should be able to replicate it:

typedef unsigned short StackType_t;
typedef void (*TaskFunction_t)(void *arg);

void pxPortInitialiseStack(StackType_t *pxTopOfStack, TaskFunction_t pxCode){
    *pxTopOfStack = (StackType_t)pxCode;
}

with the command:

CC65816 --code-model compact --data-model medium -O2 --space --list-file example.lst -o example.o example.c

also in case you're curious, the basic FreeRTOS kernel (list.c, queue.c, and tasks.c) compiles to a combined ~16kB of code. which is honestly quite impressive for what is almost a complete regular OS.

hth313 commented 5 months ago

The problem is a missing rule for conversion between compact function pointer and integer. I have fixed it for the next release which is going to happen during May.

If urgent, you can work around it by assigning to a union of a function pointer and then read it back as an int without doing a cast.

If that does not work out, let me know and I can provide a quick release for you. In that case I need to know the host platform you use.

ProxyPlayerHD commented 5 months ago

the union idea seems to have worked, thank you! it's not urgent enough to require a quick pre-release so don't worry.

on another note, the manual mentioned that when using --enable-huge-attribute you need to rebuild the whole library as it has it disabled by default. question is do you have a makefile or instructions lying around for building the library from the included source code? since some files seem to check for specific config defines.

or can all of that just be ignored and it's as simple as just compiling every file in the src/lib/* directories and then combining them to a single library file with NLIB?

hth313 commented 5 months ago

I do not have anything suitable laying around, but I will take a look at if it can be generated.

Libraries are built using an internal tool with internal knowledge on how to deal with variant builds. It is not a script, actually a binary and it cannot be used on an installation as the setup is different. Also, it does not allow for arbitrary custom settings without a recompile of it, which work for me, but it is not well suited for end users.

hth313 commented 5 months ago

I have generated an initial attempt to build scripts of libraries which I can share with you for early feedback. They are more tailored for Linux/macOS than Windows (for now), and they may require some minor changes. Are you using 65816, roughly what library settings (code and data models) do you use?

ProxyPlayerHD commented 5 months ago

for now i've been porting my 65816 workflow to use the compact code/medium data model (with size_t being 32-bit, and -O2 --space to reduce the memory foorptint). on a similar note, i just quickly want to check if i understood the optimization flags correctly, since they work a bit differently from GCC.

here is how i would map the GCC flags to the Calypsi ones, is this roughly correct?

GCC     CalypsiC        meaning
-O0     -O0             disable optimizations
-O1     -O1 --speed     optimize for speed
-O2     -O2 --speed     optimize even more for speed
-O3      x              aggressively optimize for speed
-Os     -O1 --space     optimize for size
-Oz     -O2 --space     optimize even more for size
hth313 commented 4 months ago

You can download the build script here: https://drive.google.com/file/d/1xdie9dK785-l7m4HGaqPX68pa5YDyTU9/view?usp=sharing (I could not attach it here due to unknown file extension.) You may need to remove a line due to a missing file (it will be present in the next release) and you can edit the flags (and path if needed) at the top.

ProxyPlayerHD commented 4 months ago

you can just rename the file extension to something github supports and then say what extension (if any) it should had. so you can upload it directly instead of using an external file hosting site.

i had to comment out the commands and remove references to the files s_propagateNaNF64UI.o and f64_to_ui64.o, change ROOT=/usr/local/lib/calypsi-65816 to ROOT=. (since i ran it within the calypsi folder), and add the --enable-huge-attribute flag (since that was the whole point) but it seems to have worked... somewhat.

when linking with the generated library, the linker conplains that it cannot place the zdata section. according to the guide that section should only exist with the small data model, but that makes no sense considering the whole library was built with the --data-model medium option.... i did find the file that has the zdata section in it, it's atexit.o. looking into the script it is build as any other file with the --data-model medium option. so could be happening here?

.

on another note i did try to use your script to create a more "normal" makefile. but similar to your script, while it runs (especially fast with -j24), the generated libary refuses to link. this time with undefined reference errors to _Vfp, _Mod32, _Shr64, _Mul64 _MoveLongFar, and a looooooot of _Dp. so clearly i did something very wrong!

you can take a look yourself if you want: makefile.txt (just remove the .txt extension and place the makefile inside the calypsi/src directory next to the lib and softfloat directories, also you need to export the calypsi/bin directory to PATH before running make)

hth313 commented 4 months ago

It is expected that there are a couple of floating point modules missing at this point, they will be part of the next release. For now the script is not all that polished, the main reason is to have something that helps in rebuilding the library, for the few situations it may be needed.

I compiled aexit.c with cc65816 --enable-huge-attribute atexit.c -l --data-model=medium and it has znear in the list file, no zdata.

The _Vfp and the other undefined symbols are defined in assembly modules.

ProxyPlayerHD commented 4 months ago

just as you commented i found an error in the makefile that causes none of the lowlevel assembly files to be listed in the required object files for the library, so they were never assembled and put into the library...

in the makefile, on this line:

# Extra Object files (S)
EXOBJA := $(patsubst %.s, $(LIBOBJDIR)/%.o, $(notdir $(EXSCRA)))

EXSCRA had to be changed to EXSRCA (swapping the C and R)

# Extra Object files (S)
EXOBJA := $(patsubst %.s, $(LIBOBJDIR)/%.o, $(notdir $(EXSRCA)))

I also had to remove --weak-symbols from AFLAGS since only 1 file was actually using that while assembling.

and now everything compiles fine and i can actually link with the library! you can fix the makefile i posted in case you want to polish it up and include it in the next release so people can more easily build the library themselves (with some extra parameters to allow users to compile with different code and data models, 32/64-bit floats, huge enabled/disabled, etc).

.

as for atexit, the command in the script you sent is:

cc65816 -o objs/clib-cc-md/atexit.o ${ROOT}/src/lib/stdlib/atexit.c -Wno-unused-value --weak-symbols ${CFLAGS} -I${ROOT}/src/lib -I${ROOT}/src/softfloat

where CFLAGS contains --data-model medium. which is why i'm so confused by that. i did some more testing by using set -x to have the script evaluate every variable and then print the command it runs and this is what it does for all files:

++ cc65816 -o objs/clib-cc-md/atexit.o ./src/lib/stdlib/atexit.c -Wno-unused-value --weak-symbols -O2 -I./src/lib -I./src/softfloat

CFLAGS only evaluates to -O2, all the extra parameters after it seem to be completely ignored.

i changed the lines for CFLAGS and AFLAGS, replacing the parenthathese with single quotes like this:

CFLAGS='-O2 --space --code-model=compact --data-model=medium --32bit-doubles --core=65816 --enable-huge-attribute'
AFLAGS='--core=65816 --code-model=compact --data-model=medium'

and that seems to have fixed the issue (also now the library file generated from the script is the same exact size as with my makefile, confirming that it works as intended).

.

btw, is there a way to tell the linker which clib file you want to compile with, instead of it choosing one on it's own? because i'd like to keep the original clib-cc-md.a, so i named the newly generated one clib-cc-md-huge.a but the linker always grabs the original, even when i specify clib-cc-md-huge.a in the command. being able to overwrite the linker's automatic clib choice would be a nice to have feature, specifically for stuff like this.

hth313 commented 4 months ago

I had some troubles with the quoting of flags which for some reason did not work using either single or double, so I found this parentheses way, which apparently does not work. Now I retried single quotes as you point out and it works. I have no idea how I messed that up before.

The reason I do not do a make file is for simplicity. I do not expect many people will need to rebuild the library, and I have seen some using build scripts, so I decided to provide a starting point that is as basic as possible.

It was intended to work replacing the C library on the command line, but I can see that my logic for doing that was not right. I have reworked it for the release which I plan to make during the coming week.

hth313 commented 1 month ago

Closing this for now. There is a starting point for end users to build their own libraries. Also the missing files prior has been added, so I regard this is done.