tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] symtab_section


From: Milutin Jovanović
Subject: Re: [Tinycc-devel] symtab_section
Date: Fri, 30 Mar 2012 23:45:28 -0400


Yes, the mob branch is open to all, and your improvements would be very welcome. On the same page where you had the instructions on how to get the source, the step 5 shows how to commit. Also if you search the list about a month back, I posted a short mail how to configure your git so you can push with a simple "git push".

Miki.


On 30 March 2012 19:03, David Mertens <address@hidden> wrote:
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 <address@hidden> 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ć <address@hidden>

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 <address@hidden> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



_______________________________________________
Tinycc-devel mailing list
address@hidden
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
address@hidden
https://lists.nongnu.org/mailman/listinfo/tinycc-devel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]