This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]


On Mon, Dec 10, 2018 at 05:33:19PM -0700, Jeff Law wrote:
> >> where di.num_comps is just strlen (mangled) * 2.  Without any analysis
> >> whatsoever, bumping the "recursion" limit will just mean we can process 1.5
> >> times long names.  Either we need more precise analysis on what we are
> >> looking for (how big arrays we'll need) or it needs to be an independent
> >> limit and certainly should allow say 10KB symbols too if they are
> >> reasonable.
> > 
> > If the problem is alloca, we could avoid using alloca if the size
> > passes a threshold.  Perhaps even use a better data structure than a
> > preallocated array based on a guess about the number of components...
> Actually I would strongly suggest avoiding alloca completely.  This
> isn't particularly performance sensitive code and alloca can be abused
> in all kinds of interesting ways.

We can't use malloc, therefore on some targets alloca (or VLAs) are the only
option, and for small sizes even if mmap is available using it is too

Though, I like Jason's suggestion of just adding a maxinum of the number
of components and number of substitutions and failing if we need more.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]