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
On 5/04/2014 12:55 AM, Yasumasa Suenaga wrote:
Hi all,
This should fix it:
http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb
I updated OpenJDK8 to java-1.8.0-openjdk-1.8.0.0-0.34.b132.fc20 .
However, debuginfo files are not containe
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:
>>
Hi all,
This should fix it:
http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=1734315551d634b7467f28788d90595b467ea5eb
I updated OpenJDK8 to java-1.8.0-openjdk-1.8.0.0-0.34.b132.fc20 .
However, debuginfo files are not contained ELF sections for debugging.
(I checked libjvm.s
On 2014-03-21 09:57, David Holmes wrote:
And while, technically, you can save symbols externally, and at the same
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 indepe
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
David,
My point was that we don't need in fine grained selection of elf
sections on strip - three options are enough.
> Why does full strip + copy-all + zip make no sense? It is exactly what
> we do with embedded builds. (Naturally you have to copy before you
> strip)
Sorry! it should be: full s
On 21/03/2014 7:36 PM, Dmitry Samersoff wrote:
David,
In practice, we don't have to much to keep internally.
There are no reason to copy out some of .debug_* sections but keep other
ones.
I'm not familiar with exactly what the different strip options do but
the point is this is covered by th
David,
In practice, we don't have to much to keep internally.
There are no reason to copy out some of .debug_* sections but keep other
ones.
So we have a matrix:
(a) Strip mode:
1. full
2. keep symbols
3. keep symbols and .debug_*
(b) Copy mode:
1. Copy all to ext file
2. Copy none to ext f
On 21/03/2014 6:14 PM, Magnus Ihse Bursie wrote:
I don't think this quite works as there are other variations not
captured here. Rather than "zipped" it should just be "external".
Whether the debuginfo files are zipped or not is then an additional
build time option. Additionally we still have t
I don't think this quite works as there are other variations not
captured here. Rather than "zipped" it should just be "external".
Whether the debuginfo files are zipped or not is then an additional
build time option. Additionally we still have to be able to control
the degree of stripping th
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
On 3/18/14 12:22 PM, Andrew Hughes wrote:
- Original Message -
On 3/17/14 7:19 PM, Andrew Hughes wrote:
- Original Message -
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 bi
- Original Message -
> On 3/17/14 7:19 PM, Andrew Hughes wrote:
> > - Original Message -
> >> 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
On 3/17/14 7:19 PM, Andrew Hughes wrote:
- Original Message -
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
- 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
- Original Message -
> 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. St
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
On 3/3/14 12:11 PM, Omair Majid wrote:
Hi,
* Daniel D. Daugherty [2014-03-03 09:57]:
On 3/1/14 4:08 PM, Mike Duigou wrote:
If we can put debuginfo into external files why would we ever want unstripped
binaries?
We deliver minimal stripped binaries so that can have stack traces
with some a
Hi,
* Daniel D. Daugherty [2014-03-03 09:57]:
> On 3/1/14 4:08 PM, Mike Duigou wrote:
> > If we can put debuginfo into external files why would we ever want
> > unstripped binaries?
>
> We deliver minimal stripped binaries so that can have stack traces
> with some amount of information in them
* 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 information is
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
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
Hi David,
> Moving forward I think we would need to expose the strip-policy via a
> configure option and have that pass STRIP_POLICY through to both hotspot
> and the Images target.
I want you to do so :-)
Additionally,
>>> 1. Generating debug symbols in the binaries (via gcc -g or whatever)
>>
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
> debuginfo package.
Th
Hi,
On 2/03/2014 12:07 AM, 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 s
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
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 separation between them, and if so
> that should be fixed, bu
On 1/03/2014 1:38 AM, Yasumasa Suenaga wrote:
>> The proper way to fix this is to disable FDS.
>
> Does this mean I have to pass --disable-debug-symbols to configure ?
> I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols
> to configure, gcc/g++ is not passed -g option. "
> The proper way to fix this is to disable FDS.
Does this mean I have to pass --disable-debug-symbols to configure ?
I've added comment to JDK-8036003, I think if we pass --disable-debug-symbols
to configure, gcc/g++ is not passed -g option. "-g" is needed to generate
debuginfo.
Thanks,
Yasumas
The proper way to fix this is to disable FDS. 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 report this seems way too complicated. Seems to me
> all you need to do to get what you want is not use FDS and not
Hi,
As I put in the bug report this seems way too complicated. Seems to me
all you need 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 sti
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 as package
42 matches
Mail list logo
