Community
Participate
Working Groups
Build Identifier: When working with ISymbols, ISections and IExecutableSections it is useful to know various properties about them such as whether they are executable, allocatable and what their physical address is (in some circumstances the difference between this and the virtual address is important). Some of this information is determined by the membership of a smaller object such as ISymbol of a larger one such as IExecutableSection hence adding support for getting the containing section for a symbol and the containing ISection for a IExecutableSection is useful. It also allows access to the physical address which is only known for the ISection. Hence ISection needs to be made API so that it can be returned and various methods added. I have a patch which adds this functionality. Reproducible: Always
Created attachment 200787 [details] Patch to add this functionality. Relies on patch in bug 353577 but this dependency can be removed.
(In reply to comment #0) > When working with ISymbols, ISections and IExecutableSections it is useful to > know various properties about them such as whether they are executable, > allocatable and what their physical address is (in some circumstances the > difference between this and the virtual address is important). > Some of this information is determined by the membership of a smaller object > such as ISymbol of a larger one such as IExecutableSection hence adding support > for getting the containing section for a symbol and the containing ISection for > a IExecutableSection is useful. It also allows access to the physical address > which is only known for the ISection. > > Hence ISection needs to be made API so that it can be returned and various > methods added. having internally discussed this issue and the promotion of ISection from internal to API level interface within EDC, i am not opposed on principle. however ... the description of this issue mentions properties. note that ISection already has a getProperties() method interface. a more consistent, forward-looking approach would be to add a getProperties() function to IExecutableSection (preventing IExecutableSection implementations for other executable formats from having to implement methods that aren't germane, and also stabilizing the API). there's nothing preventing an implementation of IExecutableSection from holding a property list that contains an Object instanceof ISection with the key "CONTAINER", where another IExecutableSection implementation could simply wouldn't have to set this property, or any of the other attributes that are not pertinent. such an approach would also thus mean ISection wouldn't have to be promoted solely so it could be used as a return type in an API-level method interface.
Created attachment 201069 [details] Patch adding this functionality and using properties in IExecutableSection Still depends on 353577 but that should hopefully be committed soon. This patch still uses isExecutable, isData, isNotTextOrData methods in ISymbol but this is consistent with for example isThumb in ARMSymbol. If you think that ISymbol should use properties as well then I can produce a patch which does that.
(In reply to comment #3) > This patch still uses isExecutable, isData, isNotTextOrData methods in ISymbol > but this is consistent with for example isThumb in ARMSymbol. If you think that > ISymbol should use properties as well then I can produce a patch which does > that. yes, i can see from my original comment that i didn't specify that. i was thinking that it would be best to use a getProperties() method interface in ISymbol as well, for similar reasons.
Created attachment 201136 [details] Patch adding this functionality and using properties in IExecutableSection and ISymbol
using the latest patch (merged with other changes), this test is now failing the TestAddressInterval JUnit test for me. i can change the values in TestAddressInterval to make it work a little better, but i was wondering if you had separately updated TestAddressInterval after applying this patch?
Created attachment 201214 [details] Patch adding this functionality using properties and assuming IAddressInterval tests (In reply to comment #6) > I was wondering if you had separately updated TestAddressInterval after > applying this patch? Sorry yes. I am producing my patches against current EDC master and since EDC master doesn't have TestIAddressInterval yet my changes to it didn't have anywhere to go (though I should have noticed that). Attached is a patch which assumes that TestIAddressInterval exists and is in the place I expect it to be from my tree and submitted patch (though I think you have moved it in your tree but I can't see that to check).
(In reply to comment #7) > Attached is a patch which > assumes that TestIAddressInterval exists and is in the place I expect it to be > from my tree and submitted patch (though I think you have moved it in your tree > but I can't see that to check). thanks. this patch (with a minor tweak after making getHighAddress() a @Test, has been committed to our local repository.
Fixed in: http://git.eclipse.org/c/cdt/org.eclipse.cdt.edc.git/commit/?id=f7c4790c134d0cdc30cdbe8d2a016bf27cd25528
