Community
Participate
Working Groups
As you probably know CDT does not support 64-bit applications development. This is happening due to following problems 1. CDT handles addresses as Java long 2. CDT incorrectly handles C/C++ long type 3. CDT does not have ELF64 support in ELF binary parser I attached for your attention HTML document with our proposal of how CDT can be modified in a way consistent with current CDT design to accomplish 64-bit support. Intel is very interested in 64-bit support and ready to contribute in implementation. We will be able to provide shortly a prototype of this modification.
Created attachment 13194 [details] CDT modification proposal for 64-bit support
Created attachment 14567 [details] 64bit patch for CDT CORE 2.1 build I200409150300 This patch introduces concept of IAddress and its implementations (Addr32 and Addr64). It also adds support for ELF64 binary parser. This patch is done against CDT 2.1 buld I200409150300. The build is available at http://download.eclipse.org/tools/cdt/builds/2.1.0/I200409150300. To apply the patch do the following 1. Import org.eclipse.cdt.core plug-in CDT 2.1 build I200409150300 plug-in to your workspace with sources 2. Copy cdt64bit-core.patch file to your workspace directory 3. Change dir to your workspace directory 4. Apply patch using the following command patch -p1 < cdt64bit-core.patch 5. Refresh exported projects in Eclipse NOTE: The following plug-ins will not compile (or will not work) against new CDT CORE: org.eclipse.cdt.debug.core org.eclipse.cdt.debug.mi.core org.eclipse.cdt.debug.mi.ui org.eclipse.cdt.debug.ui
Created attachment 14570 [details] ALL-IN-ONE patch for 64-bit support This patch combines all 64bit patches provided in bug #74058, #74056 and #69908. You may have working copy of CDT which supports 64-bit development by applying this patch. This patch is done against CDT 2.1 buld I200409150300. The build is available at http://download.eclipse.org/tools/cdt/builds/2.1.0/I200409150300. To get working copy of modified plug-ins do the following 1. Import the following CDT 2.1 build I200409150300 plug-ins to your workspace with sources org.eclipse.cdt.core org.eclipse.cdt.debug.core org.eclipse.cdt.debug.mi.core org.eclipse.cdt.debug.mi.ui org.eclipse.cdt.debug.ui 2. Copy cdt64bit-all.patch file to your workspace directory 3. Change dir to your workspace directory 4. Apply patch using the following command patch -p1 < cdt64bit-all.patch 5. Refresh exported projects in Eclipse 6. Build & export plug-ins NOTE: you will also need to rebuild native libraries of org.eclipse.cdt.core.linux fragment.
Allright, before doing this, we fired an email to CDT to see the reactions of the partners. The patch introduced a lot breaking API changes. If the result is positive, it could be apply after a few minor changes... well not the jumbo patch, let start with the core. Artyom, I would suggest you use eclipse to make your patches and do it on the head stream in cvs. It would make things easier 8-)
Unfortunately I do not have direct connection to eclipse CVS. I am not able to get sources directly into Eclipse and produce patches inside Eclipse. Please let me know if this patch is not applicable for HEAD stream (a lot of rejects) I will fetch sources using CVS grab and publish new patch.
> Unfortunately I do not have direct connection to eclipse CVS. I am not able to > get sources directly into Eclipse and produce patches inside Eclipse. Unfortunate. > Please let me know if this patch is not applicable for HEAD stream (a lot of > rejects) I will fetch sources using CVS grab and publish new patch. Let's start with the core. Dave brought this point about the patch: The problem for the MI and the debug patch is , if you look at the MI plugin for example, it was designed with three source folders cdi/, mi/ and src/ It was done this way because we wanted to isolate the Eclipse specific parts so we could have an mi.jar that would be independent of Eclipse and be use elsewhere. IAddress is define in the core plugin, so we have now a dependency on the core Plugin. Could not the MI plugin use BigInteger instead ? Reassigning, let's see if we can ram this through before the weekend
Created attachment 14602 [details] 64bit patch for CDT CORE 2.1 HEAD I had a look into CVS and found that source directory structure is different than in CDT 2.1 build. So I decided to produce patch against today’s HEAD from CVS To apply the patch 1. Import org.eclipse.cdt.core plug-in from CVS to your workspace with sources 2. Apply patch using Team->Apply Patch context menu (Ignore path segments should be 2)
> I had a look into CVS and found that source directory structure is different > than in CDT 2.1 build. So I decided to produce patch against today’s > HEAD from CVS The core plugin patch apply. Minor points refactor of the factories in utils. The other plugins are dealt with in other PR's. Before flipping this to fix we probably want to make some JUnit tests Artyom are you familiar with JUnit ?
Created attachment 14640 [details] CDT 2.0 64-bit and 32-bit test results Before we rebased patch to 2.1 we tested it with CDT 2.0 and Eclipse 3.0. Please find results for linux ia64 (64-bit) and x86 (32-bit) in the attachment. We grabbed unit tests with CDT_2_0 tag and changed some debug tests that deal with debug session creation since API has changed. Issues found: 1. org.eclipse.cdt.debug.ui.tests : testIsEquals (ia64, x86)- A bug in the unit test. All breakpoints are deleted and new one is set. The number of breakpoint is tested to be 1 however the thread processing the command queue has not finished yet therefore the number of breakpoints is more than 1. The test should be corrected - a delay must be placed before checking the number of breakpoints. 2. org.eclipse.cdt.core.tests : testGetChildren (ia64) – binary parser issue. Need to be investigated since x86 exe is parsed on ia64 platform. Probably problem in test case. We also done manual integration tests i.e. performed real use case scenarios.
Now that I have started using this, I would like to propose a few modifications, they are; - change IAddress::distance(IAddress) - its not obvious from the method name what the distance is relative to, should it be distanceTo or distanceFrom. I like distanceTo... - add IAddress::add(long) - makes useage simpler (and optimal for Addr32) - add checks for correct instances type before casting in methods like distance and compareTo - Addr32 and Addr64 should override Object::equals(Object) and Object::hashCode(). Comments? PS . I can make these changes if no one has objections.
> - change IAddress::distance(IAddress) Agree > - add IAddress::add(long) - makes useage simpler (and optimal for Addr32) +/-, we should be carefull in CDT since it will allow developers to analize (store and manipulate) distances as long, may lead to a problem on 64-bit systems > - add checks for correct instances type before casting in methods like distance and compareTo Disagree, type cast exceptions will allow to find problems during development. If we do checks and return false silently the problem will be hard to debug > - Addr32 and Addr64 should override Object::equals(Object) and Object:: hashCode() Agree, but IAddress should not adopt equals(Object) and hashCode() methods
>> - add IAddress::add(long) - makes useage simpler (and optimal for Addr32) >+/-, we should be carefull in CDT since it will allow developers to analize >(store and manipulate) distances as long, may lead to a problem on 64-bit >systems I think its benfits outway this protental problem, since in it abbsence the developer will be forced to just call BigInteger.valueOf(long) when they have a long/int offset they want to add to the offset. >> - add checks for correct instances type before casting in methods like distance and compareTo >Disagree, type cast exceptions will allow to find problems during development. >If we do checks and return false silently the problem will be hard to debug But what the user has is an IAddress, I was thinking on still throwing an exception, something like IllegalArgumentException, or should we create our own exception for address type mismatches. >> - Addr32 and Addr64 should override Object::equals(Object) and Object::hashCode() >Agree, but IAddress should not adopt equals(Object) and hashCode() methods Correct, though I have seen many interfaces include equals(Object) as part if is definition, why not replace the interface definition of equals(IAddress) with equals(Object).
1. add(long) – OK. I agree to introduce this method. It may improve performance and I in real world offsets are always less than maximal address. Could you please also add a warning comment to this new method so developers pay attention to the fact that long offsets may not work for Addr64 in some scenarios. 2. compareTo(IAddress) and distanceTo(IAddress) – we can throw IllegalArgumentException here but extra instanceof check will slow down performance. 3. equals(Object) and hashCode() – I suggest simply remove equals(IAddress) from IAddress and replace all its references with compareTo(IAddress) == 0. These methods do the same thing. Moreover current behavior of equals() allows comparison of different address types. All objects in Java have equals(Object) and hashCode() methods so we can add them in Addr32 and Addr64.
All patches are in.
Please make a new PR for specific problems in the implementation. Thanks all.
