On Wednesday, Jul 2, 2003, at 13:17 America/New_York, pinskia at
physics dot uc dot edu wrote:
Okay I think I figured out how this one is happening, now the problem
is figuring out how to fix it. The problem is the Darwin's backend
depends on current_function_decl which Ada changes the name inside
it for some reason to be one with a .n (where n is an integer). So
the problem is the
hashtable will not caught every thing so on when the setjmp is
generated, current_function_decl is without the .n but when the
function is generated it has a .n, so this is confusing Darwin's
backend. Now I do not know the currect fix at all and this problem
seems to be needed to be fixed in the Ada frontend.
Hi Andrew,
According to Kenner, the .n's are added by the GCC back end for
nested functions. This has nothing to do with Ada itself, and I don't
quite understand your comment that Ada "changes" the name "inside"
current_function_decl. What is exactly happening here?
Anyway, I'm quite unhappy that the whole Darwin PIC code and design
is considered "horribly ugly" and "broken". For that reason I think
it might be best to consider how we can avoid this PIC code and
default to statically linked code by default.
Actually, this brings up a question I have. Why don't we just enable
the "-mdynamic-no-pic" flag by default (at least for the Ada front end)
and then require an explicit -pic or -PIC for this to be enabled?
This came up when I tried to figure out how to change the Ada makefiles
to use the -mdynamic-no-pic flag in the right cases. Not generating
PIC code by default, but fast statically linked code instead, and only
requiring explicit flags for shared executables seems the standard
practice on most systems anyway.
The fact that PIC code is broken on Darwin only makes this more
important.