On Tue, May 12, 2020 at 8:14 AM Thomas Neumann via Gcc <gcc@gcc.gnu.org> wrote: > > > Not all GCC/G++ targets are GNU/Linux and use GLIBC. A duplicate > > implementation in GLIBC creates its own set of advantages and > > disadvantages. > > so what should I do now? Should I try to move the lookup into GLIBC? Or > handled it within libgcc, as I had originally proposed? Or give up due > to the inertia of a large, grown system? > > Another concern is memory consumption. I wanted to store the FDE entries > in a b-tree, which allows for fast lookup and low overhead > synchronization. Memory wise that is not really worse than what we have > today (the "linear" and "erratic" arrays). But the current code has a > fallback for when it is unable to allocate these arrays, falling back to > linear search. Is something like that required? It would make the code > much more complicated (but I got from Moritz mail that some people > really care about memory constrained situations).
Some people use exceptions to propagate "low memory" up which made me increase the size of the EH emergency pool (which is used when malloc cannot even allocate the EH data itself) ... So yes, people care. There absolutely has to be a path in unwinding that allocates no (as little as possible) memory. Richard. > Thomas
