Looks good!
/Erik
On 2018-03-08 06:19, Magnus Ihse Bursie wrote:
Since long time ago, native libraries in JDK has been compiled with -g1 instead
of -g, when doing a fastdebug build with gcc. (This does not apply to hotspot
which is always compiled with -g.)
This means that the debug
Since long time ago, native libraries in JDK has been compiled with -g1 instead
of -g, when doing a fastdebug build with gcc. (This does not apply to hotspot
which is always compiled with -g.)
This means that the debug information generated is limited. The gcc manual says
this about level 1
Hi,
* Yasumasa Suenaga [2014-04-04 10:56]:
> I've succeeded to make binaries which are contained debuginfo as following:
>
> http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012037.html
> $ make images STRIP_POLICY=no_strip POST_STRIP_CMD=""
>
> I guess that we should run "make" abov
For example, OpenJDK8 in Fedora20 ships libjvm.so and
libjvm.debuginfo .
libjvm.debuginfo is generated in OpenJDK's makefiles, however it
does not
contain debug information. Actual debug information is shipped by
OpenJDK
debuginfo package.
That's a bug in Fedora's build. We shoul
Magnus,
Not, we are not doing it now.
But we should consider doing it in a future and therefore keep it in
mind when designing option to choose debug symbol mode.
-Dmitry
On 2014-03-24 15:18, Magnus Ihse Bursie wrote:
> On 2014-03-21 10:36, Dmitry Samersoff wrote:
>>
>> (c) Compression mode:
>>
, Omair Majid wrote:
* Andrew Haley [2014-03-03 04:43]:
On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote:
For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo .
libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not
contain debug information. Actual debug in
sed, I would like to implement this for libjvm first and
then take care of the other libraries in a separate patch.
Thanks,
Erik
Dan
On 2/12/14 8:03 AM, Erik Helin wrote:
Hi all,
this patch changes how old debug information copied from
IMPORT_JDK is
treated.
When running the copy_*_j
t what about the
other libraries exported by HotSpot? libjsig, libjvm_db,
and libjvm_dtrace come to mind...
As we discussed, I would like to implement this for libjvm first and
then take care of the other libraries in a separate patch.
Thanks,
Erik
Dan
On 2/12/14 8:03 AM, Erik Helin wrote:
Hi a
l boils down to a few sensible ways to handle all debug
information.
1) The Oracle way -- copying debug information into an external format
(that by default is zipped), and stripping the binary as much as reasonable.
2) The community way -- keep everything in the binary, and not creating
a sep
On 2014-03-21 10:36, Dmitry Samersoff wrote:
(c) Compression mode:
1. none
2. per-section compression, SHF_GNU_COMPRESSED [1]
3. zip entire file
Is 2 something we're doing? I couldn't find any references to it in the
code. Or is it something we're planning to do?
/Magnus
re not independent on each other!
>>>>
>>>> Unless you generate debug symbols, you can't strip them, nor save them
>>>> elsewhere. So generating debug symbols (your item #1) is a prerequisite
>>>> for the rest of your items.
>>>
>
internally independent of what is made
external.
And you can't zip external symbols unless you create a non-zipped
version. And if you zip them, it does not make sense to keep the
non-zipped version.
zip vs non-zip is just an issue of disk space. It is not a fundamental
configuration choice, j
ame
>> time keep them in the binary, that does not make sense. So, in a
>> practical sense, you are going to do #2 if you are going to do #3.
>
> But you can vary what is kept internally independent of what is made
> external.
>
>> And you can't zip external sym
disk space. It is not a fundamental
configuration choice, just a variation on how external symbols are packaged.
And yes, we do not strip all debug information when creating external
debug info. But there seems to be no real use case (not even for
IcedTea, as it turned out) to want a complete
s unless you create a non-zipped
version. And if you zip them, it does not make sense to keep the
non-zipped version.
And yes, we do not strip all debug information when creating external
debug info. But there seems to be no real use case (not even for
IcedTea, as it turned out) to want a comp
On 18/03/2014 6:59 PM, Magnus Ihse Bursie wrote:
On 2014-03-18 02:19, Andrew Hughes wrote:
Do we need more than just the following three alternatives?
#1. No debugging information at all.
#2. Debugging information left in the original binaries.
#3. Debugging information stripped from the binari
On 2014-03-19 15:57, Andrew Hughes wrote:
I think that's something we must fix ourselves. What we really
need from OpenJDK is a way to build with complete debuginfo in
both binaries and jarfiles.
This was my intent with #2. The jstack/jmap issue needs to be fixed by
stripping less debuginfo
- Original Message -
> On 03/19/2014 01:51 PM, Magnus Ihse Bursie wrote:
> > On 2014-03-18 19:25, Andrew Haley wrote:
> >> On 03/18/2014 06:22 PM, Andrew Hughes wrote:
> >>> The intent was for #3 to cover this case (i.e. whatever Oracle does now)
> >>> and for #2 to be what the GNU/Linux
On 03/19/2014 01:51 PM, Magnus Ihse Bursie wrote:
> On 2014-03-18 19:25, Andrew Haley wrote:
>> On 03/18/2014 06:22 PM, Andrew Hughes wrote:
>>> The intent was for #3 to cover this case (i.e. whatever Oracle does now)
>>> and for #2 to be what the GNU/Linux distributions want (i.e. binaries with
>>
On 2014-03-18 19:25, Andrew Haley wrote:
On 03/18/2014 06:22 PM, Andrew Hughes wrote:
The intent was for #3 to cover this case (i.e. whatever Oracle does now)
and for #2 to be what the GNU/Linux distributions want (i.e. binaries with
all debuginfo generated and left intact so they can do their o
On 03/18/2014 06:22 PM, Andrew Hughes wrote:
> The intent was for #3 to cover this case (i.e. whatever Oracle does now)
> and for #2 to be what the GNU/Linux distributions want (i.e. binaries with
> all debuginfo generated and left intact so they can do their own stripping).
Mmm, but maybe that wi
the debug symbols. That's the
problem
I believe we have with our builds; we can turn the stripping off, but then
we
end up with duplicate debug information.
Do we need more than just the following three alternatives?
#1. No debugging information at all.
#2. Debugging information left in the
e
> > generated
> > in the binaries), not #2. That's why it sounded so odd to me when you
> > suggested
> > turning it off, when we discussed this before.
> >
> > It's also not clear why you'd want a situation where #3 would be turned
> > o
ilds; we can turn the stripping off, but then we
end up with duplicate debug information.
Do we need more than just the following three alternatives?
#1. No debugging information at all.
#2. Debugging information left in the original binaries.
#3. Debugging information stripped from the binaries an
- Original Message -
> On 2014-03-18 02:19, Andrew Hughes wrote:
> > Do we need more than just the following three alternatives?
> >
> > #1. No debugging information at all.
> > #2. Debugging information left in the original binaries.
> > #3. Debugging information stripped from the binaries
On 2014-03-18 02:19, Andrew Hughes wrote:
Do we need more than just the following three alternatives?
#1. No debugging information at all.
#2. Debugging information left in the original binaries.
#3. Debugging information stripped from the binaries and zipped in separate
files.
It sounds to me
would be turned off, but
not #2, as you end up with two copies of the debug symbols. That's the problem
I believe we have with our builds; we can turn the stripping off, but then we
end up with duplicate debug information.
Do we need more than just the following three alternatives?
#1. No debugging
On 3/3/14 2:49 PM, Omair Majid wrote:
* David Holmes [2014-02-28 18:48]:
There are three pieces to all of this:
1. Generating debug symbols in the binaries (via gcc -g or whatever)
2. Generating debuginfo files (zipped or not) (FDS)
3. Stripping debug symbols from the binaries (strip-policy)
* David Holmes [2014-02-28 18:48]:
> There are three pieces to all of this:
>
> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
> 2. Generating debuginfo files (zipped or not) (FDS)
> 3. Stripping debug symbols from the binaries (strip-policy)
>
> It may be that we don't hav
the debug
information from these binaries, hotspot will break completely when it
tries to generate a stack trace on crash?
Not quite. If you follow this process:
- use gobjcopy to copy debug info from libjvm.so -> libjvm.debuginfo
- use gobjcopy to tell libjvm.so that debug info is found
amount of information in them when the debuginfo files
> are not available. We have not yet figured out how to implement
> minimal stripping on Windows so Windows hs_err_pid files have no
> symbols in them when the debuginfo bundles are not present.
Am I reading it right that when tools (like
* Andrew Haley [2014-03-03 04:43]:
> On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote:
> > For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo .
> > libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not
> > contain debug information
I think we're having a problem with not all replies making it
to all the aliases. Yasumasa's reply to David below that Mike
is replying to did not arrive on any of the aliases that I'm
on... Folks need to remember to reply to all of the aliases...
On 3/1/14 4:08 PM, Mike Duigou wrote:
> On Mar 1
eve what you
> want by enabling FDS but set STRIP_POLICY to none, and set
> POST_STRIP_CMD to empty.
I tried:
$ make images STRIP_POLICY=no_strip POST_STRIP_CMD=""
I was able to get binaries which is included debug information.
Thanks,
Yasumasa
On 2014/03/03 13:39, David H
Hi Andrew,
> Separating debuginfo is not
> something that we want the OpenJDK build to do, and the most useful
> thing that we could have is a switch to turn all of OpenJDK's
> stripping and separate debuginfo off. I expect the same applies to
> all distros.
My patch provides "SEPARATED_DEBUGINF
On 03/01/2014 11:08 PM, Mike Duigou wrote:
> Do I understand correctly that rpmbuild can only deal with
> unstripped binaries and generates the stripped rpm package and
> debuginfo package.
Exactly. OpenJDK generating separate debuginfo files is very
inconvenient for RPM builds.
> It sounds kin
On 02/28/2014 09:18 AM, Yasumasa Suenaga wrote:
> For example, OpenJDK8 in Fedora20 ships libjvm.so and libjvm.debuginfo .
> libjvm.debuginfo is generated in OpenJDK's makefiles, however it does not
> contain debug information. Actual debug information is shipped by OpenJDK
>
DS. We should not need
>>>> yet another option to control debug info.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 2/28/14 4:13 AM, David Holmes wrote:
>>>>> Hi,
>>>>>
>>>>> As I put in the bug
HI Mike,
> - I would expect that the flow is something like an extended version of
> https://blogs.oracle.com/dbx/entry/creating_separate_debug_info :
>1. Compile source files with some form of "-g"
>2. Create separate debug files for object files.
>3. Strip object files.
>4.
On Mar 1 2014, at 06:07 , Yasumasa Suenaga wrote:
> Hi David,
>
>> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
>> 2. Generating debuginfo files (zipped or not) (FDS)
>> 3. Stripping debug symbols from the binaries (strip-policy)
>>
>> It may be that we don't have clean
ed to do to get what you want is not use FDS and not strip the
>>>> symbols from the binary. The former is trivial. The latter is more
>>>> awkward as the strip policy stuff does not work as I would want it to
>>>> work, but still doable.
>>>>
>>>&
the binary. The former is trivial. The latter is more
>>> awkward as the strip policy stuff does not work as I would want it to
>>> work, but still doable.
>>>
>>> David
>>>
>>> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote:
>>>> Hi all,
&
gt;> work, but still doable.
>>
>> David
>>
>> On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>>
>>> Currently, configure script can accept --disable-debug-symbols and
>>> --disable-zip-debug-info as controlling
>>
>> Currently, configure script can accept --disable-debug-symbols and
>> --disable-zip-debug-info as controlling to generate debug information.
>> However, current makefiles cannot build ELF binaries which is contained
>> debug information with "images" tar
still doable.
David
On 28/02/2014 7:18 PM, Yasumasa Suenaga wrote:
> Hi all,
>
>
> Currently, configure script can accept --disable-debug-symbols and
> --disable-zip-debug-info as controlling to generate debug information.
> However, current makefiles cannot build ELF binaries
Hi all,
Currently, configure script can accept --disable-debug-symbols and
--disable-zip-debug-info as controlling to generate debug information.
However, current makefiles cannot build ELF binaries which is contained
debug information with "images" target.
Some Linux distros use RPM
r libjvm first and
then take care of the other libraries in a separate patch.
Thanks,
Erik
Dan
On 2/12/14 8:03 AM, Erik Helin wrote:
Hi all,
this patch changes how old debug information copied from
IMPORT_JDK is
treated.
When running the copy_*_jdk target, HotSpot's makefiles copies
e patch.
Thanks,
Erik
Dan
On 2/12/14 8:03 AM, Erik Helin wrote:
Hi all,
this patch changes how old debug information copied from
IMPORT_JDK is
treated.
When running the copy_*_jdk target, HotSpot's makefiles copies the
entire IMPORT_JDK folder, including additional files (such as
bjvm first and
then take care of the other libraries in a separate patch.
Thanks,
Erik
Dan
On 2/12/14 8:03 AM, Erik Helin wrote:
Hi all,
this patch changes how old debug information copied from IMPORT_JDK is
treated.
When running the copy_*_jdk target, HotSpot's makefiles copies the
entir
discussed, I would like to implement this for libjvm first and
then take care of the other libraries in a separate patch.
Thanks,
Erik
Dan
On 2/12/14 8:03 AM, Erik Helin wrote:
Hi all,
this patch changes how old debug information copied from IMPORT_JDK is
treated.
When running the copy_*_jd
eparate patch.
Thanks,
Erik
Dan
On 2/12/14 8:03 AM, Erik Helin wrote:
Hi all,
this patch changes how old debug information copied from IMPORT_JDK is
treated.
When running the copy_*_jdk target, HotSpot's makefiles copies the
entire IMPORT_JDK folder, including additional files (such as unzi
o the above change handles libjvm, but what about the
other libraries exported by HotSpot? libjsig, libjvm_db,
and libjvm_dtrace come to mind...
Dan
On 2/12/14 8:03 AM, Erik Helin wrote:
Hi all,
this patch changes how old debug information copied from IMPORT_JDK is
treated.
When running the
Hi all,
this patch changes how old debug information copied from IMPORT_JDK is
treated.
When running the copy_*_jdk target, HotSpot's makefiles copies the
entire IMPORT_JDK folder, including additional files (such as unzipped
debug information). The export_*_jdk targets will then, vi
I created
6832141: Bug 100045 - Fix for 100028 breaks debug info for class files
-kto
Andrew Haley wrote:
Jonathan Gibbons wrote:
Andrew.
Earlier this week, Mark announced that Release Team approval was required
for the final M3 builds for JDK7. [1]
Glad I asked.
Even without that, jch
Dalibor,
I'd suggest raising this to P2, since I think it's a serious regression.
-- Jon
Dalibor Topic wrote:
Jonathan Gibbons wrote:
Andrew.
Earlier this week, Mark announced that Release Team approval was required
for the final M3 builds for JDK7. [1]
Even without that, jcheck would r
Jonathan Gibbons wrote:
> Andrew.
>
> Earlier this week, Mark announced that Release Team approval was required
> for the final M3 builds for JDK7. [1]
>
> Even without that, jcheck would require that you have another BugTraq CR
> for this issue, even though it is just a modification of a recent
Jonathan Gibbons wrote:
> Andrew.
>
> Earlier this week, Mark announced that Release Team approval was required
> for the final M3 builds for JDK7. [1]
>
> Even without that, jcheck would require that you have another BugTraq CR
> for this issue, even though it is just a modification of a recent
Xiomara Jayasena wrote:
> End of today is the code freeze for the build integration area. The
> last putback (Bug ID: 6829575) broke the windows builds.
Kelly, please help me out here, my understanding is that my patch
was tested on all the platforms before I pushed it. If my patch
really broke
End of today is the code freeze for the build integration area. The
last putback (Bug ID: 6829575) broke the windows builds.
Chris Hegarty's (SCTP feature) is in the build integration area so the
changes from there need to be pushed to the master prior to build 56.
Please address the above
On Mon, Apr 20, 2009 at 02:06, Andrew Haley wrote:
> Jonathan Gibbons wrote:
>> Andrew.
>>
>> Earlier this week, Mark announced that Release Team approval was required
>> for the final M3 builds for JDK7. [1]
>
> Glad I asked.
>
>> Even without that, jcheck would require that you have another BugT
Jonathan Gibbons wrote:
> Andrew.
>
> Earlier this week, Mark announced that Release Team approval was required
> for the final M3 builds for JDK7. [1]
Glad I asked.
> Even without that, jcheck would require that you have another BugTraq CR
> for this issue, even though it is just a modification
Andrew.
Earlier this week, Mark announced that Release Team approval was
required
for the final M3 builds for JDK7. [1]
Even without that, jcheck would require that you have another BugTraq CR
for this issue, even though it is just a modification of a recent fix.
I didn't see
a new CR get
Jonathan Gibbons wrote:
> Andrew Haley wrote:
>> I'm going to change langtools/jaxp/jaxws to
>>
>> ifeq ($(DEBUG_CLASSFILES), true)
>> ANT_OPTIONS += -Djavac.debug=true
>> ANT_OPTIONS += -Djavac.debuglevel=source,lines,vars
>> endif
>
> Yes. If all you want to do is to provide a consistent wa
Andrew Haley wrote:
Andrew Haley wrote:
Jonathan Gibbons wrote:
On Apr 17, 2009, at 9:11 AM, Andrew Haley wrote:
Jonathan Gibbons wrote:
It's one thing to be enabling more debug information if you set flags,
and/or making it more consistent, but I'm not
Andrew Haley wrote:
> Kelly O'Hair wrote:
>>
>> Andrew Haley wrote:
>>> Kelly O'Hair wrote:
Yes, I think you are right. Sorry, I think I sent you on this dead goose
chase. :^(
If this is in the jaxp and jaxws repositories, we need to fix those too.
>>> Alright. I'll test a new
Kelly O'Hair wrote:
>
>
> Andrew Haley wrote:
>> Kelly O'Hair wrote:
>>> Yes, I think you are right. Sorry, I think I sent you on this dead goose
>>> chase. :^(
>>>
>>> If this is in the jaxp and jaxws repositories, we need to fix those too.
>>
>> Alright. I'll test a new patch and submit it her
Andrew Haley wrote:
> Jonathan Gibbons wrote:
>> On Apr 17, 2009, at 9:11 AM, Andrew Haley wrote:
>>
>>> Jonathan Gibbons wrote:
>>>
>>>> It's one thing to be enabling more debug information if you set flags,
>>>> and/or making it m
k, that we took this discussion offline.
Agreed.
Andrew.
---
A little background...
With native code the historic position on debug has been between two extremes:
debug builds - full debug information
production builds - no debug information at all, and stripped ELF symbols
Function
Kelly O'Hair wrote:
> Yes, I think you are right. Sorry, I think I sent you on this dead goose
> chase. :^(
>
> If this is in the jaxp and jaxws repositories, we need to fix those too.
Alright. I'll test a new patch and submit it here.
Part of the problem is, I think, that we took this discussi
Jonathan Gibbons wrote:
>
> On Apr 17, 2009, at 9:11 AM, Andrew Haley wrote:
>
>> Jonathan Gibbons wrote:
>>
>>> It's one thing to be enabling more debug information if you set flags,
>>> and/or making it more consistent, but I'm not happy with y
Yes, I think you are right. Sorry, I think I sent you on this dead goose
chase. :^(
If this is in the jaxp and jaxws repositories, we need to fix those too.
-kto
Andrew Haley wrote:
Kelly O'Hair wrote:
My fault. I reviewed this and it didn't dawn on me what this did
until your email.
Yes, th
On Apr 17, 2009, at 9:11 AM, Andrew Haley wrote:
Jonathan Gibbons wrote:
It's one thing to be enabling more debug information if you set
flags,
and/or making it more consistent, but I'm not happy with you removing
debug information by default. At least from reading the change
Kelly O'Hair wrote:
> My fault. I reviewed this and it didn't dawn on me what this did
> until your email.
>
> Yes, the default production builds with javac should be source,lines.
> Sorry, I had native code on the brain and was thinking 'debug off' :^(
How about if I do
ifeq ($(DEBUG_CLASSFILES
thing to be enabling more debug information if you set flags,
and/or making it more consistent, but I'm not happy with you removing
debug information by default. At least from reading the changeset diff,
it seems there is no way to get what was previously the default amount
of debug info, w
Jonathan Gibbons wrote:
> It's one thing to be enabling more debug information if you set flags,
> and/or making it more consistent, but I'm not happy with you removing
> debug information by default. At least from reading the changeset diff,
> it seems there is no way to g
Andrew,
It's one thing to be enabling more debug information if you set flags,
and/or making it more consistent, but I'm not happy with you removing
debug information by default. At least from reading the changeset
diff, it seems there is no way to get what was previously t
Changeset: 4b72c2556789
Author:aph
Date: 2009-04-17 15:56 +0100
URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/4b72c2556789
6829575: 100028: Debug information is incomplete or missing
Summary: Enable debugging in many places
Reviewed-by: ohair
Contributed-by: Andrew Haley
Changeset: 9ad7e6462145
Author:aph
Date: 2009-04-17 15:56 +0100
URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/9ad7e6462145
6829575: 100028: Debug information is incomplete or missing
Summary: Enable debugging in many places
Reviewed-by: ohair
Contributed-by: Andrew Haley
Changeset: a92183572d99
Author:aph
Date: 2009-04-17 15:56 +0100
URL: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/a92183572d99
6829575: 100028: Debug information is incomplete or missing
Summary: Enable debugging in many places
Reviewed-by: ohair
Contributed-by: Andrew Haley
Changeset: 19c316392d9e
Author:aph
Date: 2009-04-17 15:55 +0100
URL: http://hg.openjdk.java.net/jdk7/build/jaxp/rev/19c316392d9e
6829575: 100028: Debug information is incomplete or missing
Summary: Enable debugging in many places
Reviewed-by: ohair
Contributed-by: Andrew Haley
Changeset: 5d4dd2f5f6a1
Author:aph
Date: 2009-04-17 15:50 +0100
URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/5d4dd2f5f6a1
6829575: 100028: Debug information is incomplete or missing
Summary: Enable debugging in many places
Reviewed-by: ohair
Contributed-by: Andrew Haley
Changeset: a942ea653d97
Author:aph
Date: 2009-04-17 15:37 +0100
URL: http://hg.openjdk.java.net/jdk7/build/rev/a942ea653d97
6829575: 100028: Debug information is incomplete or missing
Summary: Enable debugging in many places
Reviewed-by: ohair
Contributed-by: Andrew Haley
! make
Kelly O'Hair wrote:
>
> Seems ok to me, just a few observations:
>
> Do we need this:
>
> ifeq ($(DEBUG_CLASSFILES), true)
> ANT_OPTIONS += -Djavac.debug=true
> ANT_OPTIONS += -Djavac.debuglevel=source,lines,vars
> endif
>
> to be
>
> ifeq ($(DEBUG_CLASSFILES), true)
> ANT_OPTIONS += -Dj
'make DEBUG_BINARIES=true
> DEBUG_FLAG=-g1'.
Thanks, I hadn't considered this possibility.
> So how about:
>
> # DEBUG_BINARIES overrides everything, use full -g debug information
> ifeq ($(DEBUG_BINARIES), true)
> DEBUG_FLAG = -g
> CFLAGS_REQUIRED += $(DEBUG_F
thing, use full -g debug information
ifeq ($(DEBUG_BINARIES), true)
DEBUG_FLAG = -g
CFLAGS_REQUIRED += $(DEBUG_FLAG)
endif
Otherwise it seems fine.
If you have patch files for each repository (hg diff > patch) I can
run them through our test build system JPRT for you, and send you
the r
This is my first stab at moving patches from IcedTea into OpenJDK.
Rather than creating a single overriding variable that enables debuginfo
everywhere I've used two, one for native files and one for class files.
Setting DEBUG_CLASSFILES=true in the toplevel forces all classes to be built
with full
re by default.
> And you can't easily 'strip' debug information from class files that I
> am aware of. I'm a bit puzzled how you can remove the debug
> information from the classfiles and put that in a separate package.
We can't; I was only referring to E
or missing. It can be very valuable at times, just strange.
* Using javac -g will just add information about local variables,
source line information is always there by default.
And you can't easily 'strip' debug information from class files that I
am aware of. I'm
In GNU/Linux/BSD/etc systems we normally want to be able to debug
installed packages. So, in many distributions there is a rule that
all packages must be built with full debug information. This isn't
quite as bloated as it might sound, as we extract all such debug
information files and p
89 matches
Mail list logo
