On 12/11/2018 02:25 PM, Ian Lance Taylor wrote:
> On Tue, Dec 11, 2018 at 3:05 AM Pedro Alves wrote:
>> Ian earlier mentioned that we've wanted to avoid malloc because some
>> programs call the demangler from a signal handler, but it seems like
>> we already do, these functions already aren't
On Tue, Dec 11, 2018 at 3:05 AM Pedro Alves wrote:
>
> I noticed that the comment on top of __cxa_demangle says:
>
> "If OUTPUT_BUFFER is not long enough, it is expanded using realloc."
>
> and __cxa_demangle calls 'free'.
>
> And d_demangle, seemingly the workhorse for __cxa_demangle says:
>
>
On 12/11/2018 06:58 AM, Jakub Jelinek wrote:
> 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
On 12/11/2018 12:33 AM, Jeff Law wrote:
> Actually I would strongly suggest avoiding alloca completely. This
> isn't particularly performance sensitive code
On the contrary, the demangler is very performance-sensitive code for GDB.
See
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
> >>
On 12/10/18 8:34 AM, Jason Merrill wrote:
> On Mon, Dec 10, 2018 at 10:10 AM Jakub Jelinek wrote:
>> On Mon, Dec 10, 2018 at 02:52:39PM +, Michael Matz wrote:
>>> On Fri, 7 Dec 2018, H.J. Lu wrote:
>>>
>> On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote:
>>>
>>> Is the patch
On Mon, Dec 10, 2018 at 1:55 PM Jakub Jelinek wrote:
>
> On Mon, Dec 10, 2018 at 10:20:24AM -0800, Ian Lance Taylor wrote:
> > > I think it is a bad idea to use the same macro and value for both the
> > > recursion limit and essentially stack limit. For the latter, it should
> > > actually
On Mon, Dec 10, 2018 at 10:20:24AM -0800, Ian Lance Taylor wrote:
> > I think it is a bad idea to use the same macro and value for both the
> > recursion limit and essentially stack limit. For the latter, it should
> > actually compute expected stack size
> > (i.e. di.num_comps * sizeof
On Mon, Dec 10, 2018 at 7:35 AM Jakub Jelinek wrote:
>
> On Mon, Dec 10, 2018 at 03:26:18PM +, Nick Clifton wrote:
> > >> My current suggestion
> > >> is to raise the limit to 2048, which allows the libiberty patch to
> > >> pass. But do you have a feel for how much is a realistic limit ?
>
On Mon, Dec 10, 2018 at 03:26:18PM +, Nick Clifton wrote:
> >> My current suggestion
> >> is to raise the limit to 2048, which allows the libiberty patch to
> >> pass. But do you have a feel for how much is a realistic limit ?
> >
> > For recursion limit I think that is fine.
> > For just
On Mon, Dec 10, 2018 at 10:10 AM Jakub Jelinek wrote:
> On Mon, Dec 10, 2018 at 02:52:39PM +, Michael Matz wrote:
> > On Fri, 7 Dec 2018, H.J. Lu wrote:
> >
> > > > > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote:
> > > > > >
> > > > > > Is the patch OK with you ?
> > > > >
> > > >
> >
Hi David,
> Apologies in advance if this has been covered, as I've only been half-
> watching this thread, but is it always the case that the recursion
> depth can be bounded by some scalar multiple of the number of
> characters in the name?
Probably, but the point of this patch is to add a
Hi Jakub,
>> My current suggestion
>> is to raise the limit to 2048, which allows the libiberty patch to
>> pass. But do you have a feel for how much is a realistic limit ?
>
> For recursion limit I think that is fine.
> For just stack size limit, I think it is extremely small.
> I see that in
On Mon, 2018-12-10 at 14:52 +, Michael Matz wrote:
> Hi,
>
> On Fri, 7 Dec 2018, H.J. Lu wrote:
>
> > > > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton
> > > > wrote:
> > > > >
> > > > > Is the patch OK with you ?
> > >
> > > This caused:
> > >
> > >
On Mon, Dec 10, 2018 at 03:12:53PM +, Nick Clifton wrote:
> Hi Michael,
>
> > I think this points toward the limit being _much_ too low.
>
> Fair enough - several other people have said this as well. So
> I have proposed an alternative patch instead. My current suggestion
> is to raise the
Hi Michael,
> I think this points toward the limit being _much_ too low.
Fair enough - several other people have said this as well. So
I have proposed an alternative patch instead. My current suggestion
is to raise the limit to 2048, which allows the libiberty patch to
pass. But do you have
On Mon, Dec 10, 2018 at 02:52:39PM +, Michael Matz wrote:
> On Fri, 7 Dec 2018, H.J. Lu wrote:
>
> > > > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote:
> > > > >
> > > > > Is the patch OK with you ?
> > > >
> > >
> > > This caused:
> > >
> > >
Hi,
On Fri, 7 Dec 2018, H.J. Lu wrote:
> > > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote:
> > > >
> > > > Is the patch OK with you ?
> > >
> >
> > This caused:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
> >
>
> Here is the fix. OK for trunk?
I think this points
18 matches
Mail list logo
