OK, so, to answer my own question, the Changelog says this about v0.9.25: "better (still limited) support for multiple TCCStates"
I guess the transition to a compiler that allows for multiple states is still a work in progress. Question: If I shove some of those globals into the TCCState struct, and make appropriate updates, how would I push my commits? Is the mob branch open to any commits? Would I issue a pull request? Thanks! David Fri, Mar 30, 2012 at 3:08 PM, David Mertens <[email protected]>wrote: > Milutin, all - > > Yes, you were absolutely correct. Once I recompiled tcc as a shared > library, the issue went away. That lesson has been learned. :-) > > However, my main question remains unanswered, and my suspicions have been > confirmed with new tests. To recap, here is my original question: > > > Is there a good reason symtab_section is a global variable? In addition to >> the issue that I encountered, what if I want to have multiple compiler >> states? It looks to me like the pointer for symtab_section will be >> overwritten for each call to the constructor. Won't this lead to trouble? >> And is there any reason we don't have a field in the TCCState struct to >> store the location of symtab_section? >> > > Whether or not this is the source, I have indeed encountered issues under > a few circumstances: > > 1) Using a single compiler state, compiling+relocating multiple times. > When I do this, I cannot call any functions from the first relocation after > the second relocation. > 2) Using two states, I cannot call any functions from the first state > after I have compiled+relocated the second state. Using the *first* state, > I *can* retrieve symbols from the compilation of the second state! > > So, it looks like there's a global variable for some sort of symbol table > machinations. > > Thoughts? > David > > > 2012/3/21 Milutin Jovanović <[email protected]> > >> >> It sounds to me that you are building two shared libraries, and each one >> links to a static version of tcc. If this is not the case then the rest of >> my mail will not make sense. >> >> If you are doing what I just described, then the ansewer is very simply: >> "Don't!" In such a setup, you will end up with two copies of code, two sets >> of global/static variables etc. The only way to bypass this is to use tcc >> as a shared library as well. This way all libraries that depend on tcc will >> use the same binary and same global/static variables. An added hazard with >> your setup is that down the road, your two libraries might be compiled with >> different versions of tcc, and then all hell will break lose, as the >> structs might not be the same. >> >> To clarify, linking with static libraries is not evil by itself, but you >> crossed the line when you attempted to share data between two of them. If >> you statically link with tcc, and no tcc data or variables are ever used >> outside your dynamic library, then you are safe, even if both so's >> statically link with tcc. >> >> Miki. >> >> >> On 21 March 2012 10:53, David Mertens <[email protected]> wrote: >> >>> Hello all - >>> >>> I ran into and then solved a very weird error in which the >>> symtab_section global variable is being set to some non-null value during >>> the constructor phase of my compiler state, but is null when I actually try >>> to add symbols! The reason is because the symbol addition occurred from a >>> different .so file as the constructor, and these apparently did not share >>> their global symtab_section global variable. >>> >>> Obviously, my understanding of dynamic linking is weak, but bear with >>> me, I have a sensible question: >>> >>> Is there a good reason symtab_section is a global variable? In addition >>> to the issue that I encountered, what if I want to have multiple compiler >>> states? It looks to me like the pointer for symtab_section will be >>> overwritten for each call to the constructor. Won't this lead to trouble? >>> And is there any reason we don't have a field in the TCCState struct to >>> store the location of symtab_section? >>> >>> Thanks! >>> David >>> >>> -- >>> "Debugging is twice as hard as writing the code in the first place. >>> Therefore, if you write the code as cleverly as possible, you are, >>> by definition, not smart enough to debug it." -- Brian Kernighan >>> >>> >>> _______________________________________________ >>> Tinycc-devel mailing list >>> [email protected] >>> https://lists.nongnu.org/mailman/listinfo/tinycc-devel >>> >>> >> >> _______________________________________________ >> Tinycc-devel mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/tinycc-devel >> >> > > > -- > "Debugging is twice as hard as writing the code in the first place. > Therefore, if you write the code as cleverly as possible, you are, > by definition, not smart enough to debug it." -- Brian Kernighan > > -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
