Extract static object from dynamic one

Extract static object from dynamic one

[Thomas Köppe]

Hello,

I've been wondering about a relatively simple question for which there 
seems to be no obvious answer - am I overlooking something?

Suppose I have a dynamic C library libfoo.so (or foo.dll) along with 
headers in foo.h. Is it possible to build from the binary a static 
library libfoo.a?

I'm thinking that this should be easy, since I know all the function 
signatures and entry points in the binary; is there some way (maybe with 
objcopy or objdump?) in which I can extract the binary code for a 
specific function?

Thank you very much,

Thomas K.

Re: Extract static object from dynamic one

[Tom Browder]

On Dec 3, 2007 5:21 PM, Thomas Köppe <t.koeppe@ed.ac.uk> wrote:
...
> Suppose I have a dynamic C library libfoo.so (or foo.dll) along with
> headers in foo.h. Is it possible to build from the binary a static
> library libfoo.a?

I believe GNU libtool can be used to do that.  Check out the docs at

http://www.gnu.org/software/libtool/manual.html

-Tom

Tom Browder
Niceville, Florida
USA

Re: Extract static object from dynamic one

[Brian Dessent]

Tom Browder wrote:
> 
> On Dec 3, 2007 5:21 PM, Thomas Köppe <t.koeppe@ed.ac.uk> wrote:
> ...
> > Suppose I have a dynamic C library libfoo.so (or foo.dll) along with
> > headers in foo.h. Is it possible to build from the binary a static
> > library libfoo.a?
> 
> I believe GNU libtool can be used to do that.  Check out the docs at

Libtool is useful for creating both shared and static at the same
(build) time, but it won't let you create a static library from an
already linked shared library.  There is no way to do that, as far as I
know.  You need to recompile from source.

Brian

Re: Extract static object from dynamic one

[Thomas Köppe]

Brian Dessent wrote:
 >
 > Tom Browder wrote:
 >
 >> On Dec 3, 2007 5:21 PM, Thomas Köppe <t.koeppe@ed.ac.uk> wrote:
 >>
 >>> [...]
 >>>
 >>> Suppose I have a dynamic C library libfoo.so (or foo.dll) along with
 >>> headers in foo.h. Is it possible to build from the binary a static
 >>> library libfoo.a?
 >>
 >> I believe GNU libtool can be used to do that.
 >> [...]
 >
 > Libtool is useful for creating both shared and static at the same
 > (build) time, but it won't let you create a static library from an
 > already linked shared library.  There is no way to do that, as far as I
 > know.  You need to recompile from source.
 >
 > Brian

I agree that libtool does not deal with binary files in that way; that's 
why I was thinking about something from binutils.

But is there a reason that it should be impossible in principle to 
reconstruct a statically linkable object from a shared library? After 
all, the code is there, I know the function signatures, and relocatable 
addresses can be resolved to fixed addresses at link time.

Is there an obstruction in principle (that some vital information is 
lost in the shared library), or is it simply that no such tool has been 
written?

Many thanks,

Thomas

Re: Extract static object from dynamic one

[Brian Dessent]

Thomas Köppe wrote:

> Is there an obstruction in principle (that some vital information is
> lost in the shared library), or is it simply that no such tool has been
> written?

It's not just a matter of extracting something.  You'd have to rewrite
all accesses through the GOT and PLT (for ELF) or indirections through
.idata (for PE) to be regular symbol references.  You'd have to undo
relocs and make them into regular labels.  With things like relaxation
this becomes extremely nontrivial.  In a sense this is going backwards,
like a disassembler, because a static library is just a collection of
unlinked .o files, whereas a shared library is fully linked.

Brian

Re: Extract static object from dynamic one

[Ian Lance Taylor]

Brian Dessent <brian@dessent.net> writes:

> Thomas Köppe wrote:
> 
> > Is there an obstruction in principle (that some vital information is
> > lost in the shared library), or is it simply that no such tool has been
> > written?
> 
> It's not just a matter of extracting something.  You'd have to rewrite
> all accesses through the GOT and PLT (for ELF) or indirections through
> .idata (for PE) to be regular symbol references.  You'd have to undo
> relocs and make them into regular labels.  With things like relaxation
> this becomes extremely nontrivial.  In a sense this is going backwards,
> like a disassembler, because a static library is just a collection of
> unlinked .o files, whereas a shared library is fully linked.

In particular, PC relative relocations between object files will be
lost in the .so, and there is no way to recreate them as would be
required in a .o.  So this conversion is not possible even in
principle.

Ian

Re: Extract static object from dynamic one

[Thomas Köppe]

Duft Markus wrote:
> 
> At least on windows some information that would have been included in
> a static library is processed and after that discarded by the linker.
> For example, in a release link of a DLL there are no more symbol
> names (except for those that are exported - and that only when not
> importing by ordinal numbers), so it would be impossible to come up
> again with the signature for a particular (internal) function.

Yes, from the DLL itself it wouldn't seem possible to recover the 
function signatures, but let's suppose you do have the header files for 
the library.

However, Brian's argument that the DLL is fully linked, whereas a static 
library is just a collection of unlinked objects, seems to be a quite 
fundamental reason why one can't recover individual objects.

I suppose it's similarly hard as "extracting" linkable objects from an 
executable.

Thanks for all your input!

Thomas

RE: Extract static object from dynamic one

[Duft Markus]

Hi!

At least on windows some information that would have been included in a static library is processed and after that discarded by the linker. For example, in a release link of a DLL there are no more symbol names (except for those that are exported - and that only when not importing by ordinal numbers), so it would be impossible to come up again with the signature for a particular (internal) function.

I believe ELF keeps symbol names somewhere, but i'm not sure. Anyway i don't think, that a shared library contains all information a static library has. (for example at least the names of the objects containing the various functions are discarded.)

Cheers, Markus

Thomas Köppe <> wrote:
> Brian Dessent wrote:
>  >
>  > Tom Browder wrote:
>  >
>  >> On Dec 3, 2007 5:21 PM, Thomas Köppe <t.koeppe@ed.ac.uk> wrote:
>  >>
>  >>> [...]
>  >>>
>  >>> Suppose I have a dynamic C library libfoo.so (or foo.dll) along
>  with >>> headers in foo.h. Is it possible to build from the binary a
>  static >>> library libfoo.a?
>  >>
>  >> I believe GNU libtool can be used to do that.
>  >> [...]
>  >
>  > Libtool is useful for creating both shared and static at the same
>  > (build) time, but it won't let you create a static library from an
>  > already linked shared library.  There is no way to do that, as far
>  as I > know.  You need to recompile from source.
>  >
>  > Brian
> 
> I agree that libtool does not deal with binary files in that way;
> that's why I was thinking about something from binutils.
> 
> But is there a reason that it should be impossible in principle to
> reconstruct a statically linkable object from a shared library? After
> all, the code is there, I know the function signatures, and
> relocatable addresses can be resolved to fixed addresses at link time.
> 
> Is there an obstruction in principle (that some vital information is
> lost in the shared library), or is it simply that no such tool has
> been written?
> 
> Many thanks,
> 
> Thomas


-- 
5. Dezember 2007
Salomon Automation am  Schweizer Forum für Logistik, Lausanne, CH




Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht für Zivilrechtssachen Graz