Commit r1066661: "Make it possible to run kdevelop in gdb again"

[Andreas Pakulat]

On 29.12.09 01:26:12, David Nolden wrote:
> Am Dienstag 29 Dezember 2009 01:01:20 schrieb Andreas Pakulat:
> > On 28.12.09 20:57:08, David Nolden wrote:
> > > Am Montag 28 Dezember 2009 19:53:47 schrieb Andreas Pakulat:
> > > > But then I can try to debug problems with the session-specific duchain
> > > > directory.
> > > >
> > > > I'm starting to think that having the duchain in static code loaded
> > > > before everything else is the real problem here. If that wasn't the
> > > > case we wouldn't need this obscure env var and any extra process.
> > >
> > > That would also mean that one couldn't use "IndexedIdentifier",
> > > "IndexedString", and all such duchain types statically, which would be a
> > > significant limitation for such cosmetic reasons.
> > 
> > Can you explain in more detail what limitation that is? I still can't
> > see why we need all these things set up even before main() is entered,
> > there's no code using any of these classes until at least the Core is
> > created. So Core::initialize() should be early enough for the creation
> > and initialization of the DUChain no?
> 
> In the duchain library itself, in language-plugins, etc., there is many places 
> where such objects are used as global statics, for example 'IndexedIdentifier 
> globalImportIdentifier("import{....}");' or similar. When these objects are 
> initialized, the duchain must already be initialized as well.
> 
> And it is very convenient code-wise to do this, as else, all these places 
> would require explicit initialization in an "init()" like fashion, which is 
> ugly, as it requires additional code to do the initialization, instead of just 
> relying on the standard c++ initialization of global statics.

And to me global statics are very ugly, especially so since the order of
their initialization is completely undefined and varies from compiler to
compiler. I find a defined point in code where all initialization
happens a lot better, also for debugging purposes.
 
> Some of these objects have been turned into static functions, which partially 
> solves the problem, but sucks in its own right, because something as simple as 
> just reading out a simple integer is being turned into a function-call, which 
> may really hurt when used very frequently.
>
> Well, I guess in future we can review this at some point to see whether we can 
> find a compromise between code-convenience and a better controlled 
> initialization order, but right now I think it is not worth the hassle.

We really should, there are so many hacks in the code already its a
nightmare.
 
> Ah yeah, and about the debugging problem, we could also simply add a "--gdb" 
> option, that spawns a kdevelop instance with the correct environment variables 
> set in gdb.

Another thing that is lost with the forking (not sure wether in both
cases or only the detached-case) is information about core-dumps.
Usually one gets a "xyz (pid) crashed, core dumped" which lets me easily
load the right corefile into gdb. Now I first have to examine the
core-file directory to see which is the last coredump in there.

Andreas

-- 
Alimony and bribes will engage a large share of your wealth.