On Fri, 2008-04-11 at 17:05 -0400, Daniel Jacobowitz wrote: > On Sat, Apr 12, 2008 at 06:59:28AM +1000, Tim Josling wrote: > > > Why not get it out of GCC later? You don't need to hack up GCC to do > > > that.
> That's not what I meant. You don't need it _during the GCC build > process_. You can fork GCC and run it and have it tell you the answer > based on the current command line arguments, read its output, and > go on with what you were doing. Which presumably involves further > compilation. > You're right... That's more or less what I think I will do. I'm working on a proof of concept at the moment. > (You didn't say what you are trying to do, so I'm guessing at the > context a bit.) > Here is some more explanation of what I am trying to do. My COBOL compiler was going to look like this: (1). The gcc driver calls a lisp program which does the preprocessing (lex/parse/copy-includes/replaces), lex, parse, cross checking, simplification, and creates an output file in a simple binary format. This Lisp program does not have direct access to any GCC code including headers. (2). The gcc driver passes the output file to another program (cob1) which would be similar to cc1 except that its input file is a simple binary format that does not need to be lexed and parsed. This program will be drived by toplev.c and will generate, via the gcc back end, the assembler output to be assembled and linked by subsequent programs called from the gcc driver. It will have access to all the gcc middle and back end code. My initial intention was that the program (1) should know as little about gcc as possible. I then realised that it would need some target information such as type sizes and alignment information from gcc. I thought I could get this information by writing a small program that would pull in some headers and could then output a Lisp program that could be compiled into program (1). This didn't work out very well because the information is only available within the compiler at run time on the target system, and it is dynamic and option-dependent. So I will add an option to the compiler "-fget-types". This will trigger the output on standard output of all the information I need. So the flow will be: (0) cob1 -fGet-types ->stdout passed as a parameter to (1) (1) Lisp pgm ->binary file (2) cob1 Main toplev.c compilation taking binary file as input. For various reasons I have to run the Lisp program via a shell script. I cab readily include the -fget-types run in that, something like this lisp <lisp stuff> --user-parms -o <binary-output-file-name> <normal-options> -ftypes=`cob1 -fget-types` <input-file-name> The stdout from cob1 -fget-types will get passed to the Lisp program via the shell back-quotes facility, which incorporates stdout from a file into the command line where the back quotes appear. This is used elsewhere in gcc. Regards, Tim Josling
