> > > > > > "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? 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.
