addr2line and the name of the executable

[Ranjit Mathew]

> My patch is slightly at variance with your post. Here are my reflections:
>
> >  a. "gnu.gcj.progname" should be set to whatever is argv[0]. Note that
> >     apparently on Mac OS Classic, argv[0] can actually be equal to NULL,
> >     though this might be irrelevant since there is no port of GCJ on Mac
> >     OS Classic.
>
> This would be at variance with the current behavior today, where
gnu.gcj.progname
> returns /proc/XXX/exe on i686 Linux, for example. Although you mused as to
> how well-founded this was (and I agree), changing this behavior could
> potentially break the fringe cases that rely on this. Being new to this,
> I can't properly assess the consequences and wasn't comfortable changing
> behavior on platforms other than mingw32.

The "gnu.gcj.progname" thingy was inflicted upon GCJ by yours truly:

    http://gcc.gnu.org/ml/java/2002-10/threads.html#00149

The primary motivation there was again a "Usage: "-type situation I
faced with a simple program in Java. For some reason, I used
_Jv_ThisExecutable( ) rather than argv[0] - probably it wasn't
a global variable then, probably I was smoking something I shouldn't
have been... ;-)


> I said *semantically* equivalent, not equivalent. Given that a subset of
the
> Win32 platforms (albeit "deprecated" ones: Win9x) would end up having
> gnu.gcj.progname return the same value as the value that would be returned
> by my proposed patch on all Win32 platforms (i.e. the full path to the
executable
> and not necessarily whatever was present verbatim on the command line), I
don't see
> the harm in generalizing this to all Win32 platforms. I can't even begin
to imagine a
> case where the patch's behavior (having gnu.gcj.progname return
GetModuleFilename()
> and not the actual value on the command line) would not be acceptable on
> non-Win9x platforms, especially given that such programs would then break
> if run on Win9x....

Actually there *are* programs which behave differently depending on the
actual command used to invoke them. For example, "vi" will become a
read-only
editor(?) if invoked as "view", "gzip" (and bzip2) will behave
differently if invoked as "gunzip" or "gzcat" (or "bunzip2" or "bzcat")
respectively and so on.

Given that even Microsoft has discarded their full-path-to-exe approach
to argv[0] and have decided to honour the UNIX convention in their "modern"
operating systems like Win2K/WinXP, it can't be *that* terrible an idea,
can it? ;-)

Ranjit.