I found https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#RELOC-TYPE but that seems like it is from 2004 based on the copyright. Is there anything newer or is this still accurate information? I'm not sure if this is something that is keep backwards compatible.
You've found the ABIv1 spec. It's still used today for lots of 64-bit Big Endian work. You'd not expect it to change too quickly, being an ABI.
For 64-bit Little Endian, you want the ABIv2 specification. It's available from the OpenPower foundation at https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-power-architecture
Related
I'm sorry in advance if this question is not well expressed, I am trying to achieve something quite new to me and I am a little lost.
I am trying to include a Canon SDK inside an Objective-C wrapper, I understand from this paragraph that I needed to download the 64bit SDK:
There are a few steps that need to be taken in order to use EOSFramework in a project. First, ensure that you have downloaded the latest Canon EDSDK 64bit. EOSFramework currently relies on ARC which is only supported in 64bit. Therefore you must use the 64bit version of EDSDK. Also ensure that you have compiled or downloaded the latest version of EOSFramework as a .framework file.
Incidentally, after following instructions, the errors that I'm getting while building the frameworks are related to 64bit. Please see picture attached:
Can someone point out a way for me to figure this out?
I'm not sure if this won't bring a problem in the long run, but I found an answer in this post: _int64 does not name a type
Following this:
It looks like you you are trying to use MSVC specific __int64 type with GCC. That does not work, use long long instead.
Can someone point out a way for me to figure this out?
You need to track down the declaration of EdsUInt64 in the SDK you have downloaded and figure out why it is not being seen by the compiler when compiling the source you've shown.
Try right-clicking on EdsUInt32 (which the compiler was happy with) and jumping to its definition. Now look around, are the 64-bit types defined in the same place? Are they inside #if constructs? If so why are the conditions not true? Etc. Do some detective work.
You can also use TextWrangler/BBEdit, or other good editor, to do quick multi-file searches over all the SDK source to find the definitions.
If you don't find the definitions then you've got the wrong version of one of the SDKs, go back to Canon and get the right one.
The solution is very unlikely to be you needing to define the type yourself. The ARC comments in particular indicate you do have Mac specific source code, Canon compile it on a Mac, so it's unlikely to be a MS or Gnu specific issue failing on a Mac etc.
Good Hunting!
HTH
So I'm running Ubuntu 12.04 on a BeagleBone (ARM 700MHz processor), and I just discovered, to my great surprise, that Math.Pow() returns incorrect results on that platform (Mono build 2.10.8.1ubuntu2.1).
After some searching, I found this poster who indicates that this is a known issue. Almost casually. I'm a little shocked that a) the issue ever came up in the first place, and b) that there is no ETA on fixing what I view as a pretty fundamental bug in a core Math library.
Further searching only turned up a few hits, and nothing mentioning this on https://bugzilla.xamarin.com/ (I plan to submit a bug report).
So, admittedly without having gone into the source code yet (although I plan to), can anyone explain to me the difficulties of fixing this, or how it could have been introduced in the first place? I mean, the pow() function in math.h works as expected, so can't Math.Pow() just wrap that? What am I missing here?
I guess I feel like there is something about floating point operations that underlies this that I don't understand, so this is more than just a bug report, I'd like to know what the fundamental problem is, or if it's just a big overlooked problem.
EDIT:
This page summarizes the root of the problem nicely (porting status of armhf in debian):
http://wiki.debian.org/ArmHardFloatTodo
Punchline: Mono 2.10 is listed as not fixed for the armhf port, but that it's in progress for mono 3.0.
For some more detailed background on the problem:
http://lists.debian.org/debian-arm/2012/02/msg00000.html
But as a summary - armhf is not a properly supported ABI for Mono, the ARM port of which was made to the armel ABI. Meaning you end up with caller and callee disagreeing on where floating-point parameters are passed in function calls.
Very few things are "just change 2 lines of code", and those that are generally require substantial effort to track down which two lines are wrong, and what they should be doing instead.
I was looking at doxygene and I noticed that its output for objective-C is less than optimal, so I was looking at doxygene's internals(in which all syntax analyzers consolidated into a huge blob), and then I decided that it was going to take a lot of work just to figure out where to begin with that.
So I thought, ok let's start by creating a dictionary/tree from an objective-c source file which it seems Xcode does already(because symbols are search able). And it seems to use LLVM"clang" somehow. Does anyone know how I can invoke "clang" to return a structure of the symbols in a project/document?
Xcode doesn't directly use the "clang++" binary for this purpose. The clang++ binary is actually a very small wrapper around the Clang C++ libraries. Xcode uses libclang (a C wrapper around the C++ libraries) for its C++ parsing needs.
Thus, to get the information you want, you will need to use libclang. On this page are the slides and video of a presentation Doug Gregor (the main developer of Clang) gave at the 2010 dev meeting entitled "libclang: Thinking Beyond the Compiler".
Many people in the clang community have expressed interest in replacing Doxygen's parser with clang. So you are not alone. However, I believe it is not a small project.
Looking for some fast, simple and stable RPC library I stumbled upon MessagePack project which seems to be very good. It is also under active development.
If you used it in any way, could you please share your experience?
P.S. I think this question should be community wiki
Well, after some time I found that MessagePack is not well-documented (there was even non-working tutorial in Wiki for Java), there are like 7 outstanding bugs several months old without any replies. Code even is not JavaDoc'ed so that you can take and learn it quickly...
But it seems developer activity there is quite high despite of some outstanding pull requests from the community, that are several months old.
So, well, if GPL suits you, go for ICE. If not... don't know yet. Still looking.
I'm also looking into a fast, cross-platform, cross-language, non-GPL-licensed RPC library.
From looking at the C++ source of MessagePack it seems that it doesn't work on Win32 though, which is a requirement for myself.
Except for that that single item it is on top of my list of serialization/RPC libraries.
http://msgpack.org/ - Win32 missing
http://avro.apache.org/
http://thrift.apache.org/ - Win32 missing
http://bert-rpc.org/
http://www.xmlrpc.com/
http://json-rpc.org/ - GPL license
http://code.google.com/p/protobuf/ - RPC missing
Where can I find the source code for the Objective-C language? Is it open-source or is there an open-sourced implementation of it available?
It really depends on what you mean by Objective-C, there are compilers, runtimes and libraries for it.
http://opensource.apple.com/ Contains much of Apple's source code for OS X and iOS.
you can also see http://clang.llvm.org/ for a compiler.
GNUstep is an open source implementation of OpenStep (Cocoa).
I think you are asking for Cocoa - and this is not open source. All you have are the header and reverse engineering tools.
Looking around, I've found several copies of Objective-C's source code. Apple maintains it at http://opensource.apple.com/source/objc4/, which is up to date as of OS X 10.9.x Mavericks at version 551.1, but I have also found several repositories GitHub that are copies of this main repository which people have made at various points in time, so they may or may not be as up to date as Apple's main repository. These include the GitHub repositories "opensource-apple/objc4" at version 532.2; "bavarious/objc4," which is up to date at version 551.1; "macmade/OBJC4-437.1-Runtime," which obviously includes just the Objective-C runtime at version 437.1; "Apple-FOSS-Mirror/objc4" at version 532.2; "aosm," which is up to date at version 551.1; "robertvojta/objc4," which is up to date at version 551.1; "j4n0/objc4-532," which is obviously at version 532.0; and "chenniaoc/objc4-551.1," which is obviously up to date at version 551.1. Personally, it seems to me that robertvojta/objc4 is the best repository from which you could possibly fork code due to the fact that it's got every single release from Apple's Open Source website so far copied over to it.
There is no one source code. There would be as many different versions as there are compilers for the language. They would likely be written in a low-level language such as assembly or C, and be vastly complicated. For whichever compiler you are interested in, you will need to confirm that it is open-source, which I find unlikely. Even then, it may be difficult.