On Thu, Mar 21, 2019 at 1:38 PM Otto, Thomas <thomas.o...@pdv-fs.de> wrote: > > > > > > > > "ggc_collect() discarding/reusing remap_debug_filename() output, > > > > > > > thus producing invalid objects" > > > > > > > > > > > > Hmm, but AFAICS it can end up on the heap if plain get_src_pwd () > > > > > > result survives. I vaguely remember GC being happy with heap > > > > > > strings (due to identifiers?), but not sure. Otherwise the patch > > > > > > looks > > > > > > obvious enough. > > > > > > > > > > Good point, remap_filename can return the original filename pointer > > > > > (which can point to env["PWD"] or to an allocated string) or a ggc > > > > > string. > > > > > > > > > > Since not freeing the string pointed to by a static variable is ok (as > > > > > getpwd does it), what about checking if remap_filename just returns > > > > > the input filename ptr again, and if not copy the ggc string into an > > > > > allocated buffer. > > > > > > > > I think we always want GC allocated storage here since the whole > > > > dwarf2out > > > > data structures live in GC memory. That means unconditionally copying > > > > there > > > > as is done inside the DWARF2_DIR_SHOULD_END_WITH_SEPARATOR path. > > > > > > Explicitly requesting gc storage (A or B below) doesn't seem to work. The > > > mapped > > > wd string is not modified this time but is placed in a very different > > > part of the > > > assembly, in .section .debug_str.dwo, and after assembling it does not > > > even make it > > > into object, not even in a corrupted form as previously. > > > > With the cache variable moved to file scope and marked GTY(())? That > > sounds odd. > > Looking at the generated gt-dwarf2out.h shows that only global scope > variables can work > since these are referenced directly, thus a file scope GTY(()) marker results > in a compilation > error. > It was my impression that the ggc_alloc...() functions also notify the gc > mechanism > explicitly, but that does not seem to be the case as the attached data is > lost or at least > misplaced as well. > > The globally scoped static cache variable marked GTY(()) of course works - > but what > happens when a marked pointer gets assigned a non-gc pointer? > > > The point is that the garbage collector shouldn't end up at heap > > allocated storage when walking GC allocated data and I see the DWARF > > attribute > > eventually using the result of this function has the char * pointer GTY(()) > > marked. > > Does this answer my question above? "Shouldn't" as in the GC will ignore a > non gc heap > pointer and not touch it, or it shouldn't as in bad things happen when it > does?
I believe bad things may happen. But it seems that at least for strings we do know a mix of heap/GC allocation gracefully. > And I still think this function and the static variable which never changes > once set does not > require any GC. Just setting the cached_wd variable to the unchanged pointer > from > get_src_pwd() or allocating one in the function itself is enough. This solves > the problem > and relieves the GC from the task of watching over a variable which lives > forever anyhow. Yes, that works as well then. Richard.
