This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

addr2line and the name of the executable


Hi,

    While playing with Mohan's GCJ 3.3 build, I noticed 
that I get a proper stack trace with mangled symbols 
only if I explicitly invoke my program like "foo.exe" 
instead of the usual "foo".

It turns out that this is because addr2line expects the 
actual file name of the executable with the "-e" flag and 
not argv[0] which is what is effectively being passed 
to it.

I had not noticed it before with my builds simply because
the mingw-local patches change argv[0] to the fully 
qualified name of the executable. (Which itself is 
suspect behaviour since "By convention, argv[0] is the 
name by which the program was invoked..." - K&R, 
2nd Ed., Section 5.10.)

It manifests in Mohan's build because he uses stock GCC
sources instead of mingw-local patched sources.

To resolve this, is it OK if I have a "#ifdef WIN32"-ed
code in gnu::gcj::runtime::NameFinder::getExecutable( )
that just calls the Win32 GetModuleFileName( ) function
to retrieve the executable file for the current process?

If yes, I'll submit a patch for this.

AFAICT, on Linux, _Jv_ThisExecutable( ) would return
"/proc/nn/exe", where "nn" is the PID of the current
process and this path is just a symbolic link to the
real executable. So the property "gnu.gcj.progname"
would not really be "the name by which the program
was invoked" - isn't that (sort of) wrong?

Ranjit.

-- 
Ranjit Mathew        Email: rmathew AT hotmail DOT com
Bangalore,           
INDIA.               Web: http://ranjitmathew.tripod.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]