logs archiveBotHelp.net / Freenode / #43oh / 2015 / September / 10 / 1
if this RX C++ bug doesn't go anywhere soon I was just thinking I should whip out my tm4c1294 for some sweet lovin
maybe port abstractwiring over to it while I'm at it
never used a TM4C in the native CCS environment before
in the meantime I shot DJ Delorie an email notifying about the gcc bugzilla request, um, in case he didn't already see it :-)
lol got a quick reply, it's already in his inbox :-)
then again msp430-elf-g++ generates some odd code too
wonder if this is just something stupid I'm doing
yeah the same difference in ASM output occurs with msp430-elf-g++ and arm-none-eabi-g++
so one of my assumptions must be wrong here
yeah definitely... the -dP assembler output shows similar oddities there.
gonna just have to assume I'm screwing something else up here... or who knows maybe there is a unique bug in rx-elf that's not obvious here
Rickta59: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67529 ... you have any quick thoughts on this? Should you be able to, from another method in a class, be able to call an overridden method in that same class? I would think so...
or is this a wrong assumption based on the rules of C++ that I'm not taking into consideration
so virtual functions basically perform "late binding", where the actual resulting function isn't determined until runtime
k I guess that's weird but how the heck does the compiler find out which physical code to run...
ah, vtable
vtable is where it gets stored in msp430-elf-g++ anyhow
ok so rx-elf-g++ generates vtable info too
k now I'm confused even more..... wonder wtf was actually going on there
guess I'll need to inspect the gnurx output again to be sure
maybe it's not generating vtable code correctly
ok ... in windows now, looking at gnurx output, it looks like it just has to be a gnurx issue
vtable is missing from the rx-elf-objdump -C -DS output
no idea how it's getting initialized
explains a lot at least
k, don't know what the heck I'm missing here. gnurx isn't generating the vtable's for my classes
looks like from the .o files they show up as .rodata._ZTVblahblahblah sections, so .rodata.* should cover it...
yeah this is why i don't use virtual functions
as it generates vtables
which usually equals runtime sh*t
the vtable stuff is a level of indirection
useful if you are writing stuff on a real os and the interface can be used by a variety of different callers
that is why CRTP is kind of useful .. it is compile tim polymorphism vs runtime
do you have -fnortti .. or whatever that arg is ?
* goes back to watching late night and Elon Musk
the ctor is responsible for creating the vtable btw
so if you are doing some global objects .. maybe your linker is missing the init section?
or your startup code doesn't call the ctors on global objects?
try creating one of the objects on the stack * as in make it a function local object
you should then see it creating the vtable .. * probably just doing a data copy from memory to ram
Main provided by "main.cpp":
#include "my_template.h"
MyTemplate obj;
yeah so you are creating a global object ..
not having seen your start-up .s file .. i'm guessing it is missing the part where it walks the global ctor list and executes each function
PROVIDE (__init_array_end = .);
PROVIDE (__fini_array_start = .);
.. do you have code in your startup.s that walks the __init_array list?
it actually looks like Renesas puts the ctor code in a __main() function and then it's up to you to run it...
so that was missing
however even with that in main() it still didn't have vtable
so yeah mystery afoot
the ldscript does have the .init section
ok, e2studio does generate a .map file
and indeed the .rodata._ZTV* symbols are in the Discarded input sections
no idea why the hell it's discarding the .rodata._ZTV* symbols
the ldscript config is gui-ified in eclipse and what I can do is go to the .rodata section and click a "KEEP" feature in advanced
which wraps all the sections with KEEP()
that causes the vtable symbols to be included correctly
hackish, but those KPIT guys will have to figure out why -Wl,--gc-sections zealously trims the vtable's
__attribute__((used)) on the global object maybe?
you could also try not using -fdata-sections
and just globally optimize the functions, not the data
still a bug, why doesn't -fdata-sections fu*k it up on other compilers
i've used (void)someobject; to prevent something being thrown out .. often isr handlers
i've seen the compiler throw out stuff i want
ISR are especially vulnerable
I noticed energia's way of keeping them around
and used that in my code lol
kinda ugly
what does he do?
well, the file with isr's has a dummy usci_isr_dummy() function
that does nothing but gets called from main or something
yeah usually a reference in a method you know is going to be there works too
no code is generated but it lets the compiler know .. hey .. keep this
anyway, one of my biggest issues was definitely the fact that I wasn't running the __main() ctors function that C++ projects provide in the boilerplate main.cpp file
the __attribute__((used)) is a gcc thing
that is kind of nice actually
kinda scratching my head why that shouldn't be automatically run, but I guess those renesas guys don't trust C++ farther than they can throw it
as you can control when it gets run
well .. sometimes you want to turn on peripheral clocks before trying to do stuff
this is serious problem with the arduino style sh*t
indeed, guess I should know all about that :-)
they often are calling gpio setting things in ctors
« prev 1 2 3 next »