On Wed, 18 Jun 2025 15:28:29 +0200 Richard Biener <richard.guent...@gmail.com> wrote:
> That means, the adjustment should end up unifying the FUNCTION_DECL > used for all calls. Thank you. Not to put words in his mouth, but I think that's what Bob suspected. > Btw, is there any way that the thing 'prog' calls can turn out a > "wrong thing"? Aka, not a function? There is not. If prog is a string constant that refers to a contained program, we look up the "mangled" name based on the provided string and the containing program. If it does not refer to a contained program, it remains unchanged. If the program is compiled to emit static references, ld(1) will verify the symbol is somehow provided. Else the emitted code uses dlsymI(3), which of course may result in a runtime error. Unlike a normal, typical, sane, adult environment, COBOL programs traditionally aren't linked until they're executed. The JCL defines the libraries that are used for that invocation, which may not supply all the symbols the program could reference, but do supply those used for that particular invocation. Rather than a bunch of programs in /usr/bin, it's more like there are bunch of object files that the system may compose in various ways for various purposes. > Traditionally I'd have the parser register a tentative (extern) > declaration at the point of the call in 'prog' and when parsing > 'prog2' I'd query the table of (tentative) declarations, find one for > 'prog2' and then rewrite that to a definition. So, I would have > expected the Cobol frontend to have a symbol table based on its name > lookup rules. I don't see any difference between what you're saying and what we're doing. The map we're iterating over refers to symbols in the symbol table. It just relieves us of having to traverse the whole thing. --jkl
