Is gcc reentrant.

Manosiz Bhattacharyya
Fri Feb 19 13:44:00 GMT 1999

	I will try to hack jc1 to the purpose. I think the hack might
work. I have seen jc1 to take in multiple classes through the load class
function. Maybe I need to do the same. However, it is not just the
classes, I need I plan to get a call graph going. If I can make a
conservative estimate of the classes and methods.


 On Thu, 18 Feb 1999, Alexandre Petit-Bianco wrote:

> Manosiz Bhattacharyya writes:
> > I wanted to reenter jc1 on all the classes that it figured out in
> > the last runs.
> jc1 naturally re-enters its source and class file analysis code as it
> tries to resolve types. jc1 is also able to process several input
> files within a single invocation, provided that the variable
> input_filename contains a list of `&' separated file names (see
> jcf-parse.c:yyparse.) This single string is transformed into a list of
> identifier tree nodes held in current_file_list. I guess the hack
> would be to tweak that list whenever a new type gets resolved so that
> jc1 sees it sometimes later as an other file to be processed; with
> appropriate exclusion to avoid parsing the same input file twice and
> with the difference that the file doesn't need to be parsed again, but
> that the classes that it defines need to be expanded (eventually using
> java_expand_classes.)
> I believe this should work, since given the following source code
> configuration:
> class f1 {
>    ...
>    f2 foo;
> }
> class f2 {
>    ...
> }
> and the multiple source files found in `input_filename' (with the form
> `'), at the end of the analysis of `', jc1 will
> try to resolve the `f2' type. This results in `' to be analyzed
> (and the filename `' identifier marked using
> HAS_BEEN_ALREADY_PARSED.)  Next, when jc1 comes to analyze `',
> source code parsing will be skipped and jc1 will directly proceed with
> f2's unresolved type resolution (if any) and code generation (see
> jcf-parse.c:jcf_parse_source)
> -- Alex

More information about the Java mailing list