* Re: break of time loop
@ 2005-10-31 13:56 Efim Monjak
2005-10-31 14:19 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Efim Monjak @ 2005-10-31 13:56 UTC (permalink / raw)
To: gdb
thanks it works with Signal interrupt.
But I found an other Problem:
after two steps I read from CPSR Register the ARM CPU goes into Abort Mode.
I is because the GDB reads memory after a step and hier are two
adressies which
are not in address area of ARM CPU. Step after reading of such address cause
CPU Abort Mode. What informations reads GDB. Is it possible to switch it
off?
Hier is a part of remote protocol
39 l = 2 + l;
(gdb) info register
Sending packet: $g#67...Ack
Packet received:
0000000000000000F0060040040000004000000000000000000000000000000
00000000000000000F03B0040EC3D0040F03D0040D83D0040FEFFFFEA08070040000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000001F000060
r0 0x0 0
r1 0x0 0
r2 0x400006f0 1073743600
r3 0x4 4
r4 0x40 64
r5 0x0 0
r6 0x0 0
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x40003bf0 1073757168
r11 0x40003dec 1073757676
r12 0x40003df0 1073757680
sp 0x40003dd8 1073757656
lr 0xeafffffe -352321538
pc 0x40000708 1073743624
fps 0x0 0
cpsr 0x6000001f 1610612767
(gdb) step
Sending packet: $s#73...Ack
Packet received: T050B:EC3D0040;0D:D83D0040;0F:0C070040;
Sending packet: $s#73...Ack
Packet received: T050B:EC3D0040;0D:D83D0040;0F:10070040;
Sending packet: $s#73...Ack
Packet received: T050B:EC3D0040;0D:D83D0040;0F:14070040;
Sending packet: $m40000714,4#5d...Ack
Packet received: 0330A0E3
Sending packet: $m40003de8,4#c5...Ack
Packet received: FEFFFFEA
Sending packet: $meafffffe,4#f6...Ack
hier seems is readed a one pointer
Packet received: FFCBCC2F
Sending packet: $m40003de0,4#bd...Ack
Packet received: 00000000
Sending packet: $m0,4#fd...Ack
hier seems to be other pointer also
Packet received: 060000EA
Sending packet: $me9fffffc,4#cc...Ack
Packet received: FCFFFFE9
Sending packet: $m40003de4,4#c1...Ack
Packet received: F03D0040
40 ch = 3;
(gdb) info register
Sending packet: $g#67...Ack
Packet received:
0000000000000000F0060040060000004000000000000000000000000000000
00000000000000000F03B0040EC3D0040F03D0040D83D0040FEFFFFEA14070040000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000097000060
r0 0x0 0
r1 0x0 0
r2 0x400006f0 1073743600
r3 0x6 6
r4 0x40 64
r5 0x0 0
r6 0x0 0
r7 0x0 0
r8 0x0 0
r9 0x0 0
r10 0x40003bf0 1073757168
r11 0x40003dec 1073757676
r12 0x40003df0 1073757680
sp 0x40003dd8 1073757656
lr 0xeafffffe -352321538
pc 0x40000714 1073743636
fps 0x0 0
cpsr 0x60000097 1610612887
Hier CPSR shows Abort Mode
(gdb)
thanks
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: break of time loop
2005-10-31 13:56 break of time loop Efim Monjak
@ 2005-10-31 14:19 ` Daniel Jacobowitz
0 siblings, 0 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2005-10-31 14:19 UTC (permalink / raw)
To: Efim Monjak; +Cc: gdb
On Mon, Oct 31, 2005 at 02:56:46PM +0100, Efim Monjak wrote:
> thanks it works with Signal interrupt.
>
> But I found an other Problem:
> after two steps I read from CPSR Register the ARM CPU goes into Abort Mode.
> I is because the GDB reads memory after a step and hier are two
> adressies which
> are not in address area of ARM CPU. Step after reading of such address cause
> CPU Abort Mode. What informations reads GDB. Is it possible to switch it
> off?
It's probably confused about the stack frame. In general, your stub
should detect invalid memory reads and return errors.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: break of time loop
@ 2005-11-04 10:52 Efim Monjak
0 siblings, 0 replies; 11+ messages in thread
From: Efim Monjak @ 2005-11-04 10:52 UTC (permalink / raw)
To: gdb
hier are parts of protocolls thith different positions of ctrl+c to step
responce
|| 2B 24 73 23 37 33 +$s#73
*Answer: 04.11.2005 11:18:13.04264 (+0.0000 seconds)
* 2B 24 54 30 35 30 62 3A 65 63 33 64 30 30 34 30 +$T050b:ec3d0040
3B 30 64 3A 64 63 33 64 30 30 34 30 3B 30 66 3A ;0d:dc3d0040;0f:
66 30 30 37 30 30 34 30 3B 23 64 61 f0070040;#da
*Request: 04.11.2005 11:18:13.07364 (+0.0000 seconds)
* 03 2B 24 73 23 37 33 .+$s#73
*Answer: 04.11.2005 11:18:13.07364 (+0.0000 seconds)
* 2B 24 54 30 35 30 62 3A 65 63 33 64 30 30 34 30 +$T050b:ec3d0040
3B 30 64 3A 64 63 33 64 30 30 34 30 3B 30 66 3A ;0d:dc3d0040;0f: 66 34
30 37 30 30 34 30 3B 23 64 65 f4070040;#de
*Request: 04.11.2005 11:18:13.10564 (+0.0000 seconds)
* 2B 24 73 23 37 33 +$s#73
*Answer: 04.11.2005 11:18:13.10564 (+0.0000 seconds)
* 2B 24 54 30 35 30 62 3A 65 63 33 64 30 30 34 30 +$T050b:ec3d0040
3B 30 64 3A 64 63 33 64 30 30 34 30 3B 30 66 3A ;0d:dc3d0040;0f:
66 38 30 37 30 30 34 30 3B 23 65 32 f8070040;#e2
*Request: 04.11.2005 11:18:13.13664 (+0.0000 seconds)
* 2B 24 73 23 37 33 +$s#73
*Answer: 04.11.2005 11:18:13.13664 (+0.0000 seconds)
* 2B 24 +$
*Request: 04.11.2005 11:18:13.16764 (+0.0000 seconds)
* 03 .
*
[ctrl+c sent without to wait for responce end]
Answer: 04.11.2005 11:18:13.16764 (+0.0000 seconds)
* 54 30 35 30 62 3A 65 63 33 64 30 30 34 30 3B 30 T050b:ec3d0040;0
64 3A 64 63 33 64 30 30 34 30 3B 30 66 3A 66 63 d:dc3d0040;0f:fc
30 37 30 30 34 30 3B 23 30 64 070040;#0d
*Request: 04.11.2005 11:18:13.16764 (+0.0000 seconds)
* 2B 24 73 23 37 33 +$s#73
*Answer: 04.11.2005 11:18:13.16764 (+0.0000 seconds)
* 2B 24 54 30 35 30 62 3A 65 63 33 64 30 30 34 30 +$T050b:ec3d0040
3B 30 64 3A 64 63 33 64 30 30 34 30 3B 30 66 3A ;0d:dc3d0040;0f:
30 30 30 38 30 30 34 30 3B 23 61 35 00080040;#a5
they are different placies
hier from GDB
Packet received: T050b:ec3d0040;0d:dc3d0040;0f:f4070040;
Sending packet: $s#73...Ack
Packet received: T050b:ec3d0040;0d:dc3d0040;0f:f8070040;
remote_interrupt called
remote_stop called
Sending packet: $s#73...Packet instead of Ack, ignoring it
hier on serial connection
Request: 04.11.2005 11:25:58.93664 (+0.0000 seconds)
2B 24 73 23 37
33
+$s#73
Answer: 04.11.2005 11:25:58.95264 (+0.0156 seconds)
2B 24 54 30 35 30 62 3A 65 63 33 64 30 30 34 30
+$T050b:ec3d0040
3B 30 64 3A 64 63 33 64 30 30 34 30 3B 30 66 3A
;0d:dc3d0040;0f:
30 30 30 38 30 30 34 30 3B 23 61
35 00080040;#a5
Request: 04.11.2005 11:25:58.96764 (+0.0000 seconds)
2B 03 24 73 23 37
33
+.$s#73
[hier ctrl+c sentd after step responce but not wait for its own responce
after step command
signal is ignored]
Answer: 04.11.2005 11:25:58.98364 (+0.0000 seconds)
24 54 30 32 30 62 3A 65 63 33 64 30 30 34 30 3B
$T020b:ec3d0040;
30 64 3A 64 63 33 64 30 30 34 30 3B 30 66 3A 30
0d:dc3d0040;0f:0
30 30 38 30 30 34 30 3B 23 61
32 0080040;#a2
Request: 04.11.2005 11:25:58.98364 (+0.0000 seconds)
2B 24 73 23 37 33
+$s#73
Answer: 04.11.2005 11:26:01.98364 (+0.0000 seconds)
2B 24 54 30 35 30 62 3A 65 63 33 64 30 30 34 30
+$T050b:ec3d0040
3B 30 64 3A 64 63 33 64 30 30 34 30 3B 30 66 3A
;0d:dc3d0040;0f:
65 63 30 37 30 30 34 30 3B 23 30
63 ec070040;#0c
Request: 04.11.2005 11:26:01.01464 (+0.0000 seconds)
--
Mit freundlichen Gruessen
Efim Monjak
Lipowsky Industrie-Elektronik GmbH
64291 Darmstadt, Roemerstr. 57
Telefon: +49-(0)6151-93591-0
Telefax: +49-(0)6151-93591-28
Email: ymonyak@lipowsky.de
Homepage: http://www.lipowsky.de
DIN EN ISO 9001:2000 certified by DQS
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: break of time loop
2005-11-03 10:42 Efim Monjak
@ 2005-11-03 21:23 ` Daniel Jacobowitz
0 siblings, 0 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2005-11-03 21:23 UTC (permalink / raw)
To: Efim Monjak; +Cc: gdb
On Thu, Nov 03, 2005 at 11:42:24AM +0100, Efim Monjak wrote:
> Hi all,
>
> is there a particular time between send a "step" command and ctrl+c.
No, the ctrl-c is processed whenever GDB receives it from the user, if
the target is running.
> I see the ctrl+c charakter on different place depend on performanse of
> target.
> If I set a big delay before send "step" response I see about 1 sec.
> between "step" command
> and ctrl+c. Signal Interrupt which stops the time loop after ctrl+c
> don't stops
> the loop if ctrl+c is received after "stop" response but to close to
> next "step"
> command to send a special responce to ctrl+c. In this case next "step"
> is responced
> with interrupt signal. But the loop will not be stopped.
Sorry, I can not follow the situation you are describing. I would need
to see an example session.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 11+ messages in thread
* break of time loop
@ 2005-11-03 10:42 Efim Monjak
2005-11-03 21:23 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Efim Monjak @ 2005-11-03 10:42 UTC (permalink / raw)
To: gdb
Hi all,
is there a particular time between send a "step" command and ctrl+c.
I see the ctrl+c charakter on different place depend on performanse of
target.
If I set a big delay before send "step" response I see about 1 sec.
between "step" command
and ctrl+c. Signal Interrupt which stops the time loop after ctrl+c
don't stops
the loop if ctrl+c is received after "stop" response but to close to
next "step"
command to send a special responce to ctrl+c. In this case next "step"
is responced
with interrupt signal. But the loop will not be stopped.
--
Mit freundlichen Gruessen
Efim Monjak
Lipowsky Industrie-Elektronik GmbH
64291 Darmstadt, Roemerstr. 57
Telefon: +49-(0)6151-93591-0
Telefax: +49-(0)6151-93591-28
Email: ymonyak@lipowsky.de
Homepage: http://www.lipowsky.de
DIN EN ISO 9001:2000 certified by DQS
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: break of time loop
2005-10-27 15:47 Efim Monjak
@ 2005-10-27 18:08 ` Daniel Jacobowitz
0 siblings, 0 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2005-10-27 18:08 UTC (permalink / raw)
To: Efim Monjak; +Cc: gdb
On Thu, Oct 27, 2005 at 05:47:00PM +0200, Efim Monjak wrote:
> Hier are protocols for case you describe.
> The trap signal is reseived after ctrl+c but it steps after it.
> remote_interrupt called
> remote_stop called
> Packet received: T050B:EC3D0040;0D:DC3D0040;0F:60010040;
Try not returning SIGTRAP here.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 11+ messages in thread
* break of time loop
@ 2005-10-27 15:47 Efim Monjak
2005-10-27 18:08 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Efim Monjak @ 2005-10-27 15:47 UTC (permalink / raw)
To: gdb
Hier are protocols for case you describe.
The trap signal is reseived after ctrl+c but it steps after it.
00004AC4 24 54 30 35 30 42 3a 45 43 33 44 30 30 34 30 3b $T050B:E C3D0040;
00004AD4 30 44 3a 44 43 33 44 30 30 34 30 3b 30 46 3a 36 0D:DC3D0 040;0F:6
00004AE4 38 30 31 30 30 34 30 3b 23 38 43 8010040; #8C
00000A3B 2b +
00000A3C 24 73 23 37 33 $s#73
00004AEF 2b +
00004AF0 24 54 30 35 30 42 3a 45 43 33 44 30 30 34 30 3b $T050B:E C3D0040;
00004B00 30 44 3a 44 43 33 44 30 30 34 30 3b 30 46 3a 36 0D:DC3D0 040;0F:6
00004B10 43 30 31 30 30 34 30 3b 23 39 37 C010040; #97
00000A41 2b +
00000A42 24 73 23 37 33 $s#73
00004B1B 2b +
00000A47 03 .
00004B1C 24 54 30 35 30 42 3a 45 43 33 44 30 30 34 30 3b $T050B:E C3D0040;
00004B2C 30 44 3a 44 43 33 44 30 30 34 30 3b 30 46 3a 35 0D:DC3D0 040;0F:5
00004B3C 38 30 31 30 30 34 30 3b 23 38 42 8010040; #8B
00000A48 2b +
00000A49 24 73 23 37 33 $s#73
00004B47 2b +
00004B48 24 54 30 35 30 42 3a 45 43 33 44 30 30 34 30 3b $T050B:E C3D0040;
00004B58 30 44 3a 44 43 33 44 30 30 34 30 3b 30 46 3a 35 0D:DC3D0 040;0F:5
00004B68 43 30 31 30 30 34 30 3b 23 39 36 C010040; #96
00000A4E 2b +
00000A4F 24 73 23 37 33 $s#73
00004B73 2b +
Sending packet: $s#73...Ack
Packet received: T050B:EC3D0040;0D:DC3D0040;0F:58010040;
Sending packet: $s#73...Ack
Packet received: T050B:EC3D0040;0D:DC3D0040;0F:5C010040;
Sending packet: $s#73...Ack
remote_interrupt called
remote_stop called
Packet received: T050B:EC3D0040;0D:DC3D0040;0F:60010040;
Sending packet: $s#73...Ack
Packet received: T050B:EC3D0040;0D:DC3D0040;0F:64010040;
Sending packet: $s#73...Ack
Packet received: T050B:EC3D0040;0D:DC3D0040;0F:68010040;
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: break of time loop
2005-10-27 15:19 Efim Monjak
@ 2005-10-27 15:23 ` Daniel Jacobowitz
0 siblings, 0 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2005-10-27 15:23 UTC (permalink / raw)
To: Efim Monjak; +Cc: gdb
On Thu, Oct 27, 2005 at 05:19:03PM +0200, Efim Monjak wrote:
> Hier a part of transcript and a part of ethereal protocol. they are
> from different sessions but I think it is the same case.
> The ctrl+c is sent before "step" command is responsed. The response for
> "step" is recognised as response for ctrl+c,
> possibly the trap signal don't means the loop processing is stopped.
> After it next "step" command is sent and the
> response for ctrl+c, which is sent at the same time with interrupt
> signal, is ignored.
> I hope you can understand my english:)
If you receive a C-c after sending a stop response, you should ignore
the C-c, not send another. Then this won't happen.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 11+ messages in thread
* break of time loop
@ 2005-10-27 15:19 Efim Monjak
2005-10-27 15:23 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Efim Monjak @ 2005-10-27 15:19 UTC (permalink / raw)
To: gdb
Hier a part of transcript and a part of ethereal protocol. they are
from different sessions but I think it is the same case.
The ctrl+c is sent before "step" command is responsed. The response for
"step" is recognised as response for ctrl+c,
possibly the trap signal don't means the loop processing is stopped.
After it next "step" command is sent and the
response for ctrl+c, which is sent at the same time with interrupt
signal, is ignored.
I hope you can understand my english:)
000004BD 2b +
000004BE 24 73 23 37 33 $s#73
000022E2 2b +
000022E3 24 54 30 35 30 42 3a 45 43 33 44 30 30 34 30 3b $T050B:E C3D0040;
000022F3 30 44 3a 44 43 33 44 30 30 34 30 3b 30 46 3a 36 0D:DC3D0 040;0F:6
00002303 38 30 31 30 30 34 30 3b 23 38 43 8010040; #8C
000004C3 2b +
000004C4 24 73 23 37 33 $s#73
0000230E 2b +
0000230F 24 54 30 35 30 42 3a 45 43 33 44 30 30 34 30 3b $T050B:E C3D0040;
0000231F 30 44 3a 44 43 33 44 30 30 34 30 3b 30 46 3a 36 0D:DC3D0 040;0F:6
0000232F 43 30 31 30 30 34 30 3b 23 39 37 C010040; #97
000004C9 2b +
000004CA 24 73 23 37 33 $s#73
0000233A 2b +
000004CF 03 .
0000233B 24 54 30 35 30 42 3a 45 43 33 44 30 30 34 30 3b $T050B:E C3D0040;
0000234B 30 44 3a 44 43 33 44 30 30 34 30 3b 30 46 3a 35 0D:DC3D0 040;0F:5
0000235B 38 30 31 30 30 34 30 3b 23 38 42 8010040; #8B
000004D0 2b +
000004D1 24 73 23 37 33 $s#73
00002366 24 54 30 32 30 42 3a 45 43 33 44 30 30 34 30 3b $T020B:E C3D0040;
00002376 30 44 3a 44 43 33 44 30 30 34 30 3b 30 46 3a 35 0D:DC3D0 040;0F:5
00002386 38 30 31 30 30 34 30 3b 23 38 38 8010040; #88
000004D6 2b +
000004D7 24 73 23 37 33 $s#73
00002391 2b +
00002392 24 54 30 35 30 42 3a 45 43 33 44 30 30 34 30 3b $T050B:E C3D0040;
000023A2 30 44 3a 44 43 33 44 30 30 34 30 3b 30 46 3a 35 0D:DC3D0 040;0F:5
000023B2 43 30 31 30 30 34 30 3b 23 39 36 C010040; #96
000004DC 2b +
000004DD 24 73 23 37 33 $s#73
000023BD 2b +
000023BE 24 54 30 35 30 42 3a 45 43 33 44 30 30 34 30 3b $T050B:E C3D0040;
000023CE 30 44 3a 44 43 33 44 30 30 34 30 3b 30 46 3a 36 0D:DC3D0 040;0F:6
000023DE 30 30 31 30 30 34 30 3b 23 38 34 0010040; #84
000004E2 2b +
Sending packet: $s#73...Ack
Packet received: T050B:EC3D0040;0D:DC3D0040;0F:6C010040;
Sending packet: $s#73...Ack
Packet received: T050B:EC3D0040;0D:DC3D0040;0F:58010040;
Sending packet: $s#73...Ack
remote_interrupt called
remote_stop called
Packet received: T050B:EC3D0040;0D:DC3D0040;0F:5C010040;
Sending packet: $s#73...Packet instead of Ack, ignoring it
Sending packet: $s#73...Ack
Packet received: T050B:EC3D0040;0D:DC3D0040;0F:60010040;
Sending packet: $s#73...Ack
Packet received: T050B:EC3D0040;0D:DC3D0040;0F:64010040;
Sending packet: $s#73...Ack
Packet received: T050B:EC3D0040;0D:DC3D0040;0F:68010040;
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: break of time loop
2005-10-27 14:04 Efim Monjak
@ 2005-10-27 14:34 ` Daniel Jacobowitz
0 siblings, 0 replies; 11+ messages in thread
From: Daniel Jacobowitz @ 2005-10-27 14:34 UTC (permalink / raw)
To: Efim Monjak; +Cc: gdb
On Thu, Oct 27, 2005 at 04:04:47PM +0200, Efim Monjak wrote:
> The GDB send in this case to target many "step" commands.
> I try to stop the processing of loop by crtl+c. Target receive
> code 0x03 and responce it with Packet:
> TAAn...:r...;n...:r...;n...:r...;
> there AA ist signal TARGET_SIGNAL_INT = 02.
> I can see the response from target.
> It is possible the ctrl+c is sent after "step" command before
> it is responsed. In this case they are two responsies one after other.
> But GDB don't stops to send "step" commands.
> How must be responsed the ctrl+c?
Sorry, I'm not sure I understand your question. Can you give us a
transcript of the remote protocol session (set debug remote 1) that you
think is wrong?
If GDB sends an interrupt to the remote target, the target should
return a stop response (T packet, above). At that point the target is
stopped. There shouldn't be another response to any pending step
commands.
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply [flat|nested] 11+ messages in thread
* break of time loop
@ 2005-10-27 14:04 Efim Monjak
2005-10-27 14:34 ` Daniel Jacobowitz
0 siblings, 1 reply; 11+ messages in thread
From: Efim Monjak @ 2005-10-27 14:04 UTC (permalink / raw)
To: gdb
Hi all,
I try to break a time loop from GDB.
The loop is written in form:
long l;
for(l = 0; l < 0xFFFFFFL; l++)
;
The GDB send in this case to target many "step" commands.
I try to stop the processing of loop by crtl+c. Target receive
code 0x03 and responce it with Packet:
TAAn...:r...;n...:r...;n...:r...;
there AA ist signal TARGET_SIGNAL_INT = 02.
I can see the response from target.
It is possible the ctrl+c is sent after "step" command before
it is responsed. In this case they are two responsies one after other.
But GDB don't stops to send "step" commands.
How must be responsed the ctrl+c?
thanks
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-11-04 10:52 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-10-31 13:56 break of time loop Efim Monjak
2005-10-31 14:19 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2005-11-04 10:52 Efim Monjak
2005-11-03 10:42 Efim Monjak
2005-11-03 21:23 ` Daniel Jacobowitz
2005-10-27 15:47 Efim Monjak
2005-10-27 18:08 ` Daniel Jacobowitz
2005-10-27 15:19 Efim Monjak
2005-10-27 15:23 ` Daniel Jacobowitz
2005-10-27 14:04 Efim Monjak
2005-10-27 14:34 ` Daniel Jacobowitz
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).