This is the mail archive of the
mailing list for the GCC project.
questions on writing a back-end' to gcc
- To: gcc-help at gcc dot gnu dot org, gcc at gcc dot gnu dot org
- Subject: questions on writing a back-end' to gcc
- From: Catherine Harper <tylik at eskimo dot com>
- Date: Sat, 3 Nov 2001 18:00:00 -0800 (PST)
Forwarded on behalf of Craig Perras. Please direct followup to his
---------- Forwarded message ----------
Date: Sat, 3 Nov 2001 15:25:00 -0800 (PST)
From: "email@example.com" <firstname.lastname@example.org>
Subject: questions on writing a back-end' to gcc (fwd)
I'm designing a tool which would generate code to support a C++
persistence library. Basically, the idea is to simply insert some extra
logic after the C++ parser has finished constructing the tree, extract
certain type information, and generate the necessary RTTI (which would
support reflection, etc) into another source file. This could then be
compiled and linked into the target program normally.
So, I have a couple questions, and would greatly appreciate any thoughts
First, has anyone else done this, or currently working on something like
Second, where is the best place to integrate this functionality? I've
looked a little into the code and documentation, and it seems I should use
the tree.h interface.
However, I don't want to force users to download or build a special
version of gcc. Are there any hooks I can use, so that I don't have to
create a patch?
If there aren't any hooks I can use, another option in this case would be
to scan debug output. But that has its own disadvantages, and I think that
hooks into the gcc tree interface would be generally useful. One way to
provide this would be to add a command-line option which specifies a
shared library and C function. Then gcc could open this .so after it has
created the tree and invoke the specified function.