* -static-libgcc, static libstdc++.a, dynamically loaded so files and exception handling.
@ 2011-01-15 19:12 Bob Rossi
2011-01-16 4:09 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Bob Rossi @ 2011-01-15 19:12 UTC (permalink / raw)
To: gcc-help
Hi,
I've got a main C++ executable that I am linking with
-static-libgcc and libstdc++.a. This works fine.
I'm doing this to make linux distribution easier.
I've also got a C shared object library which I load from the
main executable. The C shared object library, has function pointers
which get registered in it from the main executable. So this happens,
- the main executable loads the shared object
- the main executable sets function pointers in the shared object
- the main executable calls a function in the loaded shared object file
- the shared object file calls a function pointer getting back into
the main executable
- an exception is thrown from the main executable (nested in the call
stack of the shared object)
- the exception propogates through the shared object interface and
is caught in the main executable again.
Is this use of -static-libgcc, libstdc++.a, shared objects and
exceptions safe in all known configurations?
I'm worried about this text from the gcc documentation related
to the static-ligcc option,
There are several situations in which an application should use
the shared libgcc instead of the static version. The most common
of these is when the application wishes to throw and catch
exceptions across different shared libraries. In that case, each
of the libraries as well as the application itself should use the
shared libgcc.
although, I don't think what I'm doing is related to what this text
is discussing.
Thanks,
Bob
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: -static-libgcc, static libstdc++.a, dynamically loaded so files and exception handling.
2011-01-15 19:12 -static-libgcc, static libstdc++.a, dynamically loaded so files and exception handling Bob Rossi
@ 2011-01-16 4:09 ` Ian Lance Taylor
2011-01-16 13:05 ` Bob Rossi
0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2011-01-16 4:09 UTC (permalink / raw)
To: Bob Rossi; +Cc: gcc-help
Bob Rossi <bob@brasko.net> writes:
> I've got a main C++ executable that I am linking with
> -static-libgcc and libstdc++.a. This works fine.
> I'm doing this to make linux distribution easier.
>
> I've also got a C shared object library which I load from the
> main executable. The C shared object library, has function pointers
> which get registered in it from the main executable. So this happens,
> - the main executable loads the shared object
> - the main executable sets function pointers in the shared object
> - the main executable calls a function in the loaded shared object file
> - the shared object file calls a function pointer getting back into
> the main executable
> - an exception is thrown from the main executable (nested in the call
> stack of the shared object)
> - the exception propogates through the shared object interface and
> is caught in the main executable again.
>
> Is this use of -static-libgcc, libstdc++.a, shared objects and
> exceptions safe in all known configurations?
>
> I'm worried about this text from the gcc documentation related
> to the static-ligcc option,
> There are several situations in which an application should use
> the shared libgcc instead of the static version. The most common
> of these is when the application wishes to throw and catch
> exceptions across different shared libraries. In that case, each
> of the libraries as well as the application itself should use the
> shared libgcc.
> although, I don't think what I'm doing is related to what this text
> is discussing.
What you describe is not safe in all known configurations. There are
configurations where the unwind library invoked to throw the exception
will not be able to find the unwind information defined by the shared
library, which means that it will not be able to reliably unwind through
the functions in the shared library, and, in particular, will not be
able to run destructors for local variables defined in functions in the
shared library.
However, what you describe is safe on current versions of GNU/Linux. It
is safe if 1) your linker supports the --eh-frame-hdr option (binutils
2.12 ; 2) your glibc provides the dl_iterate_phdr option; 3) your gcc
was configured to be aware of both these facts. These facts have been
true for at least five years on GNU/Linux systems.
What is the range of configurations you have to consider?
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: -static-libgcc, static libstdc++.a, dynamically loaded so files and exception handling.
2011-01-16 4:09 ` Ian Lance Taylor
@ 2011-01-16 13:05 ` Bob Rossi
2011-01-17 23:10 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Bob Rossi @ 2011-01-16 13:05 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
On Sat, Jan 15, 2011 at 08:09:16PM -0800, Ian Lance Taylor wrote:
> Bob Rossi <bob@brasko.net> writes:
>
> > I've got a main C++ executable that I am linking with
> > -static-libgcc and libstdc++.a. This works fine.
> > I'm doing this to make linux distribution easier.
> >
> > I've also got a C shared object library which I load from the
> > main executable. The C shared object library, has function pointers
> > which get registered in it from the main executable. So this happens,
> > - the main executable loads the shared object
> > - the main executable sets function pointers in the shared object
> > - the main executable calls a function in the loaded shared object file
> > - the shared object file calls a function pointer getting back into
> > the main executable
> > - an exception is thrown from the main executable (nested in the call
> > stack of the shared object)
> > - the exception propogates through the shared object interface and
> > is caught in the main executable again.
> >
> > Is this use of -static-libgcc, libstdc++.a, shared objects and
> > exceptions safe in all known configurations?
> >
> > I'm worried about this text from the gcc documentation related
> > to the static-ligcc option,
> > There are several situations in which an application should use
> > the shared libgcc instead of the static version. The most common
> > of these is when the application wishes to throw and catch
> > exceptions across different shared libraries. In that case, each
> > of the libraries as well as the application itself should use the
> > shared libgcc.
> > although, I don't think what I'm doing is related to what this text
> > is discussing.
Thanks for this answer.
> What you describe is not safe in all known configurations. There are
> configurations where the unwind library invoked to throw the exception
> will not be able to find the unwind information defined by the shared
> library, which means that it will not be able to reliably unwind through
> the functions in the shared library, and, in particular, will not be
> able to run destructors for local variables defined in functions in the
> shared library.
I'm assumming that you understood that the shared libraries are pure C,
with no C++ in them at all. (There won't be any destructors for local
variables defined in the shared library since it's pure C.) Only the
main executable with throw and catch exceptions.
> However, what you describe is safe on current versions of GNU/Linux. It
> is safe if 1) your linker supports the --eh-frame-hdr option (binutils
> 2.12 ; 2) your glibc provides the dl_iterate_phdr option; 3) your gcc
> was configured to be aware of both these facts. These facts have been
> true for at least five years on GNU/Linux systems.
>
> What is the range of configurations you have to consider?
Well, essentially any configuration that someone asks to run the
software on.
Regarding points 1, 2, and 3. Do those have to be true at link time
(when i'm building the executable on the machines I control)
or at load time (when the user goes to run the executable on the
machines they control)?
Thanks,
Bob
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: -static-libgcc, static libstdc++.a, dynamically loaded so files and exception handling.
2011-01-16 13:05 ` Bob Rossi
@ 2011-01-17 23:10 ` Ian Lance Taylor
2011-01-18 0:23 ` Bob Rossi
0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2011-01-17 23:10 UTC (permalink / raw)
To: Bob Rossi; +Cc: gcc-help
Bob Rossi <bob@brasko.net> writes:
> On Sat, Jan 15, 2011 at 08:09:16PM -0800, Ian Lance Taylor wrote:
>
>> What you describe is not safe in all known configurations. There are
>> configurations where the unwind library invoked to throw the exception
>> will not be able to find the unwind information defined by the shared
>> library, which means that it will not be able to reliably unwind through
>> the functions in the shared library, and, in particular, will not be
>> able to run destructors for local variables defined in functions in the
>> shared library.
>
> I'm assumming that you understood that the shared libraries are pure C,
> with no C++ in them at all. (There won't be any destructors for local
> variables defined in the shared library since it's pure C.) Only the
> main executable with throw and catch exceptions.
There is a gcc extension that permits destructors for local variables in
C code, and the GNU/Linux pthread library uses it when available. Look
at pthread_cleanup_push in <pthread.h>.
Anyhow, whether you rely on that or not, the unwind library still needs
to find the unwind info just to unwind the stack reliably on x86_64.
>> However, what you describe is safe on current versions of GNU/Linux. It
>> is safe if 1) your linker supports the --eh-frame-hdr option (binutils
>> 2.12 ; 2) your glibc provides the dl_iterate_phdr option; 3) your gcc
>> was configured to be aware of both these facts. These facts have been
>> true for at least five years on GNU/Linux systems.
>>
>> What is the range of configurations you have to consider?
>
> Well, essentially any configuration that someone asks to run the
> software on.
>
> Regarding points 1, 2, and 3. Do those have to be true at link time
> (when i'm building the executable on the machines I control)
> or at load time (when the user goes to run the executable on the
> machines they control)?
Unless you are linking statically, the dl_iterate_phdr function has to
be available at runtime, in libc.so.6. Every other aspect is only
required at link time, on a machine you control. You are probably safe
enough on GNU/Linux in practice, the question you'll have to consider is
whether you have to run on non-GNU/Linux systems.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: -static-libgcc, static libstdc++.a, dynamically loaded so files and exception handling.
2011-01-17 23:10 ` Ian Lance Taylor
@ 2011-01-18 0:23 ` Bob Rossi
2011-01-18 1:19 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Bob Rossi @ 2011-01-18 0:23 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: gcc-help
On Mon, Jan 17, 2011 at 03:10:27PM -0800, Ian Lance Taylor wrote:
> Bob Rossi <bob@brasko.net> writes:
>
> > On Sat, Jan 15, 2011 at 08:09:16PM -0800, Ian Lance Taylor wrote:
> >> However, what you describe is safe on current versions of GNU/Linux. It
> >> is safe if 1) your linker supports the --eh-frame-hdr option (binutils
> >> 2.12 ; 2) your glibc provides the dl_iterate_phdr option; 3) your gcc
> >> was configured to be aware of both these facts. These facts have been
> >> true for at least five years on GNU/Linux systems.
> >>
> >> What is the range of configurations you have to consider?
> >
> > Well, essentially any configuration that someone asks to run the
> > software on.
> >
> > Regarding points 1, 2, and 3. Do those have to be true at link time
> > (when i'm building the executable on the machines I control)
> > or at load time (when the user goes to run the executable on the
> > machines they control)?
>
> Unless you are linking statically, the dl_iterate_phdr function has to
> be available at runtime, in libc.so.6. Every other aspect is only
> required at link time, on a machine you control. You are probably safe
> enough on GNU/Linux in practice, the question you'll have to consider is
> whether you have to run on non-GNU/Linux systems.
Thanks for the help so far!
So, we've described how static linking isn't always safe for libgcc. I've
also described how I have shared objectcs that I load at run time. These
libraries depend on libgcc as well. I build the software on an old linux
machine, with a new version of GCC. So I've got a relative new version
of libgcc. I'm thinking about distributing my libgcc_so using the linker
rpath solution, using ORIGIN to make it relative to the executable.
Does it make sense to distribute my newer version of libgcc with my
executables in this way?
Thanks,
Bob
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: -static-libgcc, static libstdc++.a, dynamically loaded so files and exception handling.
2011-01-18 0:23 ` Bob Rossi
@ 2011-01-18 1:19 ` Ian Lance Taylor
0 siblings, 0 replies; 6+ messages in thread
From: Ian Lance Taylor @ 2011-01-18 1:19 UTC (permalink / raw)
To: Bob Rossi; +Cc: gcc-help
Bob Rossi <bob@brasko.net> writes:
> So, we've described how static linking isn't always safe for libgcc. I've
> also described how I have shared objectcs that I load at run time. These
> libraries depend on libgcc as well. I build the software on an old linux
> machine, with a new version of GCC. So I've got a relative new version
> of libgcc. I'm thinking about distributing my libgcc_so using the linker
> rpath solution, using ORIGIN to make it relative to the executable.
>
> Does it make sense to distribute my newer version of libgcc with my
> executables in this way?
Yes.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-01-18 1:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-15 19:12 -static-libgcc, static libstdc++.a, dynamically loaded so files and exception handling Bob Rossi
2011-01-16 4:09 ` Ian Lance Taylor
2011-01-16 13:05 ` Bob Rossi
2011-01-17 23:10 ` Ian Lance Taylor
2011-01-18 0:23 ` Bob Rossi
2011-01-18 1:19 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).