On Wed, 2018-02-07 at 19:26 -0500, Paul Smith wrote:
> Thanks for the conversation. I'm moving forward with a real global
> operator new/delete and working out the magic needed to ensure those
> symbols are not global in our shared library.
I remember one annoying thing I ran into: through compil
On Thu, 2018-02-08 at 01:17 +0100, Marc Glisse wrote:
> On Wed, 7 Feb 2018, Paul Smith wrote:
> > > > My question is, what do I need to do to ensure this behavior
> > > > persists if I create a global operator new/delete?
> > > >
> > > > Is it sufficient to ensure that the symbol for our shared
>
On Wed, 2018-02-07 at 16:38 -0700, Martin Sebor wrote:
> I'm not sure I see how defining operator new inline can work
> unless you recompile the world (i.e., all the DSOs used by
> the program, including libstdc++). As Marc already hinted,
> if libstdc++ dynamically allocates an object using the de
On Wed, 7 Feb 2018, Paul Smith wrote:
My question is, what do I need to do to ensure this behavior
persists if I create a global operator new/delete?
Is it sufficient to ensure that the symbol for our shared library
global new/delete symbols are hidden and not global, using a linker
map or -fvi
On 7 February 2018 at 23:38, Martin Sebor wrote:
> On 02/06/2018 03:56 PM, Paul Smith wrote:
>>
>> Hi all.
>>
>> Hopefully this isn't too annoying a question :).
>>
>> My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
>> systems. We use a separate heap management library (jemal
On 02/06/2018 03:56 PM, Paul Smith wrote:
Hi all.
Hopefully this isn't too annoying a question :).
My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
systems. We use a separate heap management library (jemalloc) rather
than the libc allocator. The way we did this in the pas
On Wed, 2018-02-07 at 11:32 +0100, Marc Glisse wrote:
> On Tue, 6 Feb 2018, Paul Smith wrote:
>
> > My environment has been using GCC 6.2 (locally compiled) on
> > GNU/Linux systems. We use a separate heap management library
> > (jemalloc) rather than the libc allocator. The way we did this in
>
On Tue, 6 Feb 2018, Paul Smith wrote:
My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
systems. We use a separate heap management library (jemalloc) rather
than the libc allocator. The way we did this in the past was to
declare operator new/delete (all forms) as inline fun
Hi all.
Hopefully this isn't too annoying a question :).
My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
systems. We use a separate heap management library (jemalloc) rather
than the libc allocator. The way we did this in the past was to
declare operator new/delete (all fo
ng. Assuming it
is GNU/Linux, then this is expected behaviour. Shared libraries on
GNU/Linux and other ELF systems act approximately like static
libraries. When two shared libraries define a symbol with the same
name, the first one encountered is used.
There are a number of ways to change this de
Hi,
I encounter a problem about several .so library linked by a
problem, when a library A executing call function which source at same
.so, but strangly it jump to another library B address with same
function name, then program crash.
Why library A don't find function name in itself address
> [ hmf. This one got lost to an smtp error when I sent it yesterday. It
> appears there's more or less agreement that at the moment you're supposed to
> manually annotate all external entry points if you want to use -fwhole-program
> on a library. On windows, where we often do that anyway, it l
[ hmf. This one got lost to an smtp error when I sent it yesterday. It
appears there's more or less agreement that at the moment you're supposed to
manually annotate all external entry points if you want to use -fwhole-program
on a library. On windows, where we often do that anyway, it looks lik
> On Mon, May 17, 2010 at 10:57:31AM -0700, Toon Moene wrote:
> > On 05/17/2010 08:08 PM, Dave Korn wrote:
> > >
> > > Hi!
> > >
> > >PR42904 is a bug where, when compiling a windows DLL using
> > > -fwhole-program,
> > > the compiler optimises away the entire library body, because there'
On Mon, May 17, 2010 at 10:57:31AM -0700, Toon Moene wrote:
> On 05/17/2010 08:08 PM, Dave Korn wrote:
> >
> > Hi!
> >
> >PR42904 is a bug where, when compiling a windows DLL using
> > -fwhole-program,
> > the compiler optimises away the entire library body, because there's no
> > depende
On 05/17/2010 08:08 PM, Dave Korn wrote:
Hi!
PR42904 is a bug where, when compiling a windows DLL using -fwhole-program,
the compiler optimises away the entire library body, because there's no
dependency chain related to 'main' to anchor it.
Aren't "shared library" and "whole program"
Hi!
PR42904 is a bug where, when compiling a windows DLL using -fwhole-program,
the compiler optimises away the entire library body, because there's no
dependency chain related to 'main' to anchor it.
It's pointed out that we could perhaps resolve this by inferring attribute
externally_v
Hello,
Is it possible to use -fprofile-generate on shared libraries,
which are loaded at runtime (dlopen'ed) by an executable not compiled
with profiling support?
The library loads and runs fine, but doesn't generate any profile output.
Thank you in advance, Clemens
I have a single threaded application that uses shared libraries. I
compile the app and the shared libraries with -pg. This gives me a
gmon.out when I run, however, gprof doesn't seem to print any of the
information from the shared libraries. Is there any way to get this
information in s
On Mon, 2008-12-15 at 11:37 +0100, Gerald Pfeifer wrote:
> Steve et al,
>
> I don't think I have seen a response to this, and it might be the same
> issue that was causing quite many testsuite failures on i386-unknown-freebsd
>
> If so, that would be GCC Bugzilla Bug 35114, "731 unexpected libgom
But the compiler also links in the shared version
> of libgomp.so because the IA64 HP-UX linker picks shared libraries over
> archive ones by default so it links in the shared libgomp.so.
>
> The libgomp.so library has a dependency on libgcc_s.so but it doesn't
> know wh
On Tue, Nov 4, 2008 at 12:56 PM, Steve Ellcey <[EMAIL PROTECTED]> wrote:
> To fix it in libtool I think we would have to stop using +nodefaultrpath
> when building shared libraries so that there is a search path to use in
> the shared libraries. This seems simple but I am not sur
am against the
archive version of libgcc so that the main program does not need the
shared libgcc_s.so. But the compiler also links in the shared version
of libgomp.so because the IA64 HP-UX linker picks shared libraries over
archive ones by default so it links in the shared libgomp.so.
The libgomp.
> is linked in statically.
>
> Since I used -Bsymbolic-functions, it has no effect on data symbols.
>
I extended -Bsymbolic-functions to libffi, libjava, libmudflap,
libssp and libgcc. There are no regressions:
http://gcc.gnu.org/ml/gcc-testresults/2007-01/msg00511.html
http://gcc.gnu.org/
On Fri, Jan 12, 2007 at 12:13:11PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Thu, Jan 11, 2007 at 07:33:21PM +0100, Paolo Bonzini wrote:
> > >
> > > >config/
> > > >
> > > >2007-01-10 H.J. Lu <[EMAIL PROTECTED]>
> > > >
> > > >* ld-symbolic.m4: New.
> > >
> > > Pleas
On Fri, Jan 12, 2007 at 08:57:42AM +0100, Paolo Bonzini wrote:
>
> >libjava will use -Bsymbolic on Linux, which is more aggresive than
> >-Bsymbol-functions. It will bind global data references locally in
> >additon to global function references. My patch will keep -Bsymbolic
> >for libjava if it
H. J. Lu writes:
> On Thu, Jan 11, 2007 at 07:33:21PM +0100, Paolo Bonzini wrote:
> >
> > >config/
> > >
> > >2007-01-10 H.J. Lu <[EMAIL PROTECTED]>
> > >
> > > * ld-symbolic.m4: New.
> >
> > Please name the macro AC_LIB_PROG_LD_GNU_SYMBOLIC, or
> > ACX_PROG_LD_GNU_SYMBOLIC.
> >
libjava will use -Bsymbolic on Linux, which is more aggresive than
-Bsymbol-functions. It will bind global data references locally in
additon to global function references. My patch will keep -Bsymbolic
for libjava if it is set by libjava/configure.host.
Here is an updated patch.
The configur
On Thu, Jan 11, 2007 at 07:33:21PM +0100, Paolo Bonzini wrote:
>
> >config/
> >
> >2007-01-10 H.J. Lu <[EMAIL PROTECTED]>
> >
> > * ld-symbolic.m4: New.
>
> Please name the macro AC_LIB_PROG_LD_GNU_SYMBOLIC, or
> ACX_PROG_LD_GNU_SYMBOLIC.
>
> >libgfortran/
> >
> >2007-01-10 H.J. Lu <[EM
config/
2007-01-10 H.J. Lu <[EMAIL PROTECTED]>
* ld-symbolic.m4: New.
Please name the macro AC_LIB_PROG_LD_GNU_SYMBOLIC, or
ACX_PROG_LD_GNU_SYMBOLIC.
libgfortran/
2007-01-10 H.J. Lu <[EMAIL PROTECTED]>
* aclocal.m4: Include ../config/lib-ld.m4 and
../config/
On Thu, Jan 11, 2007 at 09:03:42AM +0100, Paolo Bonzini wrote:
> H. J. Lu wrote:
> >On Wed, Jan 10, 2007 at 06:26:09AM -0700, Tom Tromey wrote:
> >>>"H.J." == H J Lu <[EMAIL PROTECTED]> writes:
> >>H.J.> With the new linker switches, -Bsymbolic-functions and
> >>H.J.> --dynamic-list-cpp-new, we
H. J. Lu wrote:
On Wed, Jan 10, 2007 at 06:26:09AM -0700, Tom Tromey wrote:
"H.J." == H J Lu <[EMAIL PROTECTED]> writes:
H.J.> With the new linker switches, -Bsymbolic-functions and
H.J.> --dynamic-list-cpp-new, we can improve shared library
H.J.> performance in gcc. This change will build libs
On Wed, Jan 10, 2007 at 06:26:09AM -0700, Tom Tromey wrote:
> > "H.J." == H J Lu <[EMAIL PROTECTED]> writes:
>
> H.J.> With the new linker switches, -Bsymbolic-functions and
> H.J.> --dynamic-list-cpp-new, we can improve shared library
> H.J.> performance in gcc. This change will build libstdc
> "H.J." == H J Lu <[EMAIL PROTECTED]> writes:
H.J.> With the new linker switches, -Bsymbolic-functions and
H.J.> --dynamic-list-cpp-new, we can improve shared library
H.J.> performance in gcc. This change will build libstdc++.so with
H.J.> -Bsymbolic-functions and --dynamic-list-cpp-new. I ca
On Wed, Jan 10, 2007 at 07:19:17AM -0800, Ian Lance Taylor wrote:
> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>
> > With the new linker switches, -Bsymbolic-functions and
> > --dynamic-list-cpp-new, we can improve shared library
> > performance in gcc. This change will build libstdc++.so with
> > -Bs
"H. J. Lu" <[EMAIL PROTECTED]> writes:
> With the new linker switches, -Bsymbolic-functions and
> --dynamic-list-cpp-new, we can improve shared library
> performance in gcc. This change will build libstdc++.so with
> -Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it
> to other libra
With the new linker switches, -Bsymbolic-functions and
--dynamic-list-cpp-new, we can improve shared library
performance in gcc. This change will build libstdc++.so with
-Bsymbolic-functions and --dynamic-list-cpp-new. I can expand it
to other libraries.
H.J.
--
--- gcc/libstdc++-v3/acinclude.m4.
On Thu, Dec 28, 2006 at 09:28:30AM -0800, Ian Lance Taylor wrote:
> I don't know the answer to your question. It may be that you need to
> run "gprof /path/to/lirary.so gmon.out". I'm not sure.
Gprof has roughly no support for shared libraries. Only addresses
bet
"Christian Sturz" <[EMAIL PROTECTED]> writes:
> I've a larger project that consists of several shared libraries.
> The compilation is done by autoconf and automake. One of the libraries
> seems to be slow so I would like to profile it. My idea was to use gprof
>
Hi,
I've a larger project that consists of several shared libraries.
The compilation is done by autoconf and automake. One of the libraries
seems to be slow so I would like to profile it. My idea was to use gprof
(I'm using gcc 3.4.6). First, I modified the Makefiles so that each librar
On Tue, Jun 27, 2006 at 03:48:30AM -0400, Paul Hilfinger wrote:
>
> I guess that I'm simply suggesting that it might be nice if the sort
> of modification suggested by Albert Chin's response to my question
> could be installed automatically under control of a configuration
> option (e.g.), or as a
t won't run without
special measures---seems rather bizarre. Remember that in case (a), we
expect the shared libraries to be present (in their non-standard locations)
at execution time.
I guess that I'm simply suggesting that it might be nice if the sort
of modification suggested by Al
> I don't think it's a good idea to compile in rpaths to non-standard
> (user-specific) directories by default.
Whether it should be the default is debatable and different people will
have different opinions.
Whether there should be an option to do that seems very useful and
desirable to me. That
* Paul Hilfinger:
> 2. Remember to include the appropriate -W,l-R option or whatever in
>and every compilation.
I don't think it's a good idea to compile in rpaths to non-standard
(user-specific) directories by default. This can lead to trapdoor
rpaths and generally makes the binaries less p
On Sun, Jun 25, 2006 at 07:47:52PM -0400, Paul Hilfinger wrote:
>
> I have a situation (on Linux or Solaris, at least), in which I
> install versions of GCC in non-standard directories (specifically,
> directories not owned & operated by root). With such an
> installation, when a GCC link finds a
I have a situation (on Linux or Solaris, at least), in which I install
versions of GCC in non-standard directories (specifically, directories not
owned & operated by root). With such an installation, when a GCC link
finds a definition of an external reference in a shared library that is
part of t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Dessent wrote:
>
> As far as I know, shared libstdc++ for mingw/cygwin has never worked,
> you always get static no matter what you do, regardless of
> --enable-shared or native/cross. I don't know if this is because of the
> archaic version of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Dessent wrote:
> Ranjit Mathew wrote:
>
>> I just noticed that even with "--disable-static --enable-static",
>
> Do you mean --disable-static --enable-shared?
Yes, sorry for the silly typo.
>> a Linux-to-MinGW cross compiler (mainline) sti
Ranjit Mathew wrote:
> I just noticed that even with "--disable-static --enable-static",
Do you mean --disable-static --enable-shared?
> a Linux-to-MinGW cross compiler (mainline) still created static
> libraries for the C++ and Java runtimes. Is this by design or is it
> a bug? From the point
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I just noticed that even with "--disable-static --enable-static",
a Linux-to-MinGW cross compiler (mainline) still created static
libraries for the C++ and Java runtimes. Is this by design or is it
a bug? From the point of view of creating execu
> Did the compiler give you a warning about inability to track the
> lifetime of "p"? It should have.
No. Not even with -Wall -O2.
gcc -v:
gcc (GCC) 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9)
> - FChE
>
Thanks,
Rafael
rafael.espindola wrote:
> [...]
> extern char *p;
> [...]
>char a = p[0];
> [...]
> compile and link with
> gcc -shared -fPIC a.c -o liba.so
> gcc -fmudflap -lmudflap b.c -la -L. -o b
Did the compiler give you a warning about inability to track the
lifetime of "p"? It should have.
- F
Using libmudflap to test a program that uses libxml2, I found that if
a program access a constant pointer in a non-instrumented library,
mudflap thinks that a read violation has occurred.
A simple test that illustrates this is:
a.c:
-
char *p = "abc";
-
On Tue, 2006-01-03 at 16:41 -0500, Daniel Jacobowitz wrote:
> DESTDIR support (which we already have, and people use constantly)
> allows us to install a tree somewhere different than its configured
> --prefix. Relocatable toolchains (ditto) allow the toolchain to work
> when run from an address d
On Tue, Jan 03, 2006 at 10:39:06PM +0100, Laurent GUERBY wrote:
> On Tue, 2006-01-03 at 16:01 -0500, Daniel Jacobowitz wrote:
> > On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote:
> > > On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote:
> > > > > Actually, looking more closely, t
On Tue, 2006-01-03 at 16:01 -0500, Daniel Jacobowitz wrote:
> On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote:
> > On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote:
> > > > Actually, looking more closely, the libiberty.a is the only one
> > > > installed
> > > > that way (from
On Tue, 2006-01-03 at 15:54 -0500, Richard Kenner wrote:
> Quick poll: who does configure for some system dir when doing
> development?
>
> I do. Doesn't mean I have to keep doing it that way, of course, but that's
> not what you asked.
I assume linux (and GCC) distributors also do it
On Tue, Jan 03, 2006 at 09:26:11PM +0100, Laurent GUERBY wrote:
> On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote:
> > > Actually, looking more closely, the libiberty.a is the only one installed
> > > that way (from the gcc sources). All others (for example libstdc++.a)
> > > seem
> > > to
Quick poll: who does configure for some system dir when doing
development?
I do. Doesn't mean I have to keep doing it that way, of course, but that's
not what you asked.
On Tue, 2006-01-03 at 20:47 +0100, Eric Botcazou wrote:
> > Actually, looking more closely, the libiberty.a is the only one installed
> > that way (from the gcc sources). All others (for example libstdc++.a) seem
> > to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9).
> > Hmmm...
> Actually, looking more closely, the libiberty.a is the only one installed
> that way (from the gcc sources). All others (for example libstdc++.a) seem
> to follow standard convention (32 bit in lib, 64 bit in lib/sparcv9).
> Hmmm... bug in gcc-4.0.2/libiberty/Makefile.in?
Bingo. :-) http://gcc
Quoting Eric Botcazou <[EMAIL PROTECTED]>:
I've noticed one inconsistency how libraries are installed. For shared
libraries (lib*.so), the 32-bit version is installed in prefix/lib, while
64-bit version is installed in prefix/lib/sparcv9.
For static libraries (lib*.a archives)
> I've noticed one inconsistency how libraries are installed. For shared
> libraries (lib*.so), the 32-bit version is installed in prefix/lib, while
> 64-bit version is installed in prefix/lib/sparcv9.
>
> For static libraries (lib*.a archives), it is the other way around.
I've just built gcc with sparc64 as build target (64-bit gcc binary that
generates 64-bit code by default, much like Linux amd64 does).
I've noticed one inconsistency how libraries are installed. For shared
libraries (lib*.so), the 32-bit version is installed in prefix/lib, while
64-b
This patch makes --with-gmp and --with-mpfr similar to --with-as and
others, where you don't need to have the as program in your PATH if
explicitly specified.
I now understood what you are looking for.
A good solution would be to use the macros AC_LIB_LINKFLAGS and friends,
which were first
>>> Testing done on i686-linux (built with --languages=c,fortran and
>>> a shared libgmp in /foo/bar, and regtested).
>>> OK for mainline? OK for 4.0?
ping**3, build machinery maintainers in Cc.
This patch makes --with-gmp and --with-mpfr similar to --with-as and
others, where you don't need to h
>> Basic testing done on i686-linux (built with --languages=c,fortran and
>> a shared libgmp in /foo/bar, and regtested). Extended testing (which
>> takes ages on my computer) in progress.
>>
>> OK for mainline? OK for 4.0?
>
> *ping*
>
> This patch has both a toplevel part and a part in gcc/, so I
> Or did I miss the point entirely?
Right now, having the GMP/MPFR libraries (later refered as GMP) in
/home/gmp and typing:
configure --with-gmp=/home/gmp --enable-languages=c,fortran
does configure fine but running "make" then fails when it attempts to
build libgfortran. This is PR 21547, see
This patch has both a toplevel part and a part in gcc/, so I don't
know exactly who can approve it.
I haven't really understood why you need this patch.
If you need to set the LD_LIBRARY_PATH manually after installation,
something is broken. If the GMPLIBSDIR is for example something in your
> Basic testing done on i686-linux (built with --languages=c,fortran and
> a shared libgmp in /foo/bar, and regtested). Extended testing (which
> takes ages on my computer) in progress.
>
> OK for mainline? OK for 4.0?
*ping*
This patch has both a toplevel part and a part in gcc/, so I don't
know
On 2005-11-04 19:26:14 +0200, Janne Blomqvist wrote:
> Would it be possible to replace gmp with mpfr entirely?
MPFR is based on GMP. It mainly uses the MPN and MPZ layers.
However the MPF layer isn't used at all. So, you still need
GMP somewhere anyway.
--
Vincent Lefèvre <[EMAIL PROTECTED]> - W
Quoting Janne Blomqvist <[EMAIL PROTECTED]>:
> Would it be possible to replace gmp with mpfr entirely? Or do we use
> gmp functionality that isn't found in mpfr?
We use mpz_* for our integer handling, so that's not an option, unfortunately.
- Tobi
On 2005-11-04 16:21:29 +0100, François-Xavier Coudert wrote:
> > The newest version of mpfr will build a shared library.
> > In fact, we should move to using the newest version,
> > but I think some/many people would object to having two
> > external library dependencies.
>
> What advantages have
On Fri, Nov 04, 2005 at 09:22:11AM -0800, Steve Kargl wrote:
> On Fri, Nov 04, 2005 at 04:21:29PM +0100, Fran?ois-Xavier Coudert wrote:
> > > The newest version of mpfr will build a shared library.
> > > In fact, we should move to using the newest version,
> > > but I think some/many people would o
On Fri, Nov 04, 2005 at 04:21:29PM +0100, Fran?ois-Xavier Coudert wrote:
> > The newest version of mpfr will build a shared library.
> > In fact, we should move to using the newest version,
> > but I think some/many people would object to having two
> > external library dependencies.
>
> What adva
> The newest version of mpfr will build a shared library.
> In fact, we should move to using the newest version,
> but I think some/many people would object to having two
> external library dependencies.
What advantages have the newest version? And (sorry for the obvious
question) why isn't it kep
On Fri, Nov 04, 2005 at 01:32:06PM +0100, Fran?ois-Xavier Coudert wrote:
> >> Here is a patch to fix PR libfortran/21547: when building with
> >> --with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
> >> $(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
> >> correctly when using the
>> Here is a patch to fix PR libfortran/21547: when building with
>> --with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
>> $(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
>> correctly when using the freshly built gfortran to build libgfortran.
>> The same thing happens for the g
On Fri, Nov 04, 2005 at 10:10:14AM +0100, FranXois-Xavier_Coudert wrote:
> Here is a patch to fix PR libfortran/21547: when building with
> --with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
> $(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
> correctly when using the freshly bui
Here is a patch to fix PR libfortran/21547: when building with
--with-gmp=/foo/bar and a shared libgmp in /foo/bar, the
$(RPATH_ENVVAR) variable (usually LD_LIBRARY_PATH) is not set
correctly when using the freshly built gfortran to build libgfortran.
The same thing happens for the gfortran testsui
* Softish soft | 2005-11-02 08:31:05 [+]:
>What I mean with shared library is that I build a library that somehow can
>dynamically be called over an ethernet cable.
That's a feature that you don't want! This implied many technics that
are not the tenor of gcc or another compiler!
Upper tech
On Nov 2, 2005, at 12:31 AM, Softish soft wrote:
I'm wondering if it's possible to build a shared library with GCC.
Yes, see the documentation. gcc-help is a more appropriate list for
all your questions.
Use google to read up on what a shared library is and how they work,
and all the oth
Hi!
I'm wondering if it's possible to build a shared library with GCC.
What I mean with shared library is that I build a library that somehow can
dynamically be called over an ethernet cable.
For example. I build my program and run it in one computer, when it needs a
specific library, it dyna
Andrew Haley writes:
> Jakub Jelinek writes:
>
> > > > While I still like using dl_iterate_phdr instead of
> > > > __register_frame_info_bases for totally aesthetic reasons, there
> > > > have been changes made to the dl_iterate_phdr interface since the
> > > > gcc support was writte
Jakub Jelinek writes:
> > > While I still like using dl_iterate_phdr instead of
> > > __register_frame_info_bases for totally aesthetic reasons, there
> > > have been changes made to the dl_iterate_phdr interface since the
> > > gcc support was written that would allow the dl_iterate_phdr
cation I'm working on, almost 40% of
> total CPU time is spent inside one function,
> _Unwind_IteratePhdrCallback(). This is for a few reasons: firstly,
> java uses stack traces for things other than throwing exceptions.
> Exceptions are relatively rare.
>
> Also, in a big serve
This is for a few reasons: firstly,
java uses stack traces for things other than throwing exceptions.
Exceptions are relatively rare.
Also, in a big server application you have a lot of shared libraries:
this one has 86. So, for every single stack frame we're doing many
excursions through _Unwi
On Tue, Feb 15, 2005 at 12:43:44PM -0500, Daniel Jacobowitz wrote:
> This may be exactly what you're suggesting, but could we do this
> instead of what we do now?
>
> - use dl_iterate_phdr to register and search any unregistered objects
Done naievely, this will fail with dlclose.
r~
On Tue, Feb 15, 2005 at 09:41:22AM -0800, Richard Henderson wrote:
> On Tue, Feb 15, 2005 at 05:27:15PM +, Andrew Haley wrote:
> > So, now for my question: why do we not call __register_frame_info() or
> > __register_frame_info_bases() ?
>
> Because in the normal case for C/C++, folks don't us
On Tue, Feb 15, 2005 at 05:27:15PM +, Andrew Haley wrote:
> So, now for my question: why do we not call __register_frame_info() or
> __register_frame_info_bases() ?
Because in the normal case for C/C++, folks don't use that many
exceptions. So delaying doing anything until it's needed is a w
This is about DWARF 2 unwinding through shared libraries.
As far as I can see, on current x86 GNU/Linux targets we don't call
__register_frame_info() or __register_frame_info_bases() from the
library startup code in crtbegin. There is code to do it, but it's
disabled.
When _Unwind_Fin
91 matches
Mail list logo
