Re: performance of exception handling

> Just echoing what David said really, but: if the libgcc changes > are expected to be portable beyond glibc, then the existence of > an alternative option for glibc shouldn't block the libgcc changes. > The two approaches aren't be mutually exclusive and each approach > would achieve something tha

Re: performance of exception handling

Thomas Neumann via Gcc writes: >> 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 or

Re: performance of exception handling

> 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

Re: performance of exception handling

On Tue, May 12, 2020 at 8:14 AM Thomas Neumann via Gcc 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 > h

Re: performance of exception handling

> 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

Re: performance of exception handling

* David Edelsohn: > On Mon, May 11, 2020 at 10:52 AM Florian Weimer wrote: >> >> * David Edelsohn: >> >> > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc >> > wrote: >> > >> >> My current preferred solution is something that moves the entire code >> >> that locates the relevant FDE tabl

Re: performance of exception handling

On Mon, May 11, 2020 at 10:52 AM Florian Weimer wrote: > > * David Edelsohn: > > > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc > > wrote: > > > >> My current preferred solution is something that moves the entire code > >> that locates the relevant FDE table into glibc. This is all th

Re: performance of exception handling

* David Edelsohn: > On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc > wrote: > >> My current preferred solution is something that moves the entire code >> that locates the relevant FDE table into glibc. This is all the code in >> _Unwind_IteratePhdrCallback until the first read_encoded_v

Re: performance of exception handling

On Mon, May 11, 2020 at 6:47 AM Florian Weimer via Gcc wrote: > My current preferred solution is something that moves the entire code > that locates the relevant FDE table into glibc. This is all the code in > _Unwind_IteratePhdrCallback until the first read_encoded_value_with_base > call. And

Re: performance of exception handling

* Thomas Neumann: >> Link: >> >> I'm not sure if your summary is correct. > > I was referring to Section 3.2, where Herb says: > > "We must remove all technical reasons for a C++ project to disable > exception handling (e.g., by compiler switch) or ban use of exceptions,

Re: performance of exception handling

> Link: > > I'm not sure if your summary is correct. I was referring to Section 3.2, where Herb says: "We must remove all technical reasons for a C++ project to disable exception handling (e.g., by compiler switch) or ban use of exceptions, in all or part of their proje

Re: performance of exception handling

* Thomas Neumann via Gcc: > Currently, exception handling scales poorly due to global mutexes when > throwing. This can be seen with a small demo script here: > https://repl.it/repls/DeliriousPrivateProfiler > Using a thread count >1 is much slower than running single threaded. > This global locki