Re: [Mingw-users] Re: libbfd, libtool & Win32

[David Olofson]

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 -'