Skip to contentSkip to conversation

support for gzipped (ELF) core dumps

PATCH New Shaheed 2 participants 4 messages Jan 8, 2005 – Jan 13, 2005

Subsystems (4)
Documentation VFS Library code exec and binfmt
lore
Share & tools
lore

Shaheed

author
#0 lore raw

Review

Quoted 6 lines
(quoted diff) +4 -0
+/* This table is needed for efficient CRC32 calculation */
+static const unsigned long crc_table[8][256] = {
+ {
+ 0x00000000UL, 0x77073096UL, 0xee0e612cUL, 0x990951baUL, 0x076dc419UL,

First, by using "unsigned long", you may be doubling the size on most 64 bit platforms. Second, I'm pretty sure there is a standard implementation of several CRCs already in the kernel - is there a reason not to use one of them (e.g. a different polynomial)?

#1 lore raw

Hi,

I tried to use those "in-kernel" functions, but they seem to do little different CRC calculations. Unfortunately I don't have any experiences with CRC stuff, anyone able to help here?

Regards,
Jan

Quoted 14 lines

Review

Quoted 4 lines
(quoted diff) +4 -0
+/* This table is needed for efficient CRC32 calculation */
+static const unsigned long crc_table[8][256] = {
+ {
+ 0x00000000UL, 0x77073096UL, 0xee0e612cUL, 0x990951baUL, 0x076dc419UL,

First, by using "unsigned long", you may be doubling the size on most 64 bit platforms. Second, I'm pretty sure there is a standard implementation of several CRCs already in the kernel - is there a reason not to use one of them (e.g. a different polynomial)?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

author
#2 lore raw
Quoted 5 lines · Jan Frey

Hi,

I tried to use those "in-kernel" functions, but they seem to do little different CRC calculations. Unfortunately I don't have any experiences with CRC stuff, anyone able to help here?

Do you know what polynomial you are trying to use? My first try wth Google gets me to:

http://www.cyphercalc.com/crctool.htm#LookupTables

not to mention a bunch of free sources such as:

http://www.repairfaq.org/filipg/LINK/F_crc_v35.html

which even implies that the pkzip polynomial *is* the standard one. If you really need the unrolled version for performance, at least use the right data types and/or consider to compute the tables at run time:

http://gcc.gnu.org/ml/gcc-patches/2002-04/msg01097.html

#3 lore raw

PATCH 1/1 Updated: support for gzipped (ELF) core dumps

In reply to Jan Frey

Hi all,

now I managed to use lib/crc32. Obviously the patch looks a lot better now!

Regards,
Jan

Quoted 23 lines

Hi,

I tried to use those "in-kernel" functions, but they seem to do little different CRC calculations. Unfortunately I don't have any experiences with CRC stuff, anyone able to help here?

Regards,
Jan

Quoted 6 lines

Review

Quoted 4 lines
(quoted diff) +4 -0
+/* This table is needed for efficient CRC32 calculation */
+static const unsigned long crc_table[8][256] = {
+ {
+ 0x00000000UL, 0x77073096UL, 0xee0e612cUL, 0x990951baUL, 0x076dc419UL,

First, by using "unsigned long", you may be doubling the size on most 64 bit

Quoted 8 lines

platforms. Second, I'm pretty sure there is a standard implementation of several CRCs already in the kernel - is there a reason not to use one of them (e.g. a different polynomial)?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 5 lines

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

arch/i386/config.in +1 -0
diff -ur linux-2.4.28/arch/i386/config.in linux-2.4.28-gzip-coredump/arch/i386/config.in
@@ -479,6 +479,7 @@
    bool '  Magic SysRq key' CONFIG_MAGIC_SYSRQ
    bool '  Spinlock debugging' CONFIG_DEBUG_SPINLOCK
    bool '  Compile the kernel with frame pointers' CONFIG_FRAME_POINTER
+   bool '  Write gzipped core dump files' CONFIG_GZIP_COREDUMPS
 fi
 
 int 'Kernel messages buffer length shift (0 = default)' CONFIG_LOG_BUF_SHIFT 0
Documentation/Configure.help +5 -0
diff -ur linux-2.4.28/Documentation/Configure.help linux-2.4.28-gzip-coredump/Documentation/Configure.help
@@ -29121,6 +29121,11 @@
   
   If unsure, say N.
 
+CONFIG_GZIP_COREDUMPS
+  Saying yes here makes the kernel writing core dump files in a 
+  gzipped compressed format. You will have to uncompress core files
+  with gzip -d prior to usage (e.g. with gdb).
+
 #
 # A couple of things I keep forgetting:
 #   capitalize: AppleTalk, Ethernet, DOS, DMA, FAT, FTP, Internet,
fs/binfmt_elf.c +245 -13

367 lines not on this page · raw message

lib/Config.in +2 -1
diff -ur linux-2.4.28/lib/Config.in linux-2.4.28-gzip-coredump/lib/Config.in
@@ -27,7 +27,8 @@
   fi
 fi
 
-if [ "$CONFIG_PPP_DEFLATE" = "y" -o \
+if [ "$CONFIG_GZIP_COREDUMPS" = "y" -o \
+     "$CONFIG_PPP_DEFLATE" = "y" -o \
      "$CONFIG_CRYPTO_DEFLATE" = "y" -o \
      "$CONFIG_JFFS2_FS" = "y" ]; then
    define_tristate CONFIG_ZLIB_DEFLATE y