There are commands to list all functions in the program in gdb, but I did not find any untilities or gdb command/syntax to just list symbols in a particular shared library. nm doe s not work on arm7 shared lib. Any idea how to do it?
nm works fine on shared libraries... as long as they aren't stripped. If the library you're attempting to look at is stripped, neither nm nor gdb will show function names. If you're just interested in the Objective-C bits, class-dump-z is a good option. (you can get the same information from otool but it's less pretty)
Related
I am trying to get LLVM IR for a file which is linked with some static libararies.
I tried to link using llvm-link . It just copy the .bc files in one file ( not like native linking).
clang -L$(T_LIB_PATH) -lpthread -emit-llvm gives an error: emit-llvm can not be used with linking. When passing -c option, it gives warning that the linking options were not used.
My main goal is to get .bc file with all resolved symbols and references. How can I achieve that with clang version 3.4.?
You may have a look at wllvm. It is a wrapper on the compiler, which enable to build a project and extract the LLVM bitcode of the whole program.
You need to use wllvm and wllvm++ for C and C++, respectively (after setting some environment variables).
Some symbols come from source code via LLVM IR. IR is short for intermediate representation. Those symbols are easy to handle, just stop in the middle of the build process.
Some others come from a library and probably were generated by some other compiler, one that never makes any IR, and in any case the compiler was run by some other people at some other location. You can't go back in time and make those people build IR for you, even if their compiler has the right options. All you can do is obtain the source code for the libraries and build your entire application from source.
I am working on an iOS app which links several static libraries. The challenge is, those linked libraries define same method names with different implementations. Oddly, I don't get any duplicate symbol definition errors; but, to no surprise, I end up with access to only one implementation of the method.
To be more clear, say I have libA and libB and they both define a global C method called func1()
When I link both libA and libB, and make a call to func1(), it resolves to either libA's or libB's implementation without any compilation warning. I, however, need to be able to access both libA's func1() and libB's func1() separately.
There's a similar SO post that explains how it can be done in C (via symbol renaming) but unfortunately, as I found out, objcopy tool doesn't work for ARM architecture (hence iPhone).
(I will submit it to the App Store, hence, dynamic linking is not an option)
It appears that you are in luck - you can still rename symbols with the ARM binary format, it's just a bit more hacky than the objcopy method...
NOTE: This has only been tested minimally, and I would strongly advise you to make a backup of all libraries in question before trying this!
Also note that this only works for files not compiled with the C++ compiler! This will fail if the C++ compiler was used on these files.
First, you will need a decent hex editor, for this example, I will be using Hex Fiend.
Next, you will open up a copy of your of of your libraries, let's call it lib1-renamed.a, and do the following with it:
Find the name of the symbol you wish to re-name. It can be found using the nm tool, or, if you know the header name, you should be set.
Next, you will use hex fiend, and to a textual replace of the old name (in this case foo), and give it a new name (in this case, bar). These names must have the same length, or it will corrupt the binary's offsets!
Note: if there is more than one function that contain's foo's name in it, you may have problems.
Now, you must edit the headers of the library you changed, to use the new function name (bar) instead of the old one.
If you have done the three simple† steps above properly, you should now be able to compile & link the two files successfully, and call both implementations.
If you are trying to do this with a universal binary (e.g. one the works on the simulator as well), you'd be best off using lipo to separate the two binaries, using objcopy on the i386/x64 binary, and then using my method on the ARM binary, and lipo it back together.
†: Simplicity is not guaranteed, nor is it covered by the Richard J. Ross III super warranty. For more information about the super warranty, call 1-800-FREE-WARRANTY now. That's 1-800-FREE-WARRANTY now!
Looking at the manuals, objdump and nm have overlapping features.
When would you use each one? What was the original purpose of each command?
They have no similar parameters.
nm lists file symbols, while objdump can show a lot of different information about files. objdump can shows symbols too, and it is explicitly noted in the manpage that "This is similar to the information provided by the nm program, although the display format is different."
It seems like nm is posix, so available in non-gnu platforms.
http://pubs.opengroup.org/onlinepubs/000095399/utilities/nm.html
I see for example that OSX doesn't come by default with objdump, but provides "otool" , which offers some of the same features "objdump" offers on linux.
So I guess you would use nm if really all you want is look at symbol tables or similar tasks, and you care about portability of your script. For some other tasks, such as looking into the debug info of a file, objdump might be more appropriate.
Has anyone used Bluetooth on Mac OS X with Lazarus or FreePascal? There is a bluetooth unit, but it currently only supports Linux.
Information about existing unit:
http://wiki.freepascal.org/Bluetooth
I plan to enhance this to support Mac OS, but it would be nice to know if anyone has written any code to use BlueTooth on Mac OS already to avoid duplicated work.
On the other hand, if you have used XCode to access Bluetooth, what libraries did you use? I am sure I can discover this with the XCode profiler by opening some Bluetooth applications.
Note: Mac OS X doesn't appear to use the BlueZ library that Linux has, so I don't think the solution is as easy as changing the library path. Instead, it has IOBluetooth "Framework", located at /System/Library/Frameworks/IOBluetooth.framework.
Having a look, it looks like:
kaikei.ocn.ntt.com:IOBluetooth.framework $ file *
CodeResources: XML document text
Headers: directory
IOBluetooth: Mach-O universal binary with 3 architectures
IOBluetooth (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
IOBluetooth (for architecture i386): Mach-O dynamically linked shared library i386
IOBluetooth (for architecture ppc7400): Mach-O dynamically linked shared library ppc
Resources: directory
Versions: directory
On the other hand, I think if anyone had done this already, I would probably be able to find it on Google.... On the off chance I am wrong, please reply and let me know.
Clarification: I have created bindings for normal shared libraries before (f.e. sqlite3), but not for a "framework". If nobody has created bindings or otherwise used the MacOS Bluetooth framework from FreePascal, advice on how to use framework functions from FreePascal in general woule be appreciated. (And normally the functions I am porting are C based, not Obj-C, so I am not sure how to declare Obj-C methods in FPK, although I am sure I will be able to find some samples if I keep searching).
The main svn repository for translated Mac OS X framework C headers is http://svn.freepascal.org/svn/macosxintf/trunk
From time to time, FPC releases are synchronised with the latest versions hosted there. Note that the files in that repository (in the MPPInterfaces subdirectory) are in a generic format that can be automatically translated into either FPC, GPC or CodeWarrior Pascal versions.
To generate the FPC versions, use "make fpcpinterfaces", and find the results in the Build/FPCPinterfaces folder.
To translate new headers, execute something like this from inside a checked out copy of the macosxintf repository:
./Scripts/Convert.pl /System/Library/Frameworks/IOBluetooth.framework/Headers/IOBluetooth.h FORCE MPPInterfaces
Afterwards, you'll still have to edit the resulting file to add/remove units and clean up some other things not handled by the automatic translation process. Once finished, you may want to submit a bug report at bugs.freepascal.org with the finished units.
(note: because I'm unregistered, I can only add in one url per post, so the next url's are a bit mangled to get around that restriction)
You can also subscribe to the Mac Pascal list (lists.sonic.net/mailman/listinfo/mac-pascal) and ask there whether someone already translated those headers.
The Bluetooth framework indeed also contains some Objective-C headers. Objective-Pascal support is only available in the latest FPC svn versions, as described on the FPC wiki (google FPC_PasCocoa). You need this support in order to interface with Objective-C.
Translating Objective-C is probably easiest using the script elsewhere in FPC's svn (svn.freepascal.org/svn/fpc/trunk/packages/cocoaint/utils/)
You may want to ask for help on the above-mentioned Mac Pascal list, as all people maintaining the aforementioned translations and translation tools are subscribed there.
I'm compiling library for a private project, which depends on a number of libraries. Specifically one of the dependencies is compiled with Fortran. On some instances, I've seen the dependency compiled with g77, on others I've seen it compiled with gfortran. My project then is ./configure'd to link with either -lg2c or -lgfortran, but so far I've been doing it by hand.
If it is possible, how can I find out, from looking into the dependent library (via e.g. nm or some other utility?), whether the used compiler was g77 (and then I'll use -lg2c in my link options) or gfortran (and then I'll use -lgfortran)?
Thanks in advance!
nm filename | fgrep ' __g77'
will give results if g77 was used, meanwhile
nm filename | fgrep '##GFORTRAN'
will give results if gfortran is used.
You need to grep for something, in the output of nm filename, that indicates whether g77 or gfortran was used. In most cases, if the library does at least input-output in one place, it will call libg2c or libgfortran and you will notice a symbol with g77 in it, or gfortran. So, your best bet is to use grep:
nm filename | grep _g77_
nm filename | grep _gfortran_
Two notes:
Grepping for ##GFORTRAN as geocar suggested is not reliable: it will only work on platforms where library-versioning is supported, which includes e.g. linux but not Windows or Mac OS.
It is still possible that some compiled code calls absolutely no support library function (if all it does is simple arithmetic and has not input-output, e.g.). In that case, unless it's compiled with debugging options, it's impossible to tell which compiler output it.
You might be able to figure it out by using nm, and seeing if the compiled code uses functions from one or the other, but that's quite a hack. You may be able to figure it out based on which library is available (if there's no libg2c available, then it wasn't g77, for example), but then you still have some ambiguity if both are available. If you can build the dependency yourself, then you can use have one part of your build process tell another part somehow (variable, file, etc.) which one you used.