[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-dev] Toolchains in CDT
|
I'm going to take a step back an try and give some rationale for this. As well as providing a CDT-based product, we (at TimeSys) also provide gnu-based cross compilers (and other tools including binutils, gdb). All of the tools are packaged together as a "toolchain". The toolchain comes with an xml-based descriptor which describes the toolchain and what tools it provides. I think this is a fairly common model. So based on that we have the following goals for toolchain support.
1. A user should easily be able to specify they want to use one of our toolchains in a C-project.
2. Each time they need to specify a toolchain (managed make, binary parsing, debugging) it should use the same name, etc. so as not to be confusing.
3. CDT should be able to "discover" toolchains installed on the system at runtime. Either by reading descriptors or by having the user specify information through a UI (or a combination)
4. A toolchain vendor should not be required to have one extension for each toolchain they provide. The number of toolchains is variable (and are constantly being released).
5. While we have all gnu-based toolchain, having toolchains be just a series of paths is naïve. Often there are quirks in particular toolchains that need to be dealt with in the code. Ideally, these should be dealt with by toolchain vendors, not by the CDT core. (Although the core may need to become more flexible to support variance in toolchains.) The problem is only compounded when you look at supporting non-gnu toolchains as well.
To satisfy #1 and #2 above, I made the IToolchain interface as minimal as possible. It serves only to bind together the different capabilities of the toolchain under one display name and id. This keeps the IToolchain interface from getting bloated to support all the methods needed by the various subsystems. All the "real" methods of a toolchain are actually in a sub-interface of IToolchainCapability. Each subsystem would define its own capability interface (or multiple capability interfaces). For example, Managed Make might have IManagedMakeCapability, Debugger -> IDebuggerCapability, Binary Parser -> IBinaryParserCapability. This also has the added benefit that a toolchain vendor and a CDT-based tool provider can add additional capabilities without changing CDT core. All they need to do is agree on a capability interface.
In order to satisfy discover of toolchains at runtime and user specification of toolchains (#3, above), the extension point is for a toolchain factory (rather than toolchain). This allows a toolchain vendor to register one extension point that discovers a variable number of toolchains at runtime.
Toolchain capabilities are also designed to keep toolchains from being just a collection of IPath objects. Avoiding toolchains just being a bunch of IPaths was my goal with IToolchainCapability. I'll try and illustrate this with an example:
When a sub-system (like a binary parser) needs to interact with a toolchain, it will query the toolchain reference for the appropriate capability. For example:
IToolchain tc = ToolcainManager.getToolchain(factoryId, toolchainId); IBinaryParserCapability cap = (IBinaryParserCapability)tc.
getCapability(IBinaryParserCapability.TYPE);
The IBinaryParserCapability interface would be specific to the binary parser. If each implementation of binary parser is significantly different we may need one for each type of parser. Just based on what I've seen on the mailing list so far here's an example of what IBinaryParserCapability might look like:
interface IBinaryParserCapability {
String TYPE = "org.eclipse.cdt.IBinaryParserCapability";
ISourceRange getSourceRange(IBinaryFile bFile, long address);
void stripBinary(IBinaryFile bFile, IPath outputFile);
// more methods, including one for interacting with objdump, c++filt, etc.
...
}
I don't think there is any need to change the IBinaryParser interface, at least not for toolchain support. With the above scenario, whenever the binary parser needs information from a toolchain it would obtain an instance to the binary parser capability from the toolchain and call the appropriate method on it. It could be implemented by a command-line tool (such as addr2line) or completely in java, or in a combination. It would be up to the toolchain provider. Instead of a binary parser storing the paths to command-line tools in the .cdtproject file, it would store the ids for the toolchain.
As for the exact methods that would be present in IBinaryParserCapability, I think we should start a separate thread for discussion. In particular a lot of people have been discussing what I would consider improvements to how the binary parser interacts with command lines tools. However, before we get to those specifics for the binary parser I want to try and build some general consensus about the base toolchain interfaces (IToolchainFactory, IToolchain, IToolchainCapability, ToolchainManager), and whether the general approach is acceptable to the group.
Jeremiah
-----Original Message-----
From: Alain Magloire [mailto:alain@xxxxxxx]
Sent: Thursday, February 12, 2004 1:28 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Toolchains in CDT
>
> OK. The binary parser is the area I know the least about at this
> point. As a toolchain provider our goal was to have a user be able to
> choose a "toolchain" from a drop-down containing a set of known
> toolchains, rather than specifying the path for each tool
> individually. That way we can extend an extension point and advertise
> that our tools are available on the machine. We could probably
> implement that completely in the UI. (No changes to IBinaryParser or
> any of its implementations.) Do you think that would be acceptable?
> Or will your changes to the spec handle this case?
>
Ok, that's fine with me, we could just add an adapter to deal with this for the binary parser.
Questions:
- where will the toolchain be use?
When I look at the scenarios, I do not see a lot of use cases. parser, indexer, search etc .. i.e. I certainly the usefullness of this for the Managed Builder, though.
- It does seem like a nice service that CDT core could provide, but I'm confuse about the interface, does ToolFactory maintains tools IPath's ? Will it return interfaces say , IAddr2line.class ? Do you define a set of tools(nm, addr2line, c++filt, ...) ?
- Lets try other plausible cases, "strip" or "ar". Supose we extend the IBinaryParser to strip debug symbols information to another file. The user use an BinaryParser that is implementend on top of IToolChain, we ask for "strip", it returns a path .. but then what, unfortunately not all "strip" are equals and behave the same with the same options/arguments. What I mean is that you sometimes need to change the behaviour of a tool (for a GNU tool, this can be done via different arguments), how can this be done, with the IToolChain.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/cdt-dev
