addr2line and the name of the executable

[Andrew Haley]

Mohan Embar writes:
 > > > Andrew> gnu.gcj.prognamegnu.gcj.progname should probably be argv[0], unmangled by anuything.
 > > > 
 > > > That would mean that my patch would have _Jv_ThisExecutable() potentially
 > > > return something different than gnu.gcj.progname.
 > >
 > >Yes.  Definitely.  We shouldn't intermix the implementation of
 > >gnu.gcj.progname and argv[0]; they have completely different purposes.
 > 
 > I'm running into a small snag with this. If we want gnu.gcj.progname
 > always equal to argv[0],

We don't.  There is no connection.

 > then this behavior is inconsistent with the current implementation
 > today: because today if HAVE_PROC_SELF_EXE is defined, then
 > gnu.gcj.progname becomes /proc/XXX/exe. I don't see why
 > gnu.gcj.progname is allowed to be /proc/XXX/exe in the case of
 > HAVE_PROC_SELF_EXE, but not the full path to the executable in the
 > case of Win32.

Neither do I.  This is a good plan.

 > Semantically, argv[0] and the full path to the executable are the
 > same in the case of Win32,

Ok.  Full path, drive letter, server name, everything?  I didn't know that.

 > and given that gnu.gcj.progname is allowed to be something other
 > than argv[0] in one already-existing current implementation, I
 > don't see the harm in allowing it to be something different (albeit
 > way more semantically equivalent than /proc/XXX/exe) in Win32 also.
 > 
 > May I have:
 > 
 > gnu.gcj.progname = _Jv_ThisExecutable() = whatever the implementation chooses?

Let gnu.gcj.progname be argv[0].

Let _Jv_ThisExecutable() be a full path to the executable.

As long as both of these are satisfied, everything's fine.

Andrew.