Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Christopher Faylor <cgf@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Fix partial symbol lookups
Date: Thu, 16 Nov 2000 11:01:00 -0000	[thread overview]
Message-ID: <20001116140122.A21436@redhat.com> (raw)
In-Reply-To: <m38zqj3mcb.fsf@dan2.cygnus.com>

I wanted to let everyone know that Jim Blandy is aware of this thread
and wants to help move things along but his internet connection is down
currently and, additionally, he is in the middle of an important
project.

(Of course saying that he is in the middle of an important project and
his internet connection is down may be redundant.  Doesn't it always
work that way?)

So, with luck, he'll be weighing in with an opinion on Monday.

FYI,
cgf
From msnyder@redhat.com Thu Nov 16 11:35:00 2000
From: Michael Snyder <msnyder@redhat.com>
To: Orjan Friberg <orjan.friberg@axis.com>
Cc: Fernando Nasser <fnasser@cygnus.com>, gdb-patches@sourceware.cygnus.com
Subject: Re: Relying on tm-target.h macros in target-tdep.c
Date: Thu, 16 Nov 2000 11:35:00 -0000
Message-id: <3A1436FD.581FDFDB@redhat.com>
References: <3A13C9E5.D5465E2C@axis.com> <3A13E1F7.8CCB0A4C@cygnus.com> <3A13FD96.639B2F6@axis.com>
X-SW-Source: 2000-11/msg00213.html
Content-length: 3519

Orjan Friberg wrote:
> 
> Fernando Nasser wrote:
> >
> > First of all, your tm-???.h file is already included.  Look in your build
> > directory and you'll find a link "tm.h" that points to it (if not your
> > configuration is broken).  tm.h goes in defs.h, and the latter is included
> > everywhere.  (BTW, this is explained in the gdb internals manual --
> > gdb/doc/gdbint.texinfo).
> >
> 
> Thanks, I knew about the tm.h-link, but I had missed the connection with
> defs.h.
> 
> > You haven't told us why you need these things in your gdbarch_init,
> > and that is your real problem.  You should not need any of this in there.
> >
> > Give us an example of the use of one of these things in there.
> > I bet you should be using something from bfd.
> >
> 
> Ok, the problem is that I'm adding support for two versions in the same
> chip series, which have different sizes (16 vs 32 bits) for one of the
> registers. The new chip is backwards compatible, which means I cannot
> know for sure which chip version the target actually is until I read the
> version register, in case the binary was compiled for the older chip.

This is not a unique situation.  Other targets with multiple generations
face the same problem.  Go with what the binary says it is, and then 
switch on the fly later if needed.  You cannot assume that you can
read register values from within gdbarch_init.  You might not be 
connected to any target at that time.  Registers might not be available.


> This affects register_byte, register_raw_size, register_virtual_size,
> which are implemented via function pointers.

You should have a different version of each of those functions for
each chip variation.  Unles you want to try and be clever  by having
a single function that detects on the fly what the chip is, but I
do not recommend it if you are doing this for the first time.

You must create a separate gdbarch struct for each chip variation.
The 16-bit gdbarch will point to the 16-bit functions, and so forth.

At runtime (as opposed to initialization time), gdb must decide
which gdbarch to use.

> They make use of the
> information in opcodes/cris-opc.c to get the register sizes by looking
> at the chip version which I've added to my tdep struct (Yes; I hope to
> have the chip version sorted out by the time these functions are called
> -- otherwise I have to rely on the uneducated guess I make in
> gdbarch_init).

Don't do it this way.  You are trying to be too clever.
Implement a separate version of each function for each chip, 
and point to them with separate gdbarch objects.  Let the user
set the chip version by hand, if necessary, until you get the
auto-detection issues straightened out.

> register_bytes OTOH, is an int, which means I cannot
> "postpone" that decision.

Not in your current design -- which is why you shouldn't use it.
Start simple, become more complex as time and foundation permit.
 
> Basically, there is information about registers vs chip versions in
> opcodes/cris-opc.c that I'd like to use (via register_size), instead of
> duplicating that information in gdbarch_init. It's not that big of a
> deal though.
> 
> (When/how I will be able to decide on the actual chip version is another
> story. Right now I'm just adding the framework for supporting both
> chips.)

My impression is that you're trying to do it with a single
gdbarch object.  That's not the idea.

> 
> --
> Orjan Friberg              E-mail: orjan.friberg@axis.com
> Axis Communications AB     Phone:  +46 46 272 17 68
From cgf@redhat.com Thu Nov 16 12:18:00 2000
From: Christopher Faylor <cgf@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Fix partial symbol lookups
Date: Thu, 16 Nov 2000 12:18:00 -0000
Message-id: <20001116151800.A22508@redhat.com>
References: <200011161222.NAA05985@reisser.regent.e-technik.tu-muenchen.de> <m38zqj3mcb.fsf@dan2.cygnus.com> <20001116140122.A21436@redhat.com>
X-SW-Source: 2000-11/msg00214.html
Content-length: 646

On Thu, Nov 16, 2000 at 02:01:22PM -0500, Christopher Faylor wrote:
>I wanted to let everyone know that Jim Blandy is aware of this thread
>and wants to help move things along but his internet connection is down
>currently and, additionally, he is in the middle of an important
>project.
>
>(Of course saying that he is in the middle of an important project and
>his internet connection is down may be redundant.  Doesn't it always
>work that way?)
>
>So, with luck, he'll be weighing in with an opinion on Monday.

I probably should note, in case it isn't obvious, that Jim is the
primary maintainer for the patches that Dan is submitting.

cgf
From Peter.Schauer@regent.e-technik.tu-muenchen.de Thu Nov 16 12:39:00 2000
From: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>
To: dberlin@redhat.com (Daniel Berlin)
Cc: msnyder@cygnus.com, jimb@cygnus.com, gdb-patches@sources.redhat.com, ezannoni@cygnus.com
Subject: Re: [RFA]: Fix partial symbol lookups
Date: Thu, 16 Nov 2000 12:39:00 -0000
Message-id: <200011162039.VAA06942@reisser.regent.e-technik.tu-muenchen.de>
References: <m3lmuj26vd.fsf@dan2.cygnus.com>
X-SW-Source: 2000-11/msg00215.html
Content-length: 1706

> > Not true.
> > There were no demangled names in partial symbols from most symbol readers,
> > _except_ for the HP reader, which we are currently discussing, and which
> > I discovered rather late in the day as well.
> > Before your change, lookup_partial_symbol fell back to a linear search
> > if it didn't find the symbol and had the chance to find the demangled symbol
> > via SYMBOL_MATCHES_NAME during the linear search.
> 
> Peter, you are missing an important point.
> 
> *I* added that SYMBOL_MATCHES_NAME. Not HP. As the comment shows
> right above it.
	.
	.
> So we couldn't have possibly been finding demangled names until I
> added that, and since the HP code is older than the change to use
> SYMBOL_MATCHES_NAME, they couldn't have had demangled names working in
> partial symbol lookups.

Sorry, but wrong again.
Since gdb-4.8 we have the following in lookup_partial_symbol:

          if (!do_linear_search && SYMBOL_LANGUAGE (center) == language_cplus)
            {
              do_linear_search = 1;
            }

So lookup_partial_symbol falls back to a linear search if either the mangled
or demangled partial symbol is not found.
And the linear search does this:

              if (SYMBOL_MATCHES_NAME (psym, name))
                {
                  return (psym);
                }

which will match either the mangled or the demangled partial symbol name.

It might have been my fault not to remove all this in gdb-4.14, as the symbol
readers back then wouldn't have needed it.
But now with the HP symtab reader and the HPUXHPPA defines in lookup_symbol
it might be needed again.
At least _I_ don't dare to remove it.

-- 
Peter Schauer			pes@regent.e-technik.tu-muenchen.de
From geoffk@thief.cygnus.com Thu Nov 16 13:27:00 2000
From: Geoffrey Keating <geoffk@thief.cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: sim patch for new cpplib
Date: Thu, 16 Nov 2000 13:27:00 -0000
Message-id: <200011162126.eAGLQWE25953@thief.cygnus.com>
X-SW-Source: 2000-11/msg00216.html
Content-length: 8756

This patch updates the sim for the new, more correct, interpretation
of the ISO C99 standard that GCC currently has.

OK to commit?

-- 
Geoff Keating <geoffk@redhat.com>

===File ~/patches/sim-newcpp.patch==========================
In sim/common:
2000-11-16  Geoffrey Keating  <geoffk@redhat.com>

	* sim-endian.h: Don't have parameters on macro definitions which
	are simply renaming functions, to permit use of XCONCAT2 in both
	the macro name and the arguments in a use of such a definition.

In sim/ppc:
2000-11-16  Geoffrey Keating  <geoffk@redhat.com>

	* sim-endian.h: Don't have parameters on macro definitions which
	are simply renaming functions, to permit use of XCONCAT2 in both
	the macro name and the arguments in a use of such a definition.

Index: sim/common/sim-endian.h
===================================================================
RCS file: /cvs/cvsfiles/devo/sim/common/sim-endian.h,v
retrieving revision 1.12
diff -u -p -r1.12 sim-endian.h
--- sim-endian.h	2000/03/02 09:10:17	1.12
+++ sim-endian.h	2000/11/16 21:22:38
@@ -80,53 +80,53 @@ INLINE_SIM_ENDIAN(unsigned_8) sim_endian
 
 /* SWAP */
 
-#define SWAP_1(X) swap_1(X)
-#define SWAP_2(X) swap_2(X)
-#define SWAP_4(X) swap_4(X)
-#define SWAP_8(X) swap_8(X)
-#define SWAP_16(X) swap_16(X)
+#define SWAP_1 swap_1
+#define SWAP_2 swap_2
+#define SWAP_4 swap_4
+#define SWAP_8 swap_8
+#define SWAP_16 swap_16
 
 
 /* HOST to BE */
 
-#define H2BE_1(X) endian_h2be_1(X)
-#define H2BE_2(X) endian_h2be_2(X)
-#define H2BE_4(X) endian_h2be_4(X)
-#define H2BE_8(X) endian_h2be_8(X)
-#define H2BE_16(X) endian_h2be_16(X)
-#define BE2H_1(X) endian_be2h_1(X)
-#define BE2H_2(X) endian_be2h_2(X)
-#define BE2H_4(X) endian_be2h_4(X)
-#define BE2H_8(X) endian_be2h_8(X)
-#define BE2H_16(X) endian_be2h_16(X)
+#define H2BE_1 endian_h2be_1
+#define H2BE_2 endian_h2be_2
+#define H2BE_4 endian_h2be_4
+#define H2BE_8 endian_h2be_8
+#define H2BE_16 endian_h2be_16
+#define BE2H_1 endian_be2h_1
+#define BE2H_2 endian_be2h_2
+#define BE2H_4 endian_be2h_4
+#define BE2H_8 endian_be2h_8
+#define BE2H_16 endian_be2h_16
 
 
 /* HOST to LE */
 
-#define H2LE_1(X) endian_h2le_1(X)
-#define H2LE_2(X) endian_h2le_2(X)
-#define H2LE_4(X) endian_h2le_4(X)
-#define H2LE_8(X) endian_h2le_8(X)
-#define H2LE_16(X) endian_h2le_16(X)
-#define LE2H_1(X) endian_le2h_1(X)
-#define LE2H_2(X) endian_le2h_2(X)
-#define LE2H_4(X) endian_le2h_4(X)
-#define LE2H_8(X) endian_le2h_8(X)
-#define LE2H_16(X) endian_le2h_16(X)
+#define H2LE_1 endian_h2le_1
+#define H2LE_2 endian_h2le_2
+#define H2LE_4 endian_h2le_4
+#define H2LE_8 endian_h2le_8
+#define H2LE_16 endian_h2le_16
+#define LE2H_1 endian_le2h_1
+#define LE2H_2 endian_le2h_2
+#define LE2H_4 endian_le2h_4
+#define LE2H_8 endian_le2h_8
+#define LE2H_16 endian_le2h_16
 
 
 /* HOST to TARGET */
 
-#define H2T_1(X) endian_h2t_1(X)
-#define H2T_2(X) endian_h2t_2(X)
-#define H2T_4(X) endian_h2t_4(X)
-#define H2T_8(X) endian_h2t_8(X)
-#define H2T_16(X) endian_h2t_16(X)
-#define T2H_1(X) endian_t2h_1(X)
-#define T2H_2(X) endian_t2h_2(X)
-#define T2H_4(X) endian_t2h_4(X)
-#define T2H_8(X) endian_t2h_8(X)
-#define T2H_16(X) endian_t2h_16(X)
+#define H2T_1 endian_h2t_1
+#define H2T_2 endian_h2t_2
+#define H2T_4 endian_h2t_4
+#define H2T_8 endian_h2t_8
+#define H2T_16 endian_h2t_16
+#define T2H_1 endian_t2h_1
+#define T2H_2 endian_t2h_2
+#define T2H_4 endian_t2h_4
+#define T2H_8 endian_t2h_8
+#define T2H_16 endian_t2h_16
 
 
 /* CONVERT IN PLACE
@@ -219,22 +219,22 @@ do { \
    Byte swap a quantity the size of the targets word */
 
 #if (WITH_TARGET_WORD_BITSIZE == 64)
-#define H2T_word(X) H2T_8(X)
-#define T2H_word(X) T2H_8(X)
-#define H2BE_word(X) H2BE_8(X)
-#define BE2H_word(X) BE2H_8(X)
-#define H2LE_word(X) H2LE_8(X)
-#define LE2H_word(X) LE2H_8(X)
-#define SWAP_word(X) SWAP_8(X)
+#define H2T_word H2T_8
+#define T2H_word T2H_8
+#define H2BE_word H2BE_8
+#define BE2H_word BE2H_8
+#define H2LE_word H2LE_8
+#define LE2H_word LE2H_8
+#define SWAP_word SWAP_8
 #endif
 #if (WITH_TARGET_WORD_BITSIZE == 32)
-#define H2T_word(X) H2T_4(X)
-#define T2H_word(X) T2H_4(X)
-#define H2BE_word(X) H2BE_4(X)
-#define BE2H_word(X) BE2H_4(X)
-#define H2LE_word(X) H2LE_4(X)
-#define LE2H_word(X) LE2H_4(X)
-#define SWAP_word(X) SWAP_4(X)
+#define H2T_word H2T_4
+#define T2H_word T2H_4
+#define H2BE_word H2BE_4
+#define BE2H_word BE2H_4
+#define H2LE_word H2LE_4
+#define LE2H_word LE2H_4
+#define SWAP_word SWAP_4
 #endif
 
 
@@ -243,13 +243,13 @@ do { \
 
    Byte swap a quantity the size of the targets IEEE 1275 memory cell */
 
-#define H2T_cell(X) H2T_4(X)
-#define T2H_cell(X) T2H_4(X)
-#define H2BE_cell(X) H2BE_4(X)
-#define BE2H_cell(X) BE2H_4(X)
-#define H2LE_cell(X) H2LE_4(X)
-#define LE2H_cell(X) LE2H_4(X)
-#define SWAP_cell(X) SWAP_4(X)
+#define H2T_cell H2T_4
+#define T2H_cell T2H_4
+#define H2BE_cell H2BE_4
+#define BE2H_cell BE2H_4
+#define H2LE_cell H2LE_4
+#define LE2H_cell LE2H_4
+#define SWAP_cell SWAP_4
 
 
 
Index: sim/ppc/sim-endian.h
===================================================================
RCS file: /cvs/cvsfiles/devo/sim/ppc/sim-endian.h,v
retrieving revision 1.9
diff -u -p -r1.9 sim-endian.h
--- sim-endian.h	2000/03/02 09:24:23	1.9
+++ sim-endian.h	2000/11/16 21:22:38
@@ -246,46 +246,46 @@ INLINE_SIM_ENDIAN(unsigned_8) endian_le2
 
 /* SWAP */
 
-#define SWAP_1(X) swap_1(X)
-#define SWAP_2(X) swap_2(X)
-#define SWAP_4(X) swap_4(X)
-#define SWAP_8(X) swap_8(X)
+#define SWAP_1 swap_1
+#define SWAP_2 swap_2
+#define SWAP_4 swap_4
+#define SWAP_8 swap_8
 
 
 /* HOST to BE */
 
-#define H2BE_1(X) endian_h2be_1(X)
-#define H2BE_2(X) endian_h2be_2(X)
-#define H2BE_4(X) endian_h2be_4(X)
-#define H2BE_8(X) endian_h2be_8(X)
-#define BE2H_1(X) endian_be2h_1(X)
-#define BE2H_2(X) endian_be2h_2(X)
-#define BE2H_4(X) endian_be2h_4(X)
-#define BE2H_8(X) endian_be2h_8(X)
+#define H2BE_1 endian_h2be_1
+#define H2BE_2 endian_h2be_2
+#define H2BE_4 endian_h2be_4
+#define H2BE_8 endian_h2be_8
+#define BE2H_1 endian_be2h_1
+#define BE2H_2 endian_be2h_2
+#define BE2H_4 endian_be2h_4
+#define BE2H_8 endian_be2h_8
 
 
 /* HOST to LE */
 
-#define H2LE_1(X) endian_h2le_1(X)
-#define H2LE_2(X) endian_h2le_2(X)
-#define H2LE_4(X) endian_h2le_4(X)
-#define H2LE_8(X) endian_h2le_8(X)
-#define LE2H_1(X) endian_le2h_1(X)
-#define LE2H_2(X) endian_le2h_2(X)
-#define LE2H_4(X) endian_le2h_4(X)
-#define LE2H_8(X) endian_le2h_8(X)
+#define H2LE_1 endian_h2le_1
+#define H2LE_2 endian_h2le_2
+#define H2LE_4 endian_h2le_4
+#define H2LE_8 endian_h2le_8
+#define LE2H_1 endian_le2h_1
+#define LE2H_2 endian_le2h_2
+#define LE2H_4 endian_le2h_4
+#define LE2H_8 endian_le2h_8
 
 
 /* HOST to TARGET */
 
-#define H2T_1(X) endian_h2t_1(X)
-#define H2T_2(X) endian_h2t_2(X)
-#define H2T_4(X) endian_h2t_4(X)
-#define H2T_8(X) endian_h2t_8(X)
-#define T2H_1(X) endian_t2h_1(X)
-#define T2H_2(X) endian_t2h_2(X)
-#define T2H_4(X) endian_t2h_4(X)
-#define T2H_8(X) endian_t2h_8(X)
+#define H2T_1 endian_h2t_1
+#define H2T_2 endian_h2t_2
+#define H2T_4 endian_h2t_4
+#define H2T_8 endian_h2t_8
+#define T2H_1 endian_t2h_1
+#define T2H_2 endian_t2h_2
+#define T2H_4 endian_t2h_4
+#define T2H_8 endian_t2h_8
 
 
 /* CONVERT IN PLACE
@@ -370,22 +370,22 @@ do { \
    Byte swap a quantity the size of the targets word */
 
 #if (WITH_TARGET_WORD_BITSIZE == 64)
-#define H2T_word(X) H2T_8(X)
-#define T2H_word(X) T2H_8(X)
-#define H2BE_word(X) H2BE_8(X)
-#define BE2H_word(X) BE2H_8(X)
-#define H2LE_word(X) H2LE_8(X)
-#define LE2H_word(X) LE2H_8(X)
-#define SWAP_word(X) SWAP_8(X)
+#define H2T_word H2T_8
+#define T2H_word T2H_8
+#define H2BE_word H2BE_8
+#define BE2H_word BE2H_8
+#define H2LE_word H2LE_8
+#define LE2H_word LE2H_8
+#define SWAP_word SWAP_8
 #endif
 #if (WITH_TARGET_WORD_BITSIZE == 32)
-#define H2T_word(X) H2T_4(X)
-#define T2H_word(X) T2H_4(X)
-#define H2BE_word(X) H2BE_4(X)
-#define BE2H_word(X) BE2H_4(X)
-#define H2LE_word(X) H2LE_4(X)
-#define LE2H_word(X) LE2H_4(X)
-#define SWAP_word(X) SWAP_4(X)
+#define H2T_word H2T_4
+#define T2H_word T2H_4
+#define H2BE_word H2BE_4
+#define BE2H_word BE2H_4
+#define H2LE_word H2LE_4
+#define LE2H_word LE2H_4
+#define SWAP_word SWAP_4
 #endif
 
 
@@ -393,13 +393,13 @@ do { \
 
    Byte swap a quantity the size of the targets IEEE 1275 memory cell */
 
-#define H2T_cell(X) H2T_4(X)
-#define T2H_cell(X) T2H_4(X)
-#define H2BE_cell(X) H2BE_4(X)
-#define BE2H_cell(X) BE2H_4(X)
-#define H2LE_cell(X) H2LE_4(X)
-#define LE2H_cell(X) LE2H_4(X)
-#define SWAP_cell(X) SWAP_4(X)
+#define H2T_cell H2T_4
+#define T2H_cell T2H_4
+#define H2BE_cell H2BE_4
+#define BE2H_cell BE2H_4
+#define H2LE_cell H2LE_4
+#define LE2H_cell LE2H_4
+#define SWAP_cell SWAP_4
 
 
 #if (SIM_ENDIAN_INLINE & INCLUDE_MODULE)
============================================================
From bje@redhat.com Thu Nov 16 15:04:00 2000
From: Ben Elliston <bje@redhat.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: <cgen@sources.redhat.com>, <gdb-patches@sources.redhat.com>
Subject: Re: [RFA] Patch to sim/common/cgen-ops.h
Date: Thu, 16 Nov 2000 15:04:00 -0000
Message-id: <Pine.LNX.4.30.0011171001420.11755-100000@moshpit.cygnus.com>
References: <20001116074145.B6787@redhat.com>
X-SW-Source: 2000-11/msg00217.html
Content-length: 819

fche wrote:

   :      * the way to handle out-of-range arguments to the SUBWORD
   :        functions.  Perhaps it's okay to use assert(), since we're
   :        wasting a few cycles already by doing the test.

   Sure.

I'll make that change, then.

   :      * whether it makes sense to join two SFs into a DF.

   i.e., make a double out of two floats?  I don't think so. Maybe you
   mean to build a DF out of two SI's -- go through a DI first then.

No, I want to join two SFs together to form a DF -- one architecture that I
am thinking of allows you to store pairs of single precision fp registers in
one of its double precision fp registers.  If you can think of a simpler way
(perhaps using bitwise operators?), then we can eliminate the need for this.
I just thought that using (join ..) was clearer.

Ben


       reply	other threads:[~2000-11-16 11:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200011161222.NAA05985@reisser.regent.e-technik.tu-muenchen.de>
     [not found] ` <m38zqj3mcb.fsf@dan2.cygnus.com>
2000-11-16 11:01   ` Christopher Faylor [this message]
     [not found] <m3snorj4d7.fsf@dan2.cygnus.com>
2000-11-16  8:29 ` Peter.Schauer
2000-11-16  8:44   ` Daniel Berlin
2000-11-16  9:06     ` Peter.Schauer
2000-11-16  9:16       ` Daniel Berlin
2000-11-16  8:56   ` Daniel Berlin
2000-11-16  9:02     ` Daniel Berlin
     [not found] <m3vgtqv60a.fsf@dan2.cygnus.com>
     [not found] ` <npbsvhzxm9.fsf@zwingli.cygnus.com>
     [not found]   ` <m3hf59izpl.fsf@dan2.cygnus.com>
2000-11-15  8:56     ` Michael Snyder
     [not found]       ` <m3g0ktkrjh.fsf@dan2.cygnus.com>
2000-11-15 11:19         ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20001116140122.A21436@redhat.com \
    --to=cgf@redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox