New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make objinfo read all kind of objects #5033
Comments
Comment author: mehdi Forgot some notes:
|
Comment author: @xavierleroy Hello Mehdi, This sounds great! Thanks. I'll study the new objinfo pretty soon. One thing worries me, though: the dependency on the BFD library, which is far from standard on non-Linux systems. On MacOS X I'm not sure I can get it through MacPorts; I'm pretty sure it's not in Solaris; and don't get me started on Windows. At the very least, the presence of libbfd should be tested during configuration, and the parts of objinfo that use it should be stubbed out if it's missing. |
Comment author: mehdi You're right on the libfd issue. Actually, I forgot to study the portability problem, shame on me! The first verison that was able to read cmxs used a different technique: objdump was used to compute the necessary bits as you can see in [1]. I prefer using 'bfd' rather than relying on an external program. I think that 'objdump' (part of binutils) is available on MacOSX… According to its configure file, bfd builds for 'mingw32', 'cygwin' and 'solaris'. So, those systems seem to be supported by bfd's upstream. I'll do further investigations and try to come back with an enhanced patch wrt. portability. But, I need to find some voluteers to test on Windows, Solaris and MacOSX. |
Comment author: @xavierleroy Calling objdump isn't that much more portable than using libbfd. As to upstream support: yes, GNU binutils support an awful lot of platforms, but if they are not installed by default (as in the case under Windows, Solaris and to some extent MacOS) it is still a costly dependency to add. What I suggest is the following: assume that config/s.h has a #define for HAS_LIBBFD. Can you sprinkle some #ifdefs and try...with on your code so that it compiles and fails cleanly ("cannot display info on .cmxs files") if HAS_LIBBFD is undefined? Then, we'd be in very good shape. |
Comment author: mehdi I didn't claim that using objdump is more portable. But, it's available on (at least) MacOSX and it uses libbfd. So, there is a way to get libfd working there… I didn't invetigated further. Anyway, I attached an updated version of the patch. It takes into account HAS_LIBBFD and uses LIBBFD_CFLAGS in the Makefile for the link flags. |
Comment author: mehdi I forgot to #include config/s.h. That's fixed in the attached " 0001-Enhanced-objinfo-updated-2.patch". |
Comment author: @xavierleroy Patch merged in trunk, will go in 3.12.0. |
Original bug ID: 5033
Reporter: mehdi
Assigned to: @xavierleroy
Status: closed (set by @xavierleroy on 2013-08-31T10:48:47Z)
Resolution: fixed
Priority: normal
Severity: minor
Fixed in version: 3.12.0+dev
Category: ~DO NOT USE (was: OCaml general)
Has duplicate: #4276
Monitored by: @ygrek @glondu "Julien Signoles" "Richard Jones"
Bug description
For now, objinfo reads cmi, cmo and cma files ; dumpapprox reads cmx and cmxa files. Having only one tool to read all kind of OCaml objects would be nice. Furthermore, being able to read cmxs files and bytecode binaries is a useful feature to have.
The attached patch implements the features described above and makes objinfo use only one format to show objects informations. It also deletes dumpapprox, which won't be needed any longer.
Best regards,
Mehdi
File attachments
The text was updated successfully, but these errors were encountered: