adding support for hardened toolchain

Wed Dec 29 20:13:00 GMT 2010

Heiko, All,

On Wednesday 29 December 2010 20:15:29 Heiko Zuerker wrote:
> I'm currently applying additional patches to gcc, in order to create a  
> hardened toolchain.
> You can find the patches here:  
> I was wondering what the best way would be to incorporate that as a  
> configurable options into ct-ng, so other people could enjoy this  
> functionality too.

There is a simple way to do that, but it's not future-proof:
- create a new directory under patches/ for example: patches/hardened
- add new patches in the same structure as currently present in patches/
- configure crosstool-NG to use local patches
  - set Patches origin: Bundled, then local
  - set Local patch directory to ${CT_LIB_DIR}/patches/hardened

Then, when building the toolchain, the additional patches in patches/hardened
will be apply ontop of the current patches.

What I do not like in this scheme is that it does not scale at all. Should
another feature-patchset gets included, we could not use that new patchset
with the hardened patches, as only one 'local' patch dir can be specified.
Besides, it means that true 'local' patches can no longer be applied either.

Yet, you can use that to test your patches integration, as a begining.

Now, I was thinking of something a big more generic:
- add the patches/hardened directory as above
- add a boolean option in the Toolchain options sub-menu:
  [ ] Hardened toolchain
- have CT_Patch look at the patches/hardened directory if the above
  option is set.

Then, if we add a new feature-patchset:
- add a new directory under patches, say patches/foobar
- add a boolean option in the Toolchain options sub-menu
- have CT_Patch add the new directory to the list of dirs to search, if
  the above option is set.

This would have to be split in two parts:
- first, the generic additional patch dir handling
- second the new hardened patches directory

This should not be very complex to do, I think.

> I know it works under x86 based architecture, but don't have any other  
> hardware available to do any testing with.

Qemu might come handy in this case.

Yann E. MORIN.

|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |

For unsubscribe information see

More information about the crossgcc mailing list