Shop OBEX P1 Docs P2 Docs Learn Events
PropGCC static library pulls in unused COGC module — Parallax Forums

PropGCC static library pulls in unused COGC module

DavidZemonDavidZemon Posts: 2,973
edited 2016-02-17 03:26 in Propeller 1
When I compile a certain executable and the related static library does not contain the cogc module, I get a code size of 22,612. If the static library has the cogc module it is 23,064. Looks to me like the cogc module is being included, but I don't know why.

I've looked through CMake's verbose output and condensed it some for easier reading. The include lines were all stripped out, I removed directories in front of file names, and I removed all of CMake's status lines so it's just important business. Here's what it looks like:
/opt/parallax/bin/propeller-elf-gcc    -mcog -xc -r -save-temps  -Os -m32bit-doubles -Wall -ffunction-sections -fdata-sections     -std=c99  -I"A whole ton of include lines here"  -o adcACpropab.cogc.cog adcACpropab.cogc

/opt/parallax/bin/propeller-elf-objcopy --localize-text --rename-section .text=adcACpropab.cogc.cog adcACpropab.cogc.cog

/opt/parallax/bin/propeller-elf-ar cr libSimple.a  tons_of_files.c.obj adcACpropab.cogc.cog tons_more_files.c.obj

/opt/parallax/bin/propeller-elf-ar r  libSimple.a  some_more_files_because_there_are_too_many_for_one_line.c.obj

/opt/parallax/bin/propeller-elf-ranlib libSimple.a

/opt/parallax/bin/propeller-elf-gcc  -save-temps  -Os -m32bit-doubles -Wall -ffunction-sections -fdata-sections     -std=c99   -mlmm   -Wl,--gc-sections -oFileReader_Demo.elf FileReader_Demo.cpp.obj libPropWare.a libLibpropeller.a libSimple.a

This has probably always been going on since I started including adcACpropab.cogc in PropWare's version of Simple, but I don't know for sure. It was brought to my attention a couple days ago because, intermittently, it will throw a "relocation truncated to fit" error.

Why? Is there a fix? Is it simply not possible to include cogc files in libraries?

Comments

  • I'm not able to build PropWare (Debian Jessie only has CMake 3.0.2 and PropWare needs 3.3) so I'm just guessing at this point what's wrong, but perhaps some external symbols (like CNT or OUTA) are being defined in the .cog file after it's been compiled and the .cog is being pulled in to define those symbols for other object files. You could try using propeller-elf-strip to strip the unnecessary symbols from the .cog file before putting it in the archive. I think --strip-unneeded is the option you'll want for propeller-elf-strip.
  • ersmith wrote: »
    I'm not able to build PropWare (Debian Jessie only has CMake 3.0.2 and PropWare needs 3.3) so I'm just guessing at this point what's wrong

    I'll take another look at the feature available in 3.3 and see if I really need it. Maybe I'll back it down to 3.0.
    ersmith wrote: »
    perhaps some external symbols (like CNT or OUTA) are being defined in the .cog file after it's been compiled and the .cog is being pulled in to define those symbols for other object files. You could try using propeller-elf-strip to strip the unnecessary symbols from the .cog file before putting it in the archive. I think --strip-unneeded is the option you'll want for propeller-elf-strip.

    That sounds like a very reasonable guess, I'll try it out tonight. Thanks
  • Oops no, --strip-unneeded probably won't work if (as is likely) some of the problematic symbols are in use in the .cog file. Instead we'll have to localize them. In the objcopy line, along with --localize-text we'll also have to add --localize-syms=abssyms.txt, where abssyms.txt is a file like:
    CNT
    CTRA
    CTRB
    DIRA
    DIRB
    DIRC
    DIRD
    FRQA
    FRQB
    INA
    INB
    OUTA
    OUTB
    PAR
    PHSA
    PHSB
    PINA
    PINB
    PINC
    PIND
    __stack_end
    VCFG
    VSCL
    __clkfreqval
    __clkmodeval
    
    I produced that list by doing "propeller-elf-nm -g" on a .cog file to see what symbols it defined; all the register names are potentially problematic. I'm not quite so sure about __stack_end, __clkfreqval and __clkmodeval, since those are weakly defined, but OTOH we don't need the definitions from the .cog file, so we might as well localize them as well.
  • This is one reason I like the "binary blob" approach to COG drivers. Of course, that is less flexible. It does avoid this sort of problem though.
  • ersmith wrote: »
    Oops no, --strip-unneeded probably won't work if (as is likely) some of the problematic symbols are in use in the .cog file. Instead we'll have to localize them. In the objcopy line, along with --localize-text we'll also have to add --localize-syms=abssyms.txt, where abssyms.txt is a file like:
    CNT
    CTRA
    CTRB
    DIRA
    DIRB
    DIRC
    DIRD
    FRQA
    FRQB
    INA
    INB
    OUTA
    OUTB
    PAR
    PHSA
    PHSB
    PINA
    PINB
    PINC
    PIND
    __stack_end
    VCFG
    VSCL
    __clkfreqval
    __clkmodeval
    
    I produced that list by doing "propeller-elf-nm -g" on a .cog file to see what symbols it defined; all the register names are potentially problematic. I'm not quite so sure about __stack_end, __clkfreqval and __clkmodeval, since those are weakly defined, but OTOH we don't need the definitions from the .cog file, so we might as well localize them as well.

    Perfect! I can make that happen :)
    David Betz wrote: »
    This is one reason I like the "binary blob" approach to COG drivers. Of course, that is less flexible. It does avoid this sort of problem though.

    Are you referring to the binary blob that spin2cpp produces from the DAT section of a Spin file or something else?
  • DavidZemon wrote: »
    ersmith wrote: »
    Oops no, --strip-unneeded probably won't work if (as is likely) some of the problematic symbols are in use in the .cog file. Instead we'll have to localize them. In the objcopy line, along with --localize-text we'll also have to add --localize-syms=abssyms.txt, where abssyms.txt is a file like:
    CNT
    CTRA
    CTRB
    DIRA
    DIRB
    DIRC
    DIRD
    FRQA
    FRQB
    INA
    INB
    OUTA
    OUTB
    PAR
    PHSA
    PHSB
    PINA
    PINB
    PINC
    PIND
    __stack_end
    VCFG
    VSCL
    __clkfreqval
    __clkmodeval
    
    I produced that list by doing "propeller-elf-nm -g" on a .cog file to see what symbols it defined; all the register names are potentially problematic. I'm not quite so sure about __stack_end, __clkfreqval and __clkmodeval, since those are weakly defined, but OTOH we don't need the definitions from the .cog file, so we might as well localize them as well.

    Perfect! I can make that happen :)
    David Betz wrote: »
    This is one reason I like the "binary blob" approach to COG drivers. Of course, that is less flexible. It does avoid this sort of problem though.

    Are you referring to the binary blob that spin2cpp produces from the DAT section of a Spin file or something else?
    I'm talking about a binary produced from the DAT section but not necessarily with spin2cpp. I usually write drivers using C or PASM not Spin.

  • David Betz wrote: »
    I'm talking about a binary produced from the DAT section but not necessarily with spin2cpp. I usually write drivers using C or PASM not Spin.

    Oh ok - that makes sense. They're certainly easier to deal with from a build-system perspective, but not so much from a "i need to make a small change" perspective :)
  • DavidZemon wrote: »
    David Betz wrote: »
    I'm talking about a binary produced from the DAT section but not necessarily with spin2cpp. I usually write drivers using C or PASM not Spin.

    Oh ok - that makes sense. They're certainly easier to deal with from a build-system perspective, but not so much from a "i need to make a small change" perspective :)
    I don't understand what you mean. Why is it any harder to make a change with a driver that is compiled into a binary blob? Certainly, you can still modify the source code and regenerate the blob.

  • DavidZemonDavidZemon Posts: 2,973
    edited 2016-02-17 21:46
    David Betz wrote: »
    DavidZemon wrote: »
    David Betz wrote: »
    I'm talking about a binary produced from the DAT section but not necessarily with spin2cpp. I usually write drivers using C or PASM not Spin.

    Oh ok - that makes sense. They're certainly easier to deal with from a build-system perspective, but not so much from a "i need to make a small change" perspective :)
    I don't understand what you mean. Why is it any harder to make a change with a driver that is compiled into a binary blob? Certainly, you can still modify the source code and regenerate the blob.

    Oh, I was under the assumption the original source code wouldn't be distributed. I'm not sure why I assumed that... seems silly now.

    Anyway, I think it's really cool that the cogc/cogcpp option exists. Being able to write beautiful, high-level, object-oriented code that still executes with native speed via cogcpp is fantastic. Combining that with a few (~60) lines of inline assembly and I was able to create a really cool stepper motor driver used in a Pick-n-Place machine for a client half a year ago. I would have liked (and originally tried) to use fcache for that drivers, but broke the 64-instruction limit in fcache and had to switch to either cogcpp or full assembly... and full assembly was not appealing!
  • Just an update, adding that symbols file as @ersmith suggested did the trick. Thanks. PropWare's develop branch is now has one less bug in it :)

    Time to see how many more I can add.
Sign In or Register to comment.