progress on method-gc / mangling questions

Sun Jan 27 13:33:00 GMT 2002

Bryce McKinlay <bryce@waitaki.otago.ac.nz> writes:
> Java uses a subset of this. The mangling of function names is not likely 
> to change, barring any bugs in our implementation. One special case is 
> that int[] is mangled as JArray<int>.

Is that because a "java int[]" is really a "C++ JArray<int>", and not
a "C++ int*"?
> >- If there is no documentation, can anybody tell me the meaning of
> > these symbol prefixes? I was able to guess the others.

> Note that these ones are private/local symbols that are part of the 
> Class data, I doubt you should ever refer to them directly.

Right, I just need to know when it's safe to omit them.
> >- My binaries have a lot of sections named __Utf<n> where <n> is
> > some number. What are these sections? String constants?

> I don't know why they would be in different sections. The __Utf<n> 
> symbols are Utf8Constants.

Even stranger, these are ".text" sections -- I thought .text was only
for executable code, not for static data... If there is code in there,
it makes sense that they're in seperate sections; I'm using
-ffunction-sections.
> We use Utf8Consts instead of pre-initialized String objects because
> a string object would contain a vtable pointer and thus wouldn't
> usually be a true constant (as well as wasting a bit of space in the
> binary).

Very cool idea.
> I don't think it would be unreasonable, in general, to expect developers 
> to distribute a libgcj.dll or whatever with or alongside their 
> applications, at least once binary compatibility is fully implemented. 

Yes, you're right. I'm still not used to the windows way of doing
things where installing an application will often upgrade your OS
libraries... that still creeps me out.
 - a