Skip to content
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

Closed
vicuna opened this Issue Apr 23, 2010 · 7 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link
Collaborator

vicuna commented Apr 23, 2010

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

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 23, 2010

Comment author: mehdi

Forgot some notes:

  • the patch was made using svn revision 10300
  • modifications asked in #4701 are part of my patch
  • binutils-dev will be needed in order to build objinfo (it uses the bfd library to read cmxs files).
@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 28, 2010

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 28, 2010

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…

[1] http://git.debian.org/?p=pkg-ocaml-maint/packages/ocaml.git;a=blob;f=debian/ocamlbyteinfo/ocamlplugininfo.ml;h=e28800f317650a7f467a4cf224cff589b92da6fa;hb=HEAD

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 28, 2010

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 28, 2010

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.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 28, 2010

Comment author: mehdi

I forgot to #include config/s.h. That's fixed in the attached " 0001-Enhanced-objinfo-updated-2.patch".

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented May 19, 2010

Comment author: @xavierleroy

Patch merged in trunk, will go in 3.12.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.