You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2009/09/03 23:48:07 UTC
[classlib][build] putting native debug symbols in hdk (not jre)?
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?
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?
Regards,
Mark.
[0] Probably with the help of an appropriate LD_LIBRARY_PATH setting
Re: [classlib][build] putting native debug symbols in hdk (not jre)?
Posted by Mark Hindess <ma...@googlemail.com>.
In message <20...@d06av03.portsmouth.uk.ibm.com>,
Mark Hindess writes:
>
> In message <4A...@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.
Re: [classlib][build] putting native debug symbols in hdk (not jre)?
Posted by Mark Hindess <ma...@googlemail.com>.
In message <4A...@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.
Re: [classlib][build] putting native debug symbols in hdk (not jre)?
Posted by Tim Ellison <t....@gmail.com>.
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.
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
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.
We could even host the .debug/.pdb files on the website for debuggers to
pick-up, ...
Regards,
Tim
> Regards,
> Mark.
>
> [0] Probably with the help of an appropriate LD_LIBRARY_PATH setting
>
>
>
Re: [classlib][build] putting native debug symbols in hdk (not jre)?
Posted by Gregory Shimansky <gs...@apache.org>.
On 4 Septemper 2009 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?
>
> 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?
>
> Regards,
> Mark.
>
> [0] Probably with the help of an appropriate LD_LIBRARY_PATH setting
We could create both versions, light and with the symbols.
--
Gregory