Re: [rfa] save space by using enum bitfields

Re: [rfa] save space by using enum bitfields

[Michael Elizabeth Chastain]

Here is some more data on a larger dataset.

The target program is a specific gdb.exe file with
LD_LIBRARY_PATH set to /usr/lib/debug, so that I am getting
glibc-2.2.93-5-rh with debugging symbols turned on.

I use "gdb -readnow" to read all the symbols on startup.
That increases memory usage from 20 megabytes to 100 megabytes.

'ps axuww' says:

  old: 117280 k
  new: 108112 k

'maint space 1' says:

  old: 99352576
  new: 89997312

This is 8% to 10% savings here on a 100 megabyte process.

Michael C

Re: [rfa] save space by using enum bitfields

[Jim Blandy]

Okay, I'm sold.  Looks good to commit to me.

Michael Elizabeth Chastain <mec@shout.net> writes:

> Here is some more data on a larger dataset.
> 
> The target program is a specific gdb.exe file with
> LD_LIBRARY_PATH set to /usr/lib/debug, so that I am getting
> glibc-2.2.93-5-rh with debugging symbols turned on.
> 
> I use "gdb -readnow" to read all the symbols on startup.
> That increases memory usage from 20 megabytes to 100 megabytes.
> 
> 'ps axuww' says:
> 
>   old: 117280 k
>   new: 108112 k
> 
> 'maint space 1' says:
> 
>   old: 99352576
>   new: 89997312
> 
> This is 8% to 10% savings here on a 100 megabyte process.

Re: [rfa] save space by using enum bitfields

[Michael Elizabeth Chastain]

For people tracking patches:

This patch is withdrawn for rework.  It was drawing a gcc
warning about an enum definition nested in a struct definition.

Seems like this is fine:

  struct s { enum e { one, two, three } e1; };

But this is not:

  struct s { enum e { one, two, three }; enum e e1; };

So I gotta refactor:

  enum e { one, two, three };
  struct s { enum e e1; };

Michael C

===

2003-08-17  Michael Chastain  <mec@shout.net>

	* defs.h (ENUM_BITFIELD): New macro.
	* symtab.h (ENUM_BITFIELD): Use it.
	(BYTE_BITFIELD): Remove old macro, which was already disabled.

Re: [rfa] save space by using enum bitfields

[Michael Elizabeth Chastain]

Rats, I found a bug in my patch.  Too bad you didn't approve it
before I found the bug.  :)

The bug is that the old code has some of this:

  struct minimal_symbol
  {
    ...
    enum minimal_symbol_type { ... } type BYTE_BITFIELD;
    ...
  };

My patch has this:

  struct minimal_symbol
  {
    ...
    enum minimal_symbol_type { ... };
    BITFIELD_ENUM(minimal_symbol_type) type : 8
    ...
  };

gcc 3.3.1 emits warnings for the declaration of enum inside struct.
And gcc 3.2-7-rh emits errors for this!

So I have to do:

  enum minimal_symbol_type
  {
    ...
  };

  struct minimal_symbol
  {
    ...
    BITFIELD_ENUM(minimal_symbol_type) type : 8;
  };

I am preparing a new patch now.  It's actually shorter than the
old patch, because I gave up on struct symtab (this is not a
space critical struct and it has one of those pesky embedded
enum definitions, so it's a bunch of patching for little space
savings).

Michael C

Re: [rfa] save space by using enum bitfields

[Jim Blandy]

Michael Elizabeth Chastain <mec@shout.net> writes:

> Rats, I found a bug in my patch.  Too bad you didn't approve it
> before I found the bug.  :)
> 
> The bug is that the old code has some of this:
> 
>   struct minimal_symbol
>   {
>     ...
>     enum minimal_symbol_type { ... } type BYTE_BITFIELD;
>     ...
>   };
> 
> My patch has this:
> 
>   struct minimal_symbol
>   {
>     ...
>     enum minimal_symbol_type { ... };
>     BITFIELD_ENUM(minimal_symbol_type) type : 8
>     ...
>   };
> 
> gcc 3.3.1 emits warnings for the declaration of enum inside struct.
> And gcc 3.2-7-rh emits errors for this!

I did notice that, actually, and went looking through the ISO C spec
to see whether it was kosher.  ISO C says that there are only four
kinds of scope: function, block, file, and prototype.  So those enums
should have file scope, which is what you want.

But if GCC doesn't like it, okay.  *shrug*

Re: [rfa] save space by using enum bitfields

[Michael Elizabeth Chastain]

There are a variety of semi-ugly ways to write this.  Andrew C
mentioned that he wanted to re-use the same way that gcc uses.
I like that.

Also I would prefer to keep the ": 8" in the structure definition
rather than stick it into the macro.  Some of these enum's need
even less space than 8 bits and we might get into some better
packing that way.

As far as the size goes, I will try my test case with "-readnow"
to suck in all the symbols from the target executable and its
shared libraries (gdb + libc).  With the old gdb, this takes
117280 kilobytes, most of which has to be symbol table related.

Michael C

Re: [rfa] save space by using enum bitfields

[Andrew Cagney]

> There are a variety of semi-ugly ways to write this.  Andrew C
> mentioned that he wanted to re-use the same way that gcc uses.
> I like that.

Yep.  It sux.  But at least it's consistent with GCC, and since they've 
been using it for ages, we're on pretty safe ground.

Andrew

> Also I would prefer to keep the ": 8" in the structure definition
> rather than stick it into the macro.  Some of these enum's need
> even less space than 8 bits and we might get into some better
> packing that way.
> 
> As far as the size goes, I will try my test case with "-readnow"
> to suck in all the symbols from the target executable and its
> shared libraries (gdb + libc).  With the old gdb, this takes
> 117280 kilobytes, most of which has to be symbol table related.
> 
> Michael C

[rfa] save space by using enum bitfields

[Michael Elizabeth Chastain]

This adds an ENUM_BITFIELD macro to defs.h and uses it in the
symbol table to save space.

Per Andrew C, this version uses the same macro that gcc 3.3.1, for the
sake of inter-project consistency.  The macro is in defs.h so that
any structure definition can use it, if they want.

In gcc land, Zack Weinberg originally did an autoconf test, but then he
ran into platforms where the autoconf test succeeded but the compiler
generated buggy code.  So now gcc does an explicit test on the compiler
used (gcc version 2 or later).  I wrote this patch the same way.

If the compiler does not give us enum bitfields, then we can choose
between integer bitfields (still save space) or full-width enum
(chew up space, improve debugability).  The gcc code chose the
former, so I followed it.

Testing: I ran the test suite with gcc v2 and v3, dwarf-2 and stabs+,
binutils 2.14.  I also tested the non-gcc case by putting an "#if 0"
into the feature test in order to get the non-gcc path.

Size reduction (on my vanilla native i686-pc-linux-gnu):

  struct general_symbol_info  24  20
  struct minimal_symbol       44  40
  struct symbol               60  48
  struct partial_symbol       32  24
  struct symtab               68  64

I also loaded a medium-sized program (a specific version of gdb) with a
debugging version of libc and measured memory usage at the first command
prompt with 'ps axu'.  Total memory usage dropped from 23420 kilobytes
to 23280 kilobytes, a savings of 0.6%.  Sigh.

Comments?

OK to apply?

Michael C

2003-08-17  Michael Chastain  <mec@shout.net>

	* defs.h (ENUM_BITFIELD): New macro.
	* symtab.h (ENUM_BITFIELD): Use it.
	(BYTE_BITFIELD): Remove old macro, which was already disabled.

Index: defs.h
===================================================================
RCS file: /cvs/src/src/gdb/defs.h,v
retrieving revision 1.127
diff -c -3 -p -r1.127 defs.h
*** defs.h	9 Aug 2003 14:57:30 -0000	1.127
--- defs.h	17 Aug 2003 23:17:26 -0000
*************** struct cleanup
*** 285,290 ****
--- 285,299 ----
  #endif
  #endif
  
+ /* Be conservative and use enum bitfields only with GCC.
+    This is copied from gcc 3.3.1, system.h.  */
+ 
+ #if defined(__GNUC__) && (__GNUC__ >= 2)
+ #define ENUM_BITFIELD(TYPE) enum TYPE
+ #else
+ #define ENUM_BITFIELD(TYPE) unsigned int
+ #endif
+ 
  /* Needed for various prototypes */
  
  struct symtab;
Index: symtab.h
===================================================================
RCS file: /cvs/src/src/gdb/symtab.h,v
retrieving revision 1.77
diff -c -3 -p -r1.77 symtab.h
*** symtab.h	22 Jul 2003 15:41:59 -0000	1.77
--- symtab.h	17 Aug 2003 23:17:28 -0000
*************** struct blockvector;
*** 35,51 ****
  struct axs_value;
  struct agent_expr;
  
- /* Don't do this; it means that if some .o's are compiled with GNU C
-    and some are not (easy to do accidentally the way we configure
-    things; also it is a pain to have to "make clean" every time you
-    want to switch compilers), then GDB dies a horrible death.  */
- /* GNU C supports enums that are bitfields.  Some compilers don't. */
- #if 0 && defined(__GNUC__) && !defined(BYTE_BITFIELD)
- #define	BYTE_BITFIELD	:8;
- #else
- #define	BYTE_BITFIELD		/*nothing */
- #endif
- 
  /* Define a structure for the information that is common to all symbol types,
     including minimal symbols, partial symbols, and full symbols.  In a
     multilanguage environment, some language specific information may need to
--- 35,40 ----
*************** struct general_symbol_info
*** 107,113 ****
       This is used to select one of the fields from the language specific
       union above. */
  
!   enum language language BYTE_BITFIELD;
  
    /* Which section is this symbol in?  This is an index into
       section_offsets for this objfile.  Negative means that the symbol
--- 96,102 ----
       This is used to select one of the fields from the language specific
       union above. */
  
!   ENUM_BITFIELD(language) language : 8;
  
    /* Which section is this symbol in?  This is an index into
       section_offsets for this objfile.  Negative means that the symbol
*************** struct minimal_symbol
*** 297,304 ****
      mst_file_text,		/* Static version of mst_text */
      mst_file_data,		/* Static version of mst_data */
      mst_file_bss		/* Static version of mst_bss */
!   }
!   type BYTE_BITFIELD;
  
    /* Minimal symbols with the same hash key are kept on a linked
       list.  This is the link.  */
--- 286,294 ----
      mst_file_text,		/* Static version of mst_text */
      mst_file_data,		/* Static version of mst_data */
      mst_file_bss		/* Static version of mst_bss */
!   };
! 
!   ENUM_BITFIELD(minimal_symbol_type) type : 8;
  
    /* Minimal symbols with the same hash key are kept on a linked
       list.  This is the link.  */
*************** struct minimal_symbol
*** 321,327 ****
  /* Different name domains for symbols.  Looking up a symbol specifies a
     domain and ignores symbol definitions in other name domains. */
  
! typedef enum
  {
    /* UNDEF_DOMAIN is used when a domain has not been discovered or
       none of the following apply.  This usually indicates an error either
--- 311,317 ----
  /* Different name domains for symbols.  Looking up a symbol specifies a
     domain and ignores symbol definitions in other name domains. */
  
! typedef enum domain_enum_tag
  {
    /* UNDEF_DOMAIN is used when a domain has not been discovered or
       none of the following apply.  This usually indicates an error either
*************** struct symbol
*** 578,588 ****
  
    /* Domain code.  */
  
!   domain_enum domain BYTE_BITFIELD;
  
    /* Address class */
  
!   enum address_class aclass BYTE_BITFIELD;
  
    /* Line number of definition.  FIXME:  Should we really make the assumption
       that nobody will try to debug files longer than 64K lines?  What about
--- 568,578 ----
  
    /* Domain code.  */
  
!   ENUM_BITFIELD(domain_enum_tag) domain : 8;
  
    /* Address class */
  
!   ENUM_BITFIELD(address_class) aclass : 8;
  
    /* Line number of definition.  FIXME:  Should we really make the assumption
       that nobody will try to debug files longer than 64K lines?  What about
*************** struct partial_symbol
*** 655,665 ****
  
    /* Name space code.  */
  
!   domain_enum domain BYTE_BITFIELD;
  
    /* Address class (for info_symbols) */
  
!   enum address_class aclass BYTE_BITFIELD;
  
  };
  
--- 645,655 ----
  
    /* Name space code.  */
  
!   ENUM_BITFIELD(domain_enum_tag) domain : 8;
  
    /* Address class (for info_symbols) */
  
!   ENUM_BITFIELD(address_class) aclass : 8;
  
  };
  
*************** struct symtab
*** 775,793 ****
  
    char *dirname;
  
-   /* This component says how to free the data we point to:
-      free_contents => do a tree walk and free each object.
-      free_nothing => do nothing; some other symtab will free
-      the data this one uses.
-      free_linetable => free just the linetable.  FIXME: Is this redundant
-      with the primary field?  */
- 
-   enum free_code
-   {
-     free_nothing, free_contents, free_linetable
-   }
-   free_code;
- 
    /* A function to call to free space, if necessary.  This is IN
       ADDITION to the action indicated by free_code.  */
  
--- 765,770 ----
*************** struct symtab
*** 803,811 ****
  
    int *line_charpos;
  
    /* Language of this source file.  */
  
!   enum language language;
  
    /* String that identifies the format of the debugging information, such
       as "stabs", "dwarf 1", "dwarf 2", "coff", etc.  This is mostly useful
--- 780,802 ----
  
    int *line_charpos;
  
+   /* This component says how to free the data we point to:
+      free_contents => do a tree walk and free each object.
+      free_nothing => do nothing; some other symtab will free
+      the data this one uses.
+      free_linetable => free just the linetable.  FIXME: Is this redundant
+      with the primary field?  */
+ 
+   enum free_code
+   {
+     free_nothing, free_contents, free_linetable
+   };
+ 
+   ENUM_BITFIELD(free_code) free_code : 8;
+ 
    /* Language of this source file.  */
  
!   ENUM_BITFIELD(language) language : 8;
  
    /* String that identifies the format of the debugging information, such
       as "stabs", "dwarf 1", "dwarf 2", "coff", etc.  This is mostly useful

Re: [rfa] save space by using enum bitfields

[Michael Snyder]

I gotta say, this looks like uglification to me.  Is it worth it?

Michael Elizabeth Chastain wrote:

>This adds an ENUM_BITFIELD macro to defs.h and uses it in the
>symbol table to save space.
>
>Per Andrew C, this version uses the same macro that gcc 3.3.1, for the
>sake of inter-project consistency.  The macro is in defs.h so that
>any structure definition can use it, if they want.
>
>In gcc land, Zack Weinberg originally did an autoconf test, but then he
>ran into platforms where the autoconf test succeeded but the compiler
>generated buggy code.  So now gcc does an explicit test on the compiler
>used (gcc version 2 or later).  I wrote this patch the same way.
>
>If the compiler does not give us enum bitfields, then we can choose
>between integer bitfields (still save space) or full-width enum
>(chew up space, improve debugability).  The gcc code chose the
>former, so I followed it.
>
>Testing: I ran the test suite with gcc v2 and v3, dwarf-2 and stabs+,
>binutils 2.14.  I also tested the non-gcc case by putting an "#if 0"
>into the feature test in order to get the non-gcc path.
>
>Size reduction (on my vanilla native i686-pc-linux-gnu):
>
>  struct general_symbol_info  24  20
>  struct minimal_symbol       44  40
>  struct symbol               60  48
>  struct partial_symbol       32  24
>  struct symtab               68  64
>
>I also loaded a medium-sized program (a specific version of gdb) with a
>debugging version of libc and measured memory usage at the first command
>prompt with 'ps axu'.  Total memory usage dropped from 23420 kilobytes
>to 23280 kilobytes, a savings of 0.6%.  Sigh.
>
>Comments?
>
>OK to apply?
>
>Michael C
>
>2003-08-17  Michael Chastain  <mec@shout.net>
>
>	* defs.h (ENUM_BITFIELD): New macro.
>	* symtab.h (ENUM_BITFIELD): Use it.
>	(BYTE_BITFIELD): Remove old macro, which was already disabled.
>
>Index: defs.h
>===================================================================
>RCS file: /cvs/src/src/gdb/defs.h,v
>retrieving revision 1.127
>diff -c -3 -p -r1.127 defs.h
>*** defs.h	9 Aug 2003 14:57:30 -0000	1.127
>--- defs.h	17 Aug 2003 23:17:26 -0000
>*************** struct cleanup
>*** 285,290 ****
>--- 285,299 ----
>  #endif
>  #endif
>  
>+ /* Be conservative and use enum bitfields only with GCC.
>+    This is copied from gcc 3.3.1, system.h.  */
>+ 
>+ #if defined(__GNUC__) && (__GNUC__ >= 2)
>+ #define ENUM_BITFIELD(TYPE) enum TYPE
>+ #else
>+ #define ENUM_BITFIELD(TYPE) unsigned int
>+ #endif
>+ 
>  /* Needed for various prototypes */
>  
>  struct symtab;
>Index: symtab.h
>===================================================================
>RCS file: /cvs/src/src/gdb/symtab.h,v
>retrieving revision 1.77
>diff -c -3 -p -r1.77 symtab.h
>*** symtab.h	22 Jul 2003 15:41:59 -0000	1.77
>--- symtab.h	17 Aug 2003 23:17:28 -0000
>*************** struct blockvector;
>*** 35,51 ****
>  struct axs_value;
>  struct agent_expr;
>  
>- /* Don't do this; it means that if some .o's are compiled with GNU C
>-    and some are not (easy to do accidentally the way we configure
>-    things; also it is a pain to have to "make clean" every time you
>-    want to switch compilers), then GDB dies a horrible death.  */
>- /* GNU C supports enums that are bitfields.  Some compilers don't. */
>- #if 0 && defined(__GNUC__) && !defined(BYTE_BITFIELD)
>- #define	BYTE_BITFIELD	:8;
>- #else
>- #define	BYTE_BITFIELD		/*nothing */
>- #endif
>- 
>  /* Define a structure for the information that is common to all symbol types,
>     including minimal symbols, partial symbols, and full symbols.  In a
>     multilanguage environment, some language specific information may need to
>--- 35,40 ----
>*************** struct general_symbol_info
>*** 107,113 ****
>       This is used to select one of the fields from the language specific
>       union above. */
>  
>!   enum language language BYTE_BITFIELD;
>  
>    /* Which section is this symbol in?  This is an index into
>       section_offsets for this objfile.  Negative means that the symbol
>--- 96,102 ----
>       This is used to select one of the fields from the language specific
>       union above. */
>  
>!   ENUM_BITFIELD(language) language : 8;
>  
>    /* Which section is this symbol in?  This is an index into
>       section_offsets for this objfile.  Negative means that the symbol
>*************** struct minimal_symbol
>*** 297,304 ****
>      mst_file_text,		/* Static version of mst_text */
>      mst_file_data,		/* Static version of mst_data */
>      mst_file_bss		/* Static version of mst_bss */
>!   }
>!   type BYTE_BITFIELD;
>  
>    /* Minimal symbols with the same hash key are kept on a linked
>       list.  This is the link.  */
>--- 286,294 ----
>      mst_file_text,		/* Static version of mst_text */
>      mst_file_data,		/* Static version of mst_data */
>      mst_file_bss		/* Static version of mst_bss */
>!   };
>! 
>!   ENUM_BITFIELD(minimal_symbol_type) type : 8;
>  
>    /* Minimal symbols with the same hash key are kept on a linked
>       list.  This is the link.  */
>*************** struct minimal_symbol
>*** 321,327 ****
>  /* Different name domains for symbols.  Looking up a symbol specifies a
>     domain and ignores symbol definitions in other name domains. */
>  
>! typedef enum
>  {
>    /* UNDEF_DOMAIN is used when a domain has not been discovered or
>       none of the following apply.  This usually indicates an error either
>--- 311,317 ----
>  /* Different name domains for symbols.  Looking up a symbol specifies a
>     domain and ignores symbol definitions in other name domains. */
>  
>! typedef enum domain_enum_tag
>  {
>    /* UNDEF_DOMAIN is used when a domain has not been discovered or
>       none of the following apply.  This usually indicates an error either
>*************** struct symbol
>*** 578,588 ****
>  
>    /* Domain code.  */
>  
>!   domain_enum domain BYTE_BITFIELD;
>  
>    /* Address class */
>  
>!   enum address_class aclass BYTE_BITFIELD;
>  
>    /* Line number of definition.  FIXME:  Should we really make the assumption
>       that nobody will try to debug files longer than 64K lines?  What about
>--- 568,578 ----
>  
>    /* Domain code.  */
>  
>!   ENUM_BITFIELD(domain_enum_tag) domain : 8;
>  
>    /* Address class */
>  
>!   ENUM_BITFIELD(address_class) aclass : 8;
>  
>    /* Line number of definition.  FIXME:  Should we really make the assumption
>       that nobody will try to debug files longer than 64K lines?  What about
>*************** struct partial_symbol
>*** 655,665 ****
>  
>    /* Name space code.  */
>  
>!   domain_enum domain BYTE_BITFIELD;
>  
>    /* Address class (for info_symbols) */
>  
>!   enum address_class aclass BYTE_BITFIELD;
>  
>  };
>  
>--- 645,655 ----
>  
>    /* Name space code.  */
>  
>!   ENUM_BITFIELD(domain_enum_tag) domain : 8;
>  
>    /* Address class (for info_symbols) */
>  
>!   ENUM_BITFIELD(address_class) aclass : 8;
>  
>  };
>  
>*************** struct symtab
>*** 775,793 ****
>  
>    char *dirname;
>  
>-   /* This component says how to free the data we point to:
>-      free_contents => do a tree walk and free each object.
>-      free_nothing => do nothing; some other symtab will free
>-      the data this one uses.
>-      free_linetable => free just the linetable.  FIXME: Is this redundant
>-      with the primary field?  */
>- 
>-   enum free_code
>-   {
>-     free_nothing, free_contents, free_linetable
>-   }
>-   free_code;
>- 
>    /* A function to call to free space, if necessary.  This is IN
>       ADDITION to the action indicated by free_code.  */
>  
>--- 765,770 ----
>*************** struct symtab
>*** 803,811 ****
>  
>    int *line_charpos;
>  
>    /* Language of this source file.  */
>  
>!   enum language language;
>  
>    /* String that identifies the format of the debugging information, such
>       as "stabs", "dwarf 1", "dwarf 2", "coff", etc.  This is mostly useful
>--- 780,802 ----
>  
>    int *line_charpos;
>  
>+   /* This component says how to free the data we point to:
>+      free_contents => do a tree walk and free each object.
>+      free_nothing => do nothing; some other symtab will free
>+      the data this one uses.
>+      free_linetable => free just the linetable.  FIXME: Is this redundant
>+      with the primary field?  */
>+ 
>+   enum free_code
>+   {
>+     free_nothing, free_contents, free_linetable
>+   };
>+ 
>+   ENUM_BITFIELD(free_code) free_code : 8;
>+ 
>    /* Language of this source file.  */
>  
>!   ENUM_BITFIELD(language) language : 8;
>  
>    /* String that identifies the format of the debugging information, such
>       as "stabs", "dwarf 1", "dwarf 2", "coff", etc.  This is mostly useful
>
>  
>

Re: [rfa] save space by using enum bitfields

[Daniel Jacobowitz]

Well, I'd say that 20% off the size of struct symbol is pretty good. 
It makes the idea of unifying our symbol tables to have only one kind
of symbol much more practical.

On Mon, Aug 18, 2003 at 01:49:56PM -0700, Michael Snyder wrote:
> I gotta say, this looks like uglification to me.  Is it worth it?
> 
> Michael Elizabeth Chastain wrote:
> 
> >This adds an ENUM_BITFIELD macro to defs.h and uses it in the
> >symbol table to save space.
> >
> >Per Andrew C, this version uses the same macro that gcc 3.3.1, for the
> >sake of inter-project consistency.  The macro is in defs.h so that
> >any structure definition can use it, if they want.
> >
> >In gcc land, Zack Weinberg originally did an autoconf test, but then he
> >ran into platforms where the autoconf test succeeded but the compiler
> >generated buggy code.  So now gcc does an explicit test on the compiler
> >used (gcc version 2 or later).  I wrote this patch the same way.
> >
> >If the compiler does not give us enum bitfields, then we can choose
> >between integer bitfields (still save space) or full-width enum
> >(chew up space, improve debugability).  The gcc code chose the
> >former, so I followed it.
> >
> >Testing: I ran the test suite with gcc v2 and v3, dwarf-2 and stabs+,
> >binutils 2.14.  I also tested the non-gcc case by putting an "#if 0"
> >into the feature test in order to get the non-gcc path.
> >
> >Size reduction (on my vanilla native i686-pc-linux-gnu):
> >
> > struct general_symbol_info  24  20
> > struct minimal_symbol       44  40
> > struct symbol               60  48
> > struct partial_symbol       32  24
> > struct symtab               68  64
> >
> >I also loaded a medium-sized program (a specific version of gdb) with a
> >debugging version of libc and measured memory usage at the first command
> >prompt with 'ps axu'.  Total memory usage dropped from 23420 kilobytes
> >to 23280 kilobytes, a savings of 0.6%.  Sigh.
> >
> >Comments?
> >
> >OK to apply?
> >
> >Michael C
> >
> >2003-08-17  Michael Chastain  <mec@shout.net>
> >
> >	* defs.h (ENUM_BITFIELD): New macro.
> >	* symtab.h (ENUM_BITFIELD): Use it.
> >	(BYTE_BITFIELD): Remove old macro, which was already disabled.
> >
> >Index: defs.h
> >===================================================================
> >RCS file: /cvs/src/src/gdb/defs.h,v
> >retrieving revision 1.127
> >diff -c -3 -p -r1.127 defs.h
> >*** defs.h	9 Aug 2003 14:57:30 -0000	1.127
> >--- defs.h	17 Aug 2003 23:17:26 -0000
> >*************** struct cleanup
> >*** 285,290 ****
> >--- 285,299 ----
> > #endif
> > #endif
> > 
> >+ /* Be conservative and use enum bitfields only with GCC.
> >+    This is copied from gcc 3.3.1, system.h.  */
> >+ 
> >+ #if defined(__GNUC__) && (__GNUC__ >= 2)
> >+ #define ENUM_BITFIELD(TYPE) enum TYPE
> >+ #else
> >+ #define ENUM_BITFIELD(TYPE) unsigned int
> >+ #endif
> >+ 
> > /* Needed for various prototypes */
> > 
> > struct symtab;
> >Index: symtab.h
> >===================================================================
> >RCS file: /cvs/src/src/gdb/symtab.h,v
> >retrieving revision 1.77
> >diff -c -3 -p -r1.77 symtab.h
> >*** symtab.h	22 Jul 2003 15:41:59 -0000	1.77
> >--- symtab.h	17 Aug 2003 23:17:28 -0000
> >*************** struct blockvector;
> >*** 35,51 ****
> > struct axs_value;
> > struct agent_expr;
> > 
> >- /* Don't do this; it means that if some .o's are compiled with GNU C
> >-    and some are not (easy to do accidentally the way we configure
> >-    things; also it is a pain to have to "make clean" every time you
> >-    want to switch compilers), then GDB dies a horrible death.  */
> >- /* GNU C supports enums that are bitfields.  Some compilers don't. */
> >- #if 0 && defined(__GNUC__) && !defined(BYTE_BITFIELD)
> >- #define	BYTE_BITFIELD	:8;
> >- #else
> >- #define	BYTE_BITFIELD		/*nothing */
> >- #endif
> >- 
> > /* Define a structure for the information that is common to all symbol 
> > types,
> >    including minimal symbols, partial symbols, and full symbols.  In a
> >    multilanguage environment, some language specific information may need 
> >    to
> >--- 35,40 ----
> >*************** struct general_symbol_info
> >*** 107,113 ****
> >      This is used to select one of the fields from the language specific
> >      union above. */
> > 
> >!   enum language language BYTE_BITFIELD;
> > 
> >   /* Which section is this symbol in?  This is an index into
> >      section_offsets for this objfile.  Negative means that the symbol
> >--- 96,102 ----
> >      This is used to select one of the fields from the language specific
> >      union above. */
> > 
> >!   ENUM_BITFIELD(language) language : 8;
> > 
> >   /* Which section is this symbol in?  This is an index into
> >      section_offsets for this objfile.  Negative means that the symbol
> >*************** struct minimal_symbol
> >*** 297,304 ****
> >     mst_file_text,		/* Static version of mst_text */
> >     mst_file_data,		/* Static version of mst_data */
> >     mst_file_bss		/* Static version of mst_bss */
> >!   }
> >!   type BYTE_BITFIELD;
> > 
> >   /* Minimal symbols with the same hash key are kept on a linked
> >      list.  This is the link.  */
> >--- 286,294 ----
> >     mst_file_text,		/* Static version of mst_text */
> >     mst_file_data,		/* Static version of mst_data */
> >     mst_file_bss		/* Static version of mst_bss */
> >!   };
> >! 
> >!   ENUM_BITFIELD(minimal_symbol_type) type : 8;
> > 
> >   /* Minimal symbols with the same hash key are kept on a linked
> >      list.  This is the link.  */
> >*************** struct minimal_symbol
> >*** 321,327 ****
> > /* Different name domains for symbols.  Looking up a symbol specifies a
> >    domain and ignores symbol definitions in other name domains. */
> > 
> >! typedef enum
> > {
> >   /* UNDEF_DOMAIN is used when a domain has not been discovered or
> >      none of the following apply.  This usually indicates an error either
> >--- 311,317 ----
> > /* Different name domains for symbols.  Looking up a symbol specifies a
> >    domain and ignores symbol definitions in other name domains. */
> > 
> >! typedef enum domain_enum_tag
> > {
> >   /* UNDEF_DOMAIN is used when a domain has not been discovered or
> >      none of the following apply.  This usually indicates an error either
> >*************** struct symbol
> >*** 578,588 ****
> > 
> >   /* Domain code.  */
> > 
> >!   domain_enum domain BYTE_BITFIELD;
> > 
> >   /* Address class */
> > 
> >!   enum address_class aclass BYTE_BITFIELD;
> > 
> >   /* Line number of definition.  FIXME:  Should we really make the 
> >   assumption
> >      that nobody will try to debug files longer than 64K lines?  What 
> >      about
> >--- 568,578 ----
> > 
> >   /* Domain code.  */
> > 
> >!   ENUM_BITFIELD(domain_enum_tag) domain : 8;
> > 
> >   /* Address class */
> > 
> >!   ENUM_BITFIELD(address_class) aclass : 8;
> > 
> >   /* Line number of definition.  FIXME:  Should we really make the 
> >   assumption
> >      that nobody will try to debug files longer than 64K lines?  What 
> >      about
> >*************** struct partial_symbol
> >*** 655,665 ****
> > 
> >   /* Name space code.  */
> > 
> >!   domain_enum domain BYTE_BITFIELD;
> > 
> >   /* Address class (for info_symbols) */
> > 
> >!   enum address_class aclass BYTE_BITFIELD;
> > 
> > };
> > 
> >--- 645,655 ----
> > 
> >   /* Name space code.  */
> > 
> >!   ENUM_BITFIELD(domain_enum_tag) domain : 8;
> > 
> >   /* Address class (for info_symbols) */
> > 
> >!   ENUM_BITFIELD(address_class) aclass : 8;
> > 
> > };
> > 
> >*************** struct symtab
> >*** 775,793 ****
> > 
> >   char *dirname;
> > 
> >-   /* This component says how to free the data we point to:
> >-      free_contents => do a tree walk and free each object.
> >-      free_nothing => do nothing; some other symtab will free
> >-      the data this one uses.
> >-      free_linetable => free just the linetable.  FIXME: Is this redundant
> >-      with the primary field?  */
> >- 
> >-   enum free_code
> >-   {
> >-     free_nothing, free_contents, free_linetable
> >-   }
> >-   free_code;
> >- 
> >   /* A function to call to free space, if necessary.  This is IN
> >      ADDITION to the action indicated by free_code.  */
> > 
> >--- 765,770 ----
> >*************** struct symtab
> >*** 803,811 ****
> > 
> >   int *line_charpos;
> > 
> >   /* Language of this source file.  */
> > 
> >!   enum language language;
> > 
> >   /* String that identifies the format of the debugging information, such
> >      as "stabs", "dwarf 1", "dwarf 2", "coff", etc.  This is mostly useful
> >--- 780,802 ----
> > 
> >   int *line_charpos;
> > 
> >+   /* This component says how to free the data we point to:
> >+      free_contents => do a tree walk and free each object.
> >+      free_nothing => do nothing; some other symtab will free
> >+      the data this one uses.
> >+      free_linetable => free just the linetable.  FIXME: Is this redundant
> >+      with the primary field?  */
> >+ 
> >+   enum free_code
> >+   {
> >+     free_nothing, free_contents, free_linetable
> >+   };
> >+ 
> >+   ENUM_BITFIELD(free_code) free_code : 8;
> >+ 
> >   /* Language of this source file.  */
> > 
> >!   ENUM_BITFIELD(language) language : 8;
> > 
> >   /* String that identifies the format of the debugging information, such
> >      as "stabs", "dwarf 1", "dwarf 2", "coff", etc.  This is mostly useful
> >
> > 
> >
> 
> 
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa] save space by using enum bitfields

[Jim Blandy]

Daniel Jacobowitz <drow@mvista.com> writes:
> Well, I'd say that 20% off the size of struct symbol is pretty good. 
> It makes the idea of unifying our symbol tables to have only one kind
> of symbol much more practical.

Given that Michael C. says it only saves 0.6% when debugging GDB
itself, why do you say the size reductions are significant?

Re: [rfa] save space by using enum bitfields

[David Carlton]

On 18 Aug 2003 16:48:48 -0500, Jim Blandy <jimb@redhat.com> said:
> Daniel Jacobowitz <drow@mvista.com> writes:

>> Well, I'd say that 20% off the size of struct symbol is pretty
>> good.  It makes the idea of unifying our symbol tables to have only
>> one kind of symbol much more practical.

> Given that Michael C. says it only saves 0.6% when debugging GDB
> itself, why do you say the size reductions are significant?

For what it's worth, his test wouldn't have noticed size reduction in
struct symbol, only in struct {partial,minimal}_symbol.  But 0.6%
seems pretty small either way.

David Carlton
carlton@kealia.com

Re: [rfa] save space by using enum bitfields

[Daniel Jacobowitz]

On Mon, Aug 18, 2003 at 04:48:48PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@mvista.com> writes:
> > Well, I'd say that 20% off the size of struct symbol is pretty good. 
> > It makes the idea of unifying our symbol tables to have only one kind
> > of symbol much more practical.
> 
> Given that Michael C. says it only saves 0.6% when debugging GDB
> itself, why do you say the size reductions are significant?

Because what I am talking about would increase the size of partial
symbols substantially, and this change would cut down on how big that
increase is.  But GDB isn't a good example for this anyway; relatively
small symbol table, esp. if your C library has no debug info.  Try it
on a debugging build of Mozilla and I bet you're closer to 5% savings.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [rfa] save space by using enum bitfields

[David Carlton]

On Mon, 18 Aug 2003 13:49:56 -0700, Michael Snyder <msnyder@redhat.com> said:

> I gotta say, this looks like uglification to me.  Is it worth it?

I won't venture an opinion on whether or not it's worth it, but I
don't like all those : 8's that it inserts.  Why not stick that into
the definition of ENUM_BITFIELD?  Though that would have the cost that
you'd need to have the member's name be an argument to ENUM_BITFIELD,
which wouldn't be an improvement.  Hmm.

David Carlton
carlton@kealia.com