patches/gdb/6.3/400-mips-coredump.patch-2.4.23-29
author "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Sun May 20 13:48:26 2007 +0000 (2007-05-20)
changeset 112 ea15433daba0
permissions -rw-r--r--
Ah! I finally have a progress bar that doesn't stall the build!
- pipe size in Linux is only 8*512=4096 bytes
- pipe size is not setable
- when the feeding process spits out data faster than the eating
process can read it, then the feeding process stalls after 4KiB
of data sent to the pipe
- for us, the progress bar would spawn a sub-shell every line,
and the sub-shell would in turn spawn a 'date' command.
Which was sloooww as hell, and would cause some kind of a
starvation: the pipe was full most of the time, and the
feeding process was stalled all this time.

Now, we use internal variables and a little hack based onan offset
to determine the elapsed time. Much faster this way, but still
CPU-intensive.
     1 Sometime around 2.4.22-23, the mips pt_regs.h fields were reordered, breaking
     2 coredump handling by gdb for current kernels.  Update the hardcoded constants
     3 to reflect the change.
     4 --- gdb-6.2.1/gdb/mips-linux-tdep.c-orig	2004-10-29 14:23:55.000000000 -0500
     5 +++ gdb-6.2.1/gdb/mips-linux-tdep.c	2004-10-29 14:26:44.000000000 -0500
     6 @@ -53,12 +53,22 @@
     7  
     8  #define EF_REG0			6
     9  #define EF_REG31		37
    10 +
    11 +#if 0
    12  #define EF_LO			38
    13  #define EF_HI			39
    14  #define EF_CP0_EPC		40
    15  #define EF_CP0_BADVADDR		41
    16  #define EF_CP0_STATUS		42
    17  #define EF_CP0_CAUSE		43
    18 +#else
    19 +#define EF_CP0_STATUS		38
    20 +#define EF_LO			39
    21 +#define EF_HI			40
    22 +#define EF_CP0_BADVADDR		41
    23 +#define EF_CP0_CAUSE		42
    24 +#define EF_CP0_EPC		43
    25 +#endif
    26  
    27  #define EF_SIZE			180
    28