Can't get cogc files to compile.

Kye

The linker can't seem to find the __load_start symbol for the cogc file. I'm trying to build the libadcACpropab.side library distributed with SimpleIde. I've been developing my own build system with CMake.

I compile the cogc file by doing:

propeller-elf-gcc -g -Os -ffunction-sections -fdata-sections -m32bit-doubles -Wall -std=c99 -mcog -r -xc -o filename.cogc.obj -c filename.cogc
propeller-elf-objcopy --localize-text --rename-section .text=filename.cogc.obj filename.cogc.obj

And then the file is archived and finally is linked with the main program that calls functions that need to start the cogc object.

I saw this simpleide issue about this: https://code.google.com/p/propside/issues/detail?id=184&colspec=ID%20Type%20Status%20Priority%20Owner%20Summary

However, I'm not sure how to fix the library code via the compile process without editing it. The library code does not do what the above link says to do.

... Any thoughts? I'm at a dead end on how to get this to work.

Heater.

Kye,

I have no idea really as I have not been building cog code since before there was a SimpleIDE and I believe things have changed since then.

I just built that library with SimpleIDE and notice that the way it does it is a bit different to what you are doing. See below.

The highlighted line shows the ".text" section is reamed to "filename.cog" not "filename.cog.obj"

There is something up with this. The build seems to work OK but something fails with propeller-load and then as you see the status report says ". Build Succeeded!". Simple IDE does pop up a build failed dialog which when clicked continues and ends with a "build done" in green as if everything was OK. Still that is nothing to do with the issue you have.

propeller-elf-gcc -r -Os -mcog -o cmm/adcACpropab.cog -xc adcACpropab.cogc

[B]propeller-elf-objcopy --localize-text --rename-section .text=adcACpropab.cog cmm/adcACpropab.cog[/B]

propeller-elf-gcc -I . -L . -I /home/michael/SimpleIDE/Learn/Simple Libraries/Utility/libsimpletools -L /home/michael/SimpleIDE/Learn/Simple Libraries/Utility/libsimpletools/cmm/ -I /home/michael/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext -L /home/michael/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext/cmm/ -I /home/michael/SimpleIDE/Learn/Simple Libraries/Protocol/libsimplei2c -L /home/michael/SimpleIDE/Learn/Simple Libraries/Protocol/libsimplei2c/cmm/ -I /home/michael/SimpleIDE/Learn/Simple Libraries/Convert/libadcACpropab -L /home/michael/SimpleIDE/Learn/Simple Libraries/Convert/libadcACpropab/cmm/ -Os -mcmm -m32bit-doubles -fno-exceptions -std=c99 -c adcACpropab.c -o cmm/adcACpropab.o

propeller-elf-ar rs cmm/libadcACpropab.a cmm/adcACpropab.cog cmm/adcACpropab.o

/opt/parallax/bin/propeller-elf-ar: creating cmm/libadcACpropab.a

propeller-elf-gcc -I . -L . -I /home/michael/SimpleIDE/Learn/Simple Libraries/Utility/libsimpletools -L /home/michael/SimpleIDE/Learn/Simple Libraries/Utility/libsimpletools/cmm/ -I /home/michael/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext -L /home/michael/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext/cmm/ -I /home/michael/SimpleIDE/Learn/Simple Libraries/Protocol/libsimplei2c -L /home/michael/SimpleIDE/Learn/Simple Libraries/Protocol/libsimplei2c/cmm/ -I /home/michael/SimpleIDE/Learn/Simple Libraries/Convert/libadcACpropab -L /home/michael/SimpleIDE/Learn/Simple Libraries/Convert/libadcACpropab/cmm/ -o cmm/libadcACpropab.elf -Os -mcmm -m32bit-doubles -fno-exceptions -std=c99 libadcACpropab.c cmm/libadcACpropab.a -lm -lsimpletools -lsimpletext -lsimplei2c -ladcACpropab -lm -lsimpletools -lsimpletext -lsimplei2c -lm -lsimpletools -lsimpletext -lm -lsimpletools -lm

propeller-load -s cmm/libadcACpropab.elf

/opt/parallax/bin/propeller-load: 1: /opt/parallax/bin/propeller-load: Syntax error: word unexpected (expecting ")")

propeller-elf-objdump -h cmm/libadcACpropab.elf

Done. Build Succeeded!

DavidZemon

Same problem with PropWare.
Looking into it...

Kye

There's no documentation on how to do this and how the __load_start symbol gets put into the file is magic.

David Betz

Kye wrote: »

There's no documentation on how to do this and how the __load_start symbol gets put into the file is magic.

propeller-elf-objcopy creates those symbols. Check the documentation here: http://propgcc.googlecode.com/hg/doc/Library.html#RunningNative

Kye

Can you add that page to the wiki? Its not easy to find. All those pages should have links in the main wiki area.

David Betz

Kye wrote: »

Can you add that page to the wiki? Its not easy to find. All those pages should have links in the main wiki area.

Actually, I'm wrong. It doesn't seem to be propeller-elf-objcopy that makes those symbols. It's the linker itself. The code to do it is in propgcc/binutils/ld/emultempl/propeller.em. At a quick glance, I wasn't able to determine under what circumstances those symbols are generated. Maybe ersmith will jump in and remind me. :-)

David Betz

David Betz wrote: »

Actually, I'm wrong. It doesn't seem to be propeller-elf-objcopy that makes those symbols. It's the linker itself. The code to do it is in propgcc/binutils/ld/emultempl/propeller.em. At a quick glance, I wasn't able to determine under what circumstances those symbols are generated. Maybe ersmith will jump in and remind me. :-)

Okay, the answer is that the linker creates these symbols for any section whose name ends in ".cog", ".ecog", or ".kerext".

David Betz

David Betz wrote: »

Okay, the answer is that the linker creates these symbols for any section whose name ends in ".cog", ".ecog", or ".kerext".

I just noticed that the Wiki already says this except that it only talks about sections whose names end in .cog because .ecog and .kerext hadn't been invented at the time it was written.

Kye

I've made sure the section is named .cog and I've removed all the extra commands. I now just do (summary):

propeller-elf-gcc.exe -Os -mcog -r -xc -o adcACpropab.cogc.obj -c adcACpropab.cogc
propeller-elf-objcopy.exe --localize-text --rename-section .text=".adcACpropab.cog" adcACpropab.cogc.obj
propeller-elf-ar.exe cr liblibadcACpropab.a adcACpropab.cogc otherthing1.c.obj otherthing2.c.obj
propeller-elf-gcc.exe -g -Os -m32bit-doubles -Wall -std=c99 -lm -mcmm mainFile.c.obj -o output.elf -Wl,--start-group liblibwavplayer.a liblibabvolts.a liblibadcACpropab.a liblibadcDCpropab.a liblibdacctr.a liblibvgatext.a liblibmstimer.a liblibservo.a liblibservoAux.a liblibservodiffdrive.a liblibsimplei2c.a liblibsirc.a liblibabcalibrate.a liblibabdrive.a liblibcolorpal.a liblibcompass3d.a liblibgps.a liblibmma7455.a liblibmx2125.a liblibping.a liblibrfidser.a liblibsoundimpact.a liblibfdserial.a liblibsimpletext.a liblibsimpletools.a liblibstacktest.a -Wl,--end-group


I've examined the output object and its section has been renamed to .adcACpropab.cog, however, the linking still fails. Maybe there is some magic that has to happening during the linking stage to get everything to work? The link I posted in the first posts says that the way the file that is looking for __load_start_adcACpropab_cog is coded that there is a problem.

I've attached the build output if that helps.

Kye

Do you need to execute the cogc compile commands in the same directory as the file? I didn't notice paths inside the output object file. But, this mattered for compiling spin DAT sections into the project using objcopy.

David Betz

Kye wrote: »

I've made sure the section is named .cog and I've removed all the extra commands. I now just do (summary):

propeller-elf-gcc.exe -Os -mcog -r -xc -o adcACpropab.cogc.obj -c adcACpropab.cogc
propeller-elf-objcopy.exe --localize-text --rename-section .text=".adcACpropab.cog" adcACpropab.cogc.obj
propeller-elf-ar.exe cr liblibadcACpropab.a adcACpropab.cogc otherthing1.c.obj otherthing2.c.obj
propeller-elf-gcc.exe -g -Os -m32bit-doubles -Wall -std=c99 -lm -mcmm mainFile.c.obj -o output.elf -Wl,--start-group liblibwavplayer.a liblibabvolts.a liblibadcACpropab.a liblibadcDCpropab.a liblibdacctr.a liblibvgatext.a liblibmstimer.a liblibservo.a liblibservoAux.a liblibservodiffdrive.a liblibsimplei2c.a liblibsirc.a liblibabcalibrate.a liblibabdrive.a liblibcolorpal.a liblibcompass3d.a liblibgps.a liblibmma7455.a liblibmx2125.a liblibping.a liblibrfidser.a liblibsoundimpact.a liblibfdserial.a liblibsimpletext.a liblibsimpletools.a liblibstacktest.a -Wl,--end-group


I've examined the output object and its section has been renamed to .adcACpropab.cog, however, the linking still fails. Maybe there is some magic that has to happening during the linking stage to get everything to work? The link I posted in the first posts says that the way the file that is looking for __load_start_adcACpropab_cog is coded that there is a problem.

I've attached the build output if that helps.

Okay, you've run into the problem that I solved in a different way in some of the library code. The problem is that you can't put one of these .cog files into a library because it will never be used. The linker only pulls code from a library if it defines a symbol that is needed by the program but these symbols are created on the fly so they can't be used to pull code from a library. They work fine if you link the .cog file into your program explicitly but not if it is in a library. I'll have to dig a bit to find out how I solved this.

David Betz

Here is what I do in the propgcc library when I need to put drivers in a library.

CC=propeller-elf-gcc
OBJCOPY=propeller-elf-objcopy

%.o: %.c
	$(CC) $(BASEFLAGS) -mcog -o $@ $<
	
%.dat: %.o
	$(OBJCOPY) -O binary -j .text $< $@
	
%.cog: %.dat
	$(OBJCOPY) -I binary -B propeller -O $(CC) --rename-section .data=.text $< $@

In this case, the second invocation of propeller-elf-objcopy generates the symbols _binary_foo_dat_start and _binary_foo_dat_end if the file was named "foo.c" originally and hence the file created by the second step was named "foo.dat".

Kye

I need the symbols to be named __load_start_* and __load_end_*. I guess I can rename the binary symbols? Do you know how __load_start and __load_end are related to _binary* addresses? Is it a 1-to-1 mapping?

EDIT: Don't I need to copy the .data section to the output too?

Kye

Can I just create the symbols?

David Betz

Kye wrote: »

I need the symbols to be named __load_start_* and __load_end_*. I guess I can rename the binary symbols? Do you know how __load_start and __load_end are related to _binary* addresses? Is it a 1-to-1 mapping?

EDIT: Don't I need to copy the .data section to the output too?

Why do they need those names?

David Betz

Kye wrote: »

Can I just create the symbols?

You can probably create new symbols and use the default symbol names as their values. In other words, create synonyms for the default symbol names. Why does it matter what the names are though? Can't you just change the code that references them to use the new names? The advantage of this method is that it doesn't depend on magic behavior of the linker. The downside though is that the main program can't share variables with the driver. I never do this myself but I guess it can be handy in some cases.

Kye

I'm compiling the simpleIDE libraries. They should work without modification of the code. The simple library wants to see a __load_start_*_cog symbol. In general my build system needs to work like how simpleIDE works.

David Betz

Kye wrote: »

I'm compiling the simpleIDE libraries. They should work without modification of the code. The simple library wants to see a __load_start_*_cog symbol. In general my build system needs to work like how simpleIDE works.

Okay, I understand. I'm not sure why the Simple Libraries don't have trouble with the linker-generated symbols. They may use an alternate approach that Eric devised where dummy symbols are used to pull files out of the library.

Kye

Do you know how I would do that?

The other way seems... eh...

David Betz

Kye wrote: »

Do you know how I would do that?

The other way seems... eh...

eh?

Kye

I think the s option when SimpleIDE creates libraries is what I need to use. It looks like ranlib can be called on each library after it is built.

David Betz

Kye wrote: »

I think the s option when SimpleIDE creates libraries is what I need to use. It looks like ranlib can be called on each library after it is built.

Do what works for you. I think you still need a symbol reference to pull anything out of a library. You either have to use some dummy symbol or reference a real symbol in the object file. The scheme that uses propeller-elf-objcopy uses symbols created by that utility to mark the start and end (and size) of the binary blob. Those can be used directly to load the driver into a COG. Seem pretty straight forward to me. More natural than magic symbols introduced by a custom modification to the linker and dummy symbols. The symbol creation that objcopy does is standard and works on any GCC platform. It is not Propeller specific.

Kye

I agree, however, the build system I am designing needs to operate like simpleIDE's build system.

It looks like ranlib is already run on each library after it is compiled... so that isn't the problem.

David Betz

Kye wrote: »

I agree, however, the build system I am designing needs to operate like simpleIDE's build system.

It looks like ranlib is already run on each library after it is compiled... so that isn't the problem.

No, it isn't. As I said, the problem is that you need to refer to a symbol in the object file if you want it pulled out of the library. Are you sure this hasn't been changed in a later version of SimpleIDE? I'm wondering why SimpleIDE itself doesn't have a problem with this.

Kye

I can work around this by including the object files directly in the linking command. This seems to work. When I'm generating cogc files in cmake I can store the paths of them and then pass them as libraries. If they aren't used then no harm is done.

Using objcopy is a pain to work with in cmake. I'm trying to avoid doing what you have suggested because it will require an extremely long add_custom _command in cmake to make it happen (this is because objcopy requires you to invoke it from the directory from where the object is when generating the binary symbols the path is added to the file name. Spin file support was already complex enough...

David Betz

Kye wrote: »

I can work around this by including the object files directly in the linking command. This seems to work. When I'm generating cogc files in cmake I can store the paths of them and then pass them as libraries. If they aren't used then no harm is done.

Using objcopy is a pain to work with in cmake. I'm trying to avoid doing what you have suggested because it will require an extremely long add_custom _command in cmake to make it happen (this is because objcopy requires you to invoke it from the directory from where the object is when generating the binary symbols the path is added to the file name. Spin file support was already complex enough...

Yes, that is a very unfortunate feature of objcopy. I did a cd to the directory before running it. How does SimpleIDE build this? Does it put the .cog files into a library?

Kye

SimpleIDE runs the build from the same directory as the .side file. I believe reading somewhere you had to put .cogc and .spin files in the same directory for this reason. Maybe that has been relaxed...

SimpleIDE does put the .cog files into a library. I don't know why it doesn't have any problems.

...

Putting all .cogc.obj files into the final link command works perfectly. cmake will automatically put everything in a response file if the command line gets too long so there is no problem.

David Betz

Can you post the code you're trying to compile along with the SimpleIDE project that handles it successfully?

David Betz

Actually, I think I figured out why it works in SimpleIDE. Steve isn't including the generated library with -l. He's just adding the .a file to the command line directly. That probably has the effect of linking all of the object files in the archive whether they are referenced or not. That's just a guess though. You can try this theory by adding your .a file to your linker command line instead of including it with the -l syntax.

David Betz

David Betz wrote: »

Actually, I think I figured out why it works in SimpleIDE. Steve isn't including the generated library with -l. He's just adding the .a file to the command line directly. That probably has the effect of linking all of the object files in the archive whether they are referenced or not. That's just a guess though. You can try this theory by adding your .a file to your linker command line instead of including it with the -l syntax.

I'm beginning to doubt this because from what I've read -lfoo is just a shorthand for libfoo.a so the two should be equivalent. Could you post your example code so I can try to track this down further?