harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [classlib][build] putting native debug symbols in hdk (not jre)?
Date Wed, 23 Sep 2009 22:01:06 GMT

In message <200909091217.n89CHDr4018843@d06av03.portsmouth.uk.ibm.com>,
Mark Hindess writes:
> 
> In message <4AA0CFAE.7070504@gmail.com>, Tim Ellison writes:
> >
> > On 03/Sep/2009 22:48, Mark Hindess wrote:
> > > In release mode we currently discard windows .pdb files.  This is
> > > good because it keeps the size of the jre down but perhaps we should
> > > place the .pdb files for jre/bin/*.dll in the hdk/ lib directory and
> > > package them in our release HDKs?
> >
> > Or we could follow the other distros that (IIRC) include the source
> > jars and native debug info in JDKs but leave them out of JREs.
> 
> You are right.  The JDK is a better place for them.  (I suggested
> HDK/lib as that is where the corresponding .lib files for windows dlls
> are placed.)
> 
> > I can imagine that having source JARs and .debug/.pdb files is useful
> > as you develop your Java programs, but they are an unnecessary
> > overhead when you are simply running them.
> 
> Exactly.
> 
> > > On linux we could also create smaller .so files (quite a lot smaller
> > > in some cases!) by stripping them but maintain debug capability by
> > > creating associated .debug files.  See:
> > > 
> > >   http://sources.redhat.com/gdb/current/onlinedocs/gdb_17.html#SEC166
> > > 
> > > Something like:
> > > 
> > >   objcopy --only-keep-debug $dll $hdk/lib/$dll.debug
> > >   strip --strip-debug --strip-unneeded $dll
> > >   objcopy --add-gnu-debuglink=$hdk/lib/$dll.debug $dll
> > > 
> > > so gdb can pick them up[0].
> > > 
> > > Do people think this is a reasonable idea?
> > 
> > Yes, though as I say, I'd s/HDK/JDK/g
> 
> I agree.
> 
> > The next logical step would be to compile at a different optimizaion
> > level for the JRE, but I think it is helpful to have the same debug
> > info around so that it can be brought alongside a JRE to help debug
> > it.
> 
> I definitely intended that the debug files would match and would
> automatically used by tools (like gdb) if they were (downloaded and)
> placed on the library path, so having them produced from the same
> original library is essential.
> 
> I agree that providing non-optimized libraries might also serve a useful
> purpose (essentially the native equivalent of running with -Xint) but that
> is outside the scope for what I was trying to do at the moment.  I was
> concentrating on the first failure capture scenario at the moment.
> 
> > We could even host the .debug/.pdb files on the website for debuggers to
> > pick-up, ...
> 
> Hmm... my gdb skills don't extend to that I'm afraid.
> 
> -Mark.

I've committed this change in r818225.  However, since committing I
notice that some (very) old linux distros might not have the requisite
support for this.  If you happen to be unlucky enough to have a broken
build because of this, then please use:

  ant -Dmake.arg="HY_CAN_LINK_DEBUG=no" ...

to workaround this (and let me know what "objdump --version" says on
your machine).

I plan to support non-linux platforms by just copying the whole .so file
with debug symbols to jdk/lib and stripping the version in the jre/bin
directory.  I'll probably handle old linux distros in a similar way.

-Mark.






Mime
View raw message