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, 09 Sep 2009 12:17:13 GMT

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.


> > 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.


View raw message