[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mingw-users] Re: libbfd, libtool & Win32
From: |
David Olofson |
Subject: |
Re: [Mingw-users] Re: libbfd, libtool & Win32 |
Date: |
Wed, 18 Sep 2002 11:08:43 +0200 |
On Tuesday 17 September 2002 20:33, Guido Draheim wrote:
[...]
> On another e-mail, you said to have some idea of the `objdump -p`
> output of an export table. If someone could work that out with a
> portable shell program (sh/sed/etc), then we can let that impgen.sh be
> created in the $builddir instead of an impgen.exe, and have it run
> through extract_expsyms_cmd. That would atleast fix our crosscompile
> problem.
That could work, but I'm not sure how much we can rely on the format of
that output. Either way, it generates *a lot* of data that we need to
throw away. Not a major issue, I guess, but it doesn't feel right...
> Still, I think that the correct solution is in the objdump
> itself, giving it another option to spit out the export table in .def
> style format.
Would that be "Win32 DLL .def format", or some GNU standard format?
(Seems like other platforms have different formats for their .def
files...)
Anyway, I looked into that yesterday.
Good news:
There is code in libbfd that can find and parse
the exports (".edata") section of a Win32 DLL.
Bad news:
objdump does this when you specify '-p':
static void
dump_bfd_private_header (abfd)
bfd *abfd;
{
bfd_print_private_bfd_data (abfd, stdout);
}
And yes, it's just as bad as it looks; the PE/pei implementation of
bfd_print_private_bfd_data() is just a big function that, among other
things, calls a static function that parses and prints out the export
table... That code cannot be reached in any other way through the libbfd
API. It's all or nothing, and it's all hardcoded.
Indeed, it seems that the export section is *not* really a symbol table,
which is why some DLLs can have symbols ('-syms'), while most DLLs don't.
(In fact, I think clean DLLs *shouldn't* have the kind of symbol table
that 'objdump -syms' would print.)
So, there appears to be no clean way of getting at this information by
hacking objdump. I might be missing something, but I've found no trace of
export table parsing anywhere else in the pei code of libbfd, so I have
to conclude that libbfd must be hacked as well.
I could do that, but I'd need guidelines from the binutils folks, as I
can't seem to figure out where such a feature should go, with respect to
the BFD API.
Another way would be to do what that private data printing function does,
but inside objdump (libbfd supports messing with raw section data...),
but to me at least, that makes throwing impgen into binutils look like a
good idea...
> Looking at that later thing I'd say that I could even
> live with a quickhack of a impgen.sh that works for most projects, and
> those projects with trickier stuff must upgrade their binutils to a
> recent version. How does that sound?
That could work. Dunno' about the reliability or portability of fitering
'objdump -p' output, but if it works for most people for now, it can at
least avoid strictly forcing every cross gcc'er to upgrade.
//David Olofson --- Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------------> http://www.linuxdj.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'
- Re: [Mingw-users] Re: libbfd, libtool & Win32, (continued)
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Earnie Boyd, 2002/09/16
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Guido Draheim, 2002/09/16
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Earnie Boyd, 2002/09/16
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Guido Draheim, 2002/09/16
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Earnie Boyd, 2002/09/16
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Guido Draheim, 2002/09/16
- Message not available
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Guido Draheim, 2002/09/16
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Max Bowsher, 2002/09/17
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/17
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Guido Draheim, 2002/09/17
- Re: [Mingw-users] Re: libbfd, libtool & Win32,
David Olofson <=
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Danny Smith, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Danny Smith, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Danny Smith, 2002/09/18
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/20
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Guido Draheim, 2002/09/20
- Re: [Mingw-users] Re: libbfd, libtool & Win32, Earnie Boyd, 2002/09/20
- Re: [Mingw-users] Re: libbfd, libtool & Win32, David Olofson, 2002/09/23