From: David O. <dav...@re...> - 2002-09-18 09:09:10
|
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=20 that output. Either way, it generates *a lot* of data that we need to=20 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?=20 (Seems like other platforms have different formats for their .def=20 files...) Anyway, I looked into that yesterday. =09Good news: =09=09There is code in libbfd that can find and parse =09=09the exports (".edata") section of a Win32 DLL. =09Bad news: =09=09objdump does this when you specify '-p': =09=09=09static void =09=09=09dump_bfd_private_header (abfd) =09=09=09bfd *abfd; =09=09=09{ =09=09=09 bfd_print_private_bfd_data (abfd, stdout); =09=09=09} And yes, it's just as bad as it looks; the PE/pei implementation of=20 bfd_print_private_bfd_data() is just a big function that, among other=20 things, calls a static function that parses and prints out the export=20 table... That code cannot be reached in any other way through the libbfd=20 API. It's all or nothing, and it's all hardcoded. Indeed, it seems that the export section is *not* really a symbol table,=20 which is why some DLLs can have symbols ('-syms'), while most DLLs don't.= =20 (In fact, I think clean DLLs *shouldn't* have the kind of symbol table=20 that 'objdump -syms' would print.) So, there appears to be no clean way of getting at this information by=20 hacking objdump. I might be missing something, but I've found no trace of= =20 export table parsing anywhere else in the pei code of libbfd, so I have=20 to conclude that libbfd must be hacked as well. I could do that, but I'd need guidelines from the binutils folks, as I=20 can't seem to figure out where such a feature should go, with respect to=20 the BFD API. Another way would be to do what that private data printing function does,= =20 but inside objdump (libbfd supports messing with raw section data...),=20 but to me at least, that makes throwing impgen into binutils look like a=20 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=20 'objdump -p' output, but if it works for most people for now, it can at=20 least avoid strictly forcing every cross gcc'er to upgrade. //David Olofson --- Programmer, Reologica Instruments AB =2E- M A I A -------------------------------------------------. | Multimedia Application Integration Architecture | | A Free/Open Source Plugin API for Professional Multimedia | `----------------------------> http://www.linuxdj.com/maia -' =2E- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter | `-------------------------------------> http://olofson.net -' |