NEW: devel/dwz

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

NEW: devel/dwz

Brian Callahan-5
Hello ports --

It was hinted at recently that a port of dwz might be desirable. Here is
one.

---
pkg/DESCR:
dwz is a program that attempts to optimize DWARF debugging information
contained in ELF shared libraries and ELF executables for size, by
replacing DWARF information representation with equivalent smaller
representation where possible and by reducing the amount of duplication
using techniques from DWARF standard appendix E - creating
DW_TAG_partial_unit compilation units (CUs) for duplicated information
and using DW_TAG_imported_unit to import it into each CU that needs it.
---

Can verify that it does in fact do something with some test binaries on
amd64 (diffing the output of `objdump -g' from a newer binutils does
show substantial differences), but I don't know enough about DWARF
symbols to authoritatively say anything more than that. Testing on other
archs would be greatly appreciated.

OK?

~Brian


dwz.tgz (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: devel/dwz

Marc Espie-2
On Fri, Mar 20, 2020 at 03:22:16PM -0400, Brian Callahan wrote:

> Hello ports --
>
> It was hinted at recently that a port of dwz might be desirable. Here is
> one.
>
> ---
> pkg/DESCR:
> dwz is a program that attempts to optimize DWARF debugging information
> contained in ELF shared libraries and ELF executables for size, by
> replacing DWARF information representation with equivalent smaller
> representation where possible and by reducing the amount of duplication
> using techniques from DWARF standard appendix E - creating
> DW_TAG_partial_unit compilation units (CUs) for duplicated information
> and using DW_TAG_imported_unit to import it into each CU that needs it.
> ---
>
> Can verify that it does in fact do something with some test binaries on
> amd64 (diffing the output of `objdump -g' from a newer binutils does show
> substantial differences), but I don't know enough about DWARF symbols to
> authoritatively say anything more than that. Testing on other archs would be
> greatly appreciated.
>
> OK?
Thanks for the initial work, but you're not thinking straight.

Here's an updated port.

You'll notice the dependencies on gmake and xz are gone, which is
required if we want to use this for DEBUG_PACKAGES eventually ;)

dwz.tgz (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: devel/dwz

Brian Callahan-5


On 2020-03-23 10:54 AM, Marc Espie wrote:

> On Fri, Mar 20, 2020 at 03:22:16PM -0400, Brian Callahan wrote:
>> Hello ports --
>>
>> It was hinted at recently that a port of dwz might be desirable. Here is
>> one.
>>
>> ---
>> pkg/DESCR:
>> dwz is a program that attempts to optimize DWARF debugging information
>> contained in ELF shared libraries and ELF executables for size, by
>> replacing DWARF information representation with equivalent smaller
>> representation where possible and by reducing the amount of duplication
>> using techniques from DWARF standard appendix E - creating
>> DW_TAG_partial_unit compilation units (CUs) for duplicated information
>> and using DW_TAG_imported_unit to import it into each CU that needs it.
>> ---
>>
>> Can verify that it does in fact do something with some test binaries on
>> amd64 (diffing the output of `objdump -g' from a newer binutils does show
>> substantial differences), but I don't know enough about DWARF symbols to
>> authoritatively say anything more than that. Testing on other archs would be
>> greatly appreciated.
>>
>> OK?
> Thanks for the initial work, but you're not thinking straight.
>
> Here's an updated port.
>
> You'll notice the dependencies on gmake and xz are gone, which is
> required if we want to use this for DEBUG_PACKAGES eventually ;)

Unless I'm missing something, you sent me back my own port without changes.
I'm fine with switching to the gz tarball and removing the dependency on
gmake. I get why.

~Brian

Reply | Threaded
Open this post in threaded view
|

Re: NEW: devel/dwz

Marc Espie-2
On Mon, Mar 23, 2020 at 11:08:16AM -0400, Brian Callahan wrote:

>
>
> On 2020-03-23 10:54 AM, Marc Espie wrote:
> > On Fri, Mar 20, 2020 at 03:22:16PM -0400, Brian Callahan wrote:
> > > Hello ports --
> > >
> > > It was hinted at recently that a port of dwz might be desirable. Here is
> > > one.
> > >
> > > ---
> > > pkg/DESCR:
> > > dwz is a program that attempts to optimize DWARF debugging information
> > > contained in ELF shared libraries and ELF executables for size, by
> > > replacing DWARF information representation with equivalent smaller
> > > representation where possible and by reducing the amount of duplication
> > > using techniques from DWARF standard appendix E - creating
> > > DW_TAG_partial_unit compilation units (CUs) for duplicated information
> > > and using DW_TAG_imported_unit to import it into each CU that needs it.
> > > ---
> > >
> > > Can verify that it does in fact do something with some test binaries on
> > > amd64 (diffing the output of `objdump -g' from a newer binutils does show
> > > substantial differences), but I don't know enough about DWARF symbols to
> > > authoritatively say anything more than that. Testing on other archs would be
> > > greatly appreciated.
> > >
> > > OK?
> > Thanks for the initial work, but you're not thinking straight.
> >
> > Here's an updated port.
> >
> > You'll notice the dependencies on gmake and xz are gone, which is
> > required if we want to use this for DEBUG_PACKAGES eventually ;)
>
> Unless I'm missing something, you sent me back my own port without changes.
> I'm fine with switching to the gz tarball and removing the dependency on
> gmake. I get why.
Oops, bad tarball

dwz.tgz (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: devel/dwz

Brian Callahan-5


On 2020-03-23 11:11 AM, Marc Espie wrote:

> On Mon, Mar 23, 2020 at 11:08:16AM -0400, Brian Callahan wrote:
>>
>> On 2020-03-23 10:54 AM, Marc Espie wrote:
>>> On Fri, Mar 20, 2020 at 03:22:16PM -0400, Brian Callahan wrote:
>>>> Hello ports --
>>>>
>>>> It was hinted at recently that a port of dwz might be desirable. Here is
>>>> one.
>>>>
>>>> ---
>>>> pkg/DESCR:
>>>> dwz is a program that attempts to optimize DWARF debugging information
>>>> contained in ELF shared libraries and ELF executables for size, by
>>>> replacing DWARF information representation with equivalent smaller
>>>> representation where possible and by reducing the amount of duplication
>>>> using techniques from DWARF standard appendix E - creating
>>>> DW_TAG_partial_unit compilation units (CUs) for duplicated information
>>>> and using DW_TAG_imported_unit to import it into each CU that needs it.
>>>> ---
>>>>
>>>> Can verify that it does in fact do something with some test binaries on
>>>> amd64 (diffing the output of `objdump -g' from a newer binutils does show
>>>> substantial differences), but I don't know enough about DWARF symbols to
>>>> authoritatively say anything more than that. Testing on other archs would be
>>>> greatly appreciated.
>>>>
>>>> OK?
>>> Thanks for the initial work, but you're not thinking straight.
>>>
>>> Here's an updated port.
>>>
>>> You'll notice the dependencies on gmake and xz are gone, which is
>>> required if we want to use this for DEBUG_PACKAGES eventually ;)
>> Unless I'm missing something, you sent me back my own port without changes.
>> I'm fine with switching to the gz tarball and removing the dependency on
>> gmake. I get why.
> Oops, bad tarball

Like I said before, this is all fine.
At some point, perhaps someone should look into making the tests work. I
have never been able to figure out how to get dejagnu to work so I
disabled them but that might not be ideal.

~Brian

Reply | Threaded
Open this post in threaded view
|

Re: NEW: devel/dwz

Marc Espie-2
On Mon, Mar 23, 2020 at 11:21:40AM -0400, Brian Callahan wrote:

>
>
> On 2020-03-23 11:11 AM, Marc Espie wrote:
> > On Mon, Mar 23, 2020 at 11:08:16AM -0400, Brian Callahan wrote:
> > >
> > > On 2020-03-23 10:54 AM, Marc Espie wrote:
> > > > On Fri, Mar 20, 2020 at 03:22:16PM -0400, Brian Callahan wrote:
> > > > > Hello ports --
> > > > >
> > > > > It was hinted at recently that a port of dwz might be desirable. Here is
> > > > > one.
> > > > >
> > > > > ---
> > > > > pkg/DESCR:
> > > > > dwz is a program that attempts to optimize DWARF debugging information
> > > > > contained in ELF shared libraries and ELF executables for size, by
> > > > > replacing DWARF information representation with equivalent smaller
> > > > > representation where possible and by reducing the amount of duplication
> > > > > using techniques from DWARF standard appendix E - creating
> > > > > DW_TAG_partial_unit compilation units (CUs) for duplicated information
> > > > > and using DW_TAG_imported_unit to import it into each CU that needs it.
> > > > > ---
> > > > >
> > > > > Can verify that it does in fact do something with some test binaries on
> > > > > amd64 (diffing the output of `objdump -g' from a newer binutils does show
> > > > > substantial differences), but I don't know enough about DWARF symbols to
> > > > > authoritatively say anything more than that. Testing on other archs would be
> > > > > greatly appreciated.
> > > > >
> > > > > OK?
> > > > Thanks for the initial work, but you're not thinking straight.
> > > >
> > > > Here's an updated port.
> > > >
> > > > You'll notice the dependencies on gmake and xz are gone, which is
> > > > required if we want to use this for DEBUG_PACKAGES eventually ;)
> > > Unless I'm missing something, you sent me back my own port without changes.
> > > I'm fine with switching to the gz tarball and removing the dependency on
> > > gmake. I get why.
> > Oops, bad tarball
>
> Like I said before, this is all fine.
> At some point, perhaps someone should look into making the tests work. I
> have never been able to figure out how to get dejagnu to work so I disabled
> them but that might not be ideal.

Oh, I'll have a look later.

Please import this. This is mostly your work, I just did a wee little bit
of tinkering ;)

Reply | Threaded
Open this post in threaded view
|

Re: NEW: devel/dwz

Jeremie Courreges-Anglas-2
In reply to this post by Brian Callahan-5
On Mon, Mar 23 2020, Brian Callahan <[hidden email]> wrote:

> On 2020-03-23 11:11 AM, Marc Espie wrote:
>> On Mon, Mar 23, 2020 at 11:08:16AM -0400, Brian Callahan wrote:
>>>
>>> On 2020-03-23 10:54 AM, Marc Espie wrote:
>>>> On Fri, Mar 20, 2020 at 03:22:16PM -0400, Brian Callahan wrote:
>>>>> Hello ports --
>>>>>
>>>>> It was hinted at recently that a port of dwz might be desirable. Here is
>>>>> one.
>>>>>
>>>>> ---
>>>>> pkg/DESCR:
>>>>> dwz is a program that attempts to optimize DWARF debugging information
>>>>> contained in ELF shared libraries and ELF executables for size, by
>>>>> replacing DWARF information representation with equivalent smaller
>>>>> representation where possible and by reducing the amount of duplication
>>>>> using techniques from DWARF standard appendix E - creating
>>>>> DW_TAG_partial_unit compilation units (CUs) for duplicated information
>>>>> and using DW_TAG_imported_unit to import it into each CU that needs it.
>>>>> ---
>>>>>
>>>>> Can verify that it does in fact do something with some test binaries on
>>>>> amd64 (diffing the output of `objdump -g' from a newer binutils does show
>>>>> substantial differences), but I don't know enough about DWARF symbols to
>>>>> authoritatively say anything more than that. Testing on other archs would be
>>>>> greatly appreciated.
>>>>>
>>>>> OK?
>>>> Thanks for the initial work, but you're not thinking straight.
>>>>
>>>> Here's an updated port.
>>>>
>>>> You'll notice the dependencies on gmake and xz are gone, which is
>>>> required if we want to use this for DEBUG_PACKAGES eventually ;)
>>> Unless I'm missing something, you sent me back my own port without changes.
>>> I'm fine with switching to the gz tarball and removing the dependency on
>>> gmake. I get why.
>> Oops, bad tarball
>
> Like I said before, this is all fine.
> At some point, perhaps someone should look into making the tests work.
> I have never been able to figure out how to get dejagnu to work so
> I disabled them but that might not be ideal.

I tried to enable the tests but didn't get anywhere.

Here's an unrelated diff: fix endianness checks.  ok?


Index: Makefile
===================================================================
RCS file: /d/cvs/ports/devel/dwz/Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 Makefile
--- Makefile 24 Mar 2020 17:33:43 -0000 1.2
+++ Makefile 26 Mar 2020 01:11:43 -0000
@@ -2,6 +2,8 @@
 
 COMMENT = DWARF optimization and duplicate removal tool
 DISTNAME = dwz-0.13
+REVISION = 0
+
 CATEGORIES = devel
 
 HOMEPAGE = https://sourceware.org/dwz/
Index: patches/patch-hashtab_c
===================================================================
RCS file: patches/patch-hashtab_c
diff -N patches/patch-hashtab_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-hashtab_c 26 Mar 2020 01:12:27 -0000
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+More portable endianness check
+https://www.austingroupbugs.net/view.php?id=162#c665
+
+Index: hashtab.c
+--- hashtab.c.orig
++++ hashtab.c
+@@ -38,7 +38,7 @@ Boston, MA 02110-1301, USA.  */
+ #include "hashtab.h"
+
+ #include <endian.h>
+-#if __BYTE_ORDER == __BIG_ENDIAN
++#if BYTE_ORDER == BIG_ENDIAN
+ # define WORDS_BIGENDIAN 1
+ #endif
+
Index: patches/patch-sha1_c
===================================================================
RCS file: patches/patch-sha1_c
diff -N patches/patch-sha1_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-sha1_c 26 Mar 2020 01:12:17 -0000
@@ -0,0 +1,17 @@
+$OpenBSD$
+
+More portable endianness check
+https://www.austingroupbugs.net/view.php?id=162#c665
+
+Index: sha1.c
+--- sha1.c.orig
++++ sha1.c
+@@ -29,7 +29,7 @@
+ #include <string.h>
+ #include <endian.h>
+
+-#if __BYTE_ORDER == __BIG_ENDIAN
++#if BYTE_ORDER == BIG_ENDIAN
+ # define SWAP(n) (n)
+ #else
+ # define SWAP(n) \


--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: NEW: devel/dwz

Brian Callahan-5


On 2020-03-25 9:24 PM, Jeremie Courreges-Anglas wrote:

> On Mon, Mar 23 2020, Brian Callahan <[hidden email]> wrote:
>> On 2020-03-23 11:11 AM, Marc Espie wrote:
>>> On Mon, Mar 23, 2020 at 11:08:16AM -0400, Brian Callahan wrote:
>>>> On 2020-03-23 10:54 AM, Marc Espie wrote:
>>>>> On Fri, Mar 20, 2020 at 03:22:16PM -0400, Brian Callahan wrote:
>>>>>> Hello ports --
>>>>>>
>>>>>> It was hinted at recently that a port of dwz might be desirable. Here is
>>>>>> one.
>>>>>>
>>>>>> ---
>>>>>> pkg/DESCR:
>>>>>> dwz is a program that attempts to optimize DWARF debugging information
>>>>>> contained in ELF shared libraries and ELF executables for size, by
>>>>>> replacing DWARF information representation with equivalent smaller
>>>>>> representation where possible and by reducing the amount of duplication
>>>>>> using techniques from DWARF standard appendix E - creating
>>>>>> DW_TAG_partial_unit compilation units (CUs) for duplicated information
>>>>>> and using DW_TAG_imported_unit to import it into each CU that needs it.
>>>>>> ---
>>>>>>
>>>>>> Can verify that it does in fact do something with some test binaries on
>>>>>> amd64 (diffing the output of `objdump -g' from a newer binutils does show
>>>>>> substantial differences), but I don't know enough about DWARF symbols to
>>>>>> authoritatively say anything more than that. Testing on other archs would be
>>>>>> greatly appreciated.
>>>>>>
>>>>>> OK?
>>>>> Thanks for the initial work, but you're not thinking straight.
>>>>>
>>>>> Here's an updated port.
>>>>>
>>>>> You'll notice the dependencies on gmake and xz are gone, which is
>>>>> required if we want to use this for DEBUG_PACKAGES eventually ;)
>>>> Unless I'm missing something, you sent me back my own port without changes.
>>>> I'm fine with switching to the gz tarball and removing the dependency on
>>>> gmake. I get why.
>>> Oops, bad tarball
>> Like I said before, this is all fine.
>> At some point, perhaps someone should look into making the tests work.
>> I have never been able to figure out how to get dejagnu to work so
>> I disabled them but that might not be ideal.
> I tried to enable the tests but didn't get anywhere.
>
> Here's an unrelated diff: fix endianness checks.  ok?

I don't have any reliable BE machines at the moment but hoping to remedy
that soon. But yes ok for this as I'm guessing it improves things there.

~Brian

>
> Index: Makefile
> ===================================================================
> RCS file: /d/cvs/ports/devel/dwz/Makefile,v
> retrieving revision 1.2
> diff -u -p -r1.2 Makefile
> --- Makefile 24 Mar 2020 17:33:43 -0000 1.2
> +++ Makefile 26 Mar 2020 01:11:43 -0000
> @@ -2,6 +2,8 @@
>  
>   COMMENT = DWARF optimization and duplicate removal tool
>   DISTNAME = dwz-0.13
> +REVISION = 0
> +
>   CATEGORIES = devel
>  
>   HOMEPAGE = https://sourceware.org/dwz/
> Index: patches/patch-hashtab_c
> ===================================================================
> RCS file: patches/patch-hashtab_c
> diff -N patches/patch-hashtab_c
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-hashtab_c 26 Mar 2020 01:12:27 -0000
> @@ -0,0 +1,17 @@
> +$OpenBSD$
> +
> +More portable endianness check
> +https://www.austingroupbugs.net/view.php?id=162#c665
> +
> +Index: hashtab.c
> +--- hashtab.c.orig
> ++++ hashtab.c
> +@@ -38,7 +38,7 @@ Boston, MA 02110-1301, USA.  */
> + #include "hashtab.h"
> +
> + #include <endian.h>
> +-#if __BYTE_ORDER == __BIG_ENDIAN
> ++#if BYTE_ORDER == BIG_ENDIAN
> + # define WORDS_BIGENDIAN 1
> + #endif
> +
> Index: patches/patch-sha1_c
> ===================================================================
> RCS file: patches/patch-sha1_c
> diff -N patches/patch-sha1_c
> --- /dev/null 1 Jan 1970 00:00:00 -0000
> +++ patches/patch-sha1_c 26 Mar 2020 01:12:17 -0000
> @@ -0,0 +1,17 @@
> +$OpenBSD$
> +
> +More portable endianness check
> +https://www.austingroupbugs.net/view.php?id=162#c665
> +
> +Index: sha1.c
> +--- sha1.c.orig
> ++++ sha1.c
> +@@ -29,7 +29,7 @@
> + #include <string.h>
> + #include <endian.h>
> +
> +-#if __BYTE_ORDER == __BIG_ENDIAN
> ++#if BYTE_ORDER == BIG_ENDIAN
> + # define SWAP(n) (n)
> + #else
> + # define SWAP(n) \
>
>