Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Toolchains in CDT

Title: Message
Comments are inline.
-----Original Message-----
From: Sean Evoy [mailto:sevoy@xxxxxxxxxx]
Sent: Monday, February 16, 2004 12:30 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Toolchains in CDT

This is a very interesting proposal that has wide-ranging implications. I have put some comments/questions in-line below.

> 1. A user should easily be able to specify they want to use one of
> our toolchains in a C-project.  

Based on your proposal, many of the core CDT features will be treated as toolchains with varying capability interfaces depending on the functionality of the specific feature. I can see the logic of toolchains as part of the core if it will help us support the diverse development environments of the end-user. Where I am a bit worried is how much of that we want to expose the end user to. My own feeling is that users are still thinking in terms of projects and build goals. They are probably more interested in creating a <insert-your-marketing-departments-idea-of-a-cool-name-here> project, adding a couple of files to it, and building.  I guess what I am saying is that toolchains seem like an internal thing and we will need to present bundles of toolchains to users through another, higher-level concept.
I'm not sure I agree.  While the user thinks in terms of projects and build goals, they also think in terms of the tools needed to complete those goals.  For example, in managed make a user may choose "linux executable" as the "platform", but they will also want to choose what version of gcc, ld, etc. they use.  I think the user will see this as two logical steps, first choose the type of output (i.e. linux executable), then choose the toolchain to use (i.e. sh-linux toolchain).  In particular I think this will be necessary when cross-compilation is the goal.
> 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.

From the perspective of the CDT core they should all have the same type, but can/should we force vendors to supply all functionality in a limited range of types? I guess my concern is for the vendor whose tools cannot be easily partitioned. What if a new debugger toolchain was developed that provided its own strip capability, but still relied on some of the other functionality of the default binary parser such as addr2line (or at least did not provide those functions to the core)? Obviously, the vendor supplies an implementation of a debugger toolchain, but they now have an overlapping capability with the default binary parser. We will have to come up with some way to deal with these overlaps so the internal client knows which one to use.  
I think that this problem would exist regardless of how toolchains are provided.  In what I propose the design of the capability would be the key.  In the case above, I might suggest a toolchain which provides both a debug capability and a binary parser capability.  The binary parser capability should extend some base class (e.g. GnuBinaryParserCapability) and override the strip method, but leave the default addr2line and c++filt methods.  The other possibility would be to make the capabilities more granular, for example core might define a IBinaryParserCapability interface which corresponds to addr2line, c++filt and a separate IStripCapability interface.  But I think this second possbility only makes sense if we think a separate implementation of strip is common.
> 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)

I agree completely. Imagine a user gets a new debugger that is binary compatible with their build tools. They probably just want that compiler to appear as an option in the list of debuggers when they debug their project. I doubt that they will intuitively say "Oh yeah, that's a toolchain, I'd better go change that somewhere". The more we hide the idea of a toolchain from the user the better.  
I'm not sure I understand the difference between the two scenarios that you present here.  I saw two possibilities:
1.  This is the one I prefer.  When the user creating/editing a launch configuration the list of debuggers is built from the list of toolchains installed on the machine.  Any toolchain which supplies a debugger capability would be listed.
2.  The list of debuggers would be the same as now.  First the user would choose the type of debugger (i.e. GDB-MI compatable debugger).  Then the user would be presented with a list of toolchains that provide a gdb-mi compatable debugger.
> 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).

This leads me a to a practical concern. If we let users mix-and-match toolchains for a project, how will the CDT core be able to resolve toolchains that should not work together? One can easily imagine that a matrix of toolchain compatibility would be difficult to maintain. What if the builder was producing binary code that was incompatible with the changed binary parser or worse, caused it to die unexpectedly? 
I don't believe that this problem would be any greater than now.  For standard make we allow users to mix and match as much as we want, so this is basically the same.  For managed build, we set the binary parser automatically, and should be able to continue to do so with something similar to the following algorithm:
IToolchain tc = configuration.getToolchain();
IBinaryParserCapability cap = (IBinaryParserCapability)tc.getCapability(IBinaryParserCapability.TYPE);
IBinaryParser parser = cap.getBinaryParser();
Obviously this is a simplified example.  If the toolchain didn't provide a binary parser capability, then either the user would have to choose one, or we would choose the default one.  For example, the default binary parser for linux executable would be the GnuElfBinaryParser, using the default tool locations.
If functionality like the managed (or replacement) builder and binary parser are supplied as toolchains, then the core may not function if at least one is not present or working correctly. Maybe it is better say that we will have to be very strict about what the capability interface must supply? 
I saw two possibilities: 
1. CDT will function without toolchains.  Basically "no toolchain" could be an option, which would default to the behavior that is in CDT now.
2. CDT will autodetect toolchains that are installed on the path.  Minimally, a toolchain factory that spits out a toolchain which corresponds to "gcc on path" would be provided with CDT.  This would ensure that at least one toolchain is always present.
> 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.

We should not do anything that would make it difficult to introduce non-Gnu (or any other) toolchains in the future. An IPath-based approach may not work for every case, but it is robust and simple and all of the required "stuff" is present in the core today. We risk losing some control over quality if the CDT core has to rely on toolchain vendors to work correctly or if everybody adds a new UI element to handle said "quirks". I guess I would feel a bit more comfortable knowing that there was a default implementation that worked with a minimum amount of coding. For example, if you create a new capabilities interface implementation, the default will just use IPath and invoke the command. If that is not enough, then you can customize.  
I think CDT should provide a set of base classes for a "GNU-toolchain" (and also other toolchains, if we can idenitfy the need for them).  It could be used in one of two ways:
1. Call its constructor and pass it a bunch of IPath's (or maybe just Strings) for the tools.  This would cover most people.
2. Sub-class the toolchain class and/or the various toolchain classes and override methods to "tweak" it to work with your toolchain.
I don't think there is anything in the general toolchain design that is specific to gnu-toolchains.  We would need to be careful in the design of each specific capability to ensure nothing gnu-specific goes in. 
To summarize, I like the proposal for discovering the capability of a toolchain and for putting the capabilities in an interface. Obviously, a lot of work will be needed to define what the minimum capability interface is for a toolchain. I can see how a toolchain vendor may want to bundle a set together for a project type (or some other organizational construct) but I am concerned about partitioning functionality and allowing users to mix-and-match potentially conflicting toolchains. I want to get a better handle on whether or not it makes sense to provide a builder as a toolchain, since the parser relies heavily on the build system (standard,  managed, or whatever) to function correctly.  


Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada

Back to the top