* Break at address on darwin
@ 2011-08-02 16:47 Ben L. Titzer
2011-08-02 19:00 ` Jeffrey Walton
0 siblings, 1 reply; 12+ messages in thread
From: Ben L. Titzer @ 2011-08-02 16:47 UTC (permalink / raw)
To: gdb
I am generating very simple Mach-O binaries by hand without symbol
information and trying to debug them with gdb by setting breakpoints
at various addresses. However, the breakpoints I set do not fire,
though I am certain those addresses are being executed (program runs
to completion, I can put in illegal instructions and they trap in gdb,
my program makes system calls that output to stdout, etc).
When I debug other binaries (e.g. generated by gcc), I am able to set
breakpoints at various addresses and they fire in gdb no problem.
Even though my binaries load and run correctly, producing the correct
output, gdb breakpoints don't work. If I explicitly insert an int3
instruction, a gdb breakpoint does occur.
I have a feeling that I am missing some step that is required by gdb,
such as setting an attribute or adding an extra section to my binary,
but I don't know what.
uname -a
Darwin goro 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16
PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
output from otool -l for one of my binaries:
/tmp/add01:
Load command 0
cmd LC_SEGMENT
cmdsize 56
segname __PAGEZERO
vmaddr 0x00000000
vmsize 0x00001000
fileoff 0
filesize 0
maxprot 0x00000000
initprot 0x00000000
nsects 0
flags 0x0
Load command 1
cmd LC_SEGMENT
cmdsize 56
segname __TEXT
vmaddr 0x00001000
vmsize 0x00001000
fileoff 0
filesize 4096
maxprot 0x00000007
initprot 0x00000005
nsects 0
flags 0x0
Load command 2
cmd LC_SEGMENT
cmdsize 56
segname __DATA
vmaddr 0x00002000
vmsize 0x00000000
fileoff 4096
filesize 0
maxprot 0x00000003
initprot 0x00000003
nsects 0
flags 0x0
Load command 3
cmd LC_UNIXTHREAD
cmdsize 80
flavor i386_THREAD_STATE
count i386_THREAD_STATE_COUNT
eax 0x00000000 ebx 0x00000000 ecx 0x00000000 edx 0x00000000
edi 0x00000000 esi 0x00000000 ebp 0x00000000 esp 0x00000000
ss 0x00000000 eflags 0x00000000 eip 0x00001114 cs 0x00000000
ds 0x00000000 es 0x00000000 fs 0x00000000 gs 0x00000000
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: Break at address on darwin 2011-08-02 16:47 Break at address on darwin Ben L. Titzer @ 2011-08-02 19:00 ` Jeffrey Walton 2011-08-02 19:19 ` Ben L. Titzer 0 siblings, 1 reply; 12+ messages in thread From: Jeffrey Walton @ 2011-08-02 19:00 UTC (permalink / raw) To: Ben L. Titzer; +Cc: gdb Hi Ben, On Tue, Aug 2, 2011 at 12:46 PM, Ben L. Titzer <ben.titzer@gmail.com> wrote: > I am generating very simple Mach-O binaries by hand without symbol > information and trying to debug them with gdb by setting breakpoints > at various addresses. However, the breakpoints I set do not fire, > though I am certain those addresses are being executed (program runs > to completion, I can put in illegal instructions and they trap in gdb, > my program makes system calls that output to stdout, etc). Are you certain you are setting a breakpoint on an address (eg, b 0x40000000)? Or is it a symbolic name (b main)? > When I debug other binaries (e.g. generated by gcc), I am able to set > breakpoints at various addresses and they fire in gdb no problem. > > Even though my binaries load and run correctly, producing the correct > output, gdb breakpoints don't work. If I explicitly insert an int3 > instruction, a gdb breakpoint does occur. > I have a feeling that I am missing some step that is required by gdb, > such as setting an attribute or adding an extra section to my binary, > but I don't know what. > > [SNIP] When I have issues, it typically is because I have optimizations enabled and I set a symbolic breakpoint which is never hit (despite what the result of the break command states). Taking optimizations back to -O0 usually resolves the issue for me. For what its worth, I don't find this sort of thing to be an Apple/Mac OS X issue. It can happen anywhere the optimizer works its magic. Jeff ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Break at address on darwin 2011-08-02 19:00 ` Jeffrey Walton @ 2011-08-02 19:19 ` Ben L. Titzer 2011-08-02 20:31 ` Jonas Maebe 0 siblings, 1 reply; 12+ messages in thread From: Ben L. Titzer @ 2011-08-02 19:19 UTC (permalink / raw) To: noloader; +Cc: gdb On Tue, Aug 2, 2011 at 12:00 PM, Jeffrey Walton <noloader@gmail.com> wrote: > Hi Ben, > > On Tue, Aug 2, 2011 at 12:46 PM, Ben L. Titzer <ben.titzer@gmail.com> wrote: >> I am generating very simple Mach-O binaries by hand without symbol >> information and trying to debug them with gdb by setting breakpoints >> at various addresses. However, the breakpoints I set do not fire, >> though I am certain those addresses are being executed (program runs >> to completion, I can put in illegal instructions and they trap in gdb, >> my program makes system calls that output to stdout, etc). > Are you certain you are setting a breakpoint on an address (eg, b > 0x40000000)? Or is it a symbolic name (b main)? It's an address. I know for sure it's being executed because it's the first instruction in the binary. No gdb breakpoints work on my binaries. However if I insert an int3 or illegal instruction in the code, then it will break or trap in gdb. > >> When I debug other binaries (e.g. generated by gcc), I am able to set >> breakpoints at various addresses and they fire in gdb no problem. >> >> Even though my binaries load and run correctly, producing the correct >> output, gdb breakpoints don't work. If I explicitly insert an int3 >> instruction, a gdb breakpoint does occur. >> I have a feeling that I am missing some step that is required by gdb, >> such as setting an attribute or adding an extra section to my binary, >> but I don't know what. >> >> [SNIP] > When I have issues, it typically is because I have optimizations > enabled and I set a symbolic breakpoint which is never hit (despite > what the result of the break command states). Taking optimizations > back to -O0 usually resolves the issue for me. > I am not trying to debug binaries generated by gcc. I am generating binaries from my own compiler, and I think I missed some attribute or section necessary for gdb breakpoints to work properly with my binaries. -B ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Break at address on darwin 2011-08-02 19:19 ` Ben L. Titzer @ 2011-08-02 20:31 ` Jonas Maebe 2011-08-02 21:51 ` Ben L. Titzer 0 siblings, 1 reply; 12+ messages in thread From: Jonas Maebe @ 2011-08-02 20:31 UTC (permalink / raw) To: Ben L. Titzer; +Cc: gdb On 02 Aug 2011, at 21:19, Ben L. Titzer wrote: > On Tue, Aug 2, 2011 at 12:00 PM, Jeffrey Walton <noloader@gmail.com> wrote: >> Are you certain you are setting a breakpoint on an address (eg, b >> 0x40000000)? Or is it a symbolic name (b main)? Just to make sure: to put a breakpoint on an address, it's "b *0x40000000" (i.e., with an extra "*"; but you'd notice if you used the wrong syntax, since gdb would complain that it can't find a symbol with that name). > It's an address. I ænow for sure it's being executed because it's the > first instruction in the binary. Actually, I've noticed on many platforms that breakpoints on the very first instruction don't work. Did you also try other instructions? Jonas ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Break at address on darwin 2011-08-02 20:31 ` Jonas Maebe @ 2011-08-02 21:51 ` Ben L. Titzer 2011-08-03 8:09 ` Tristan Gingold 2011-08-03 9:00 ` Pedro Alves 0 siblings, 2 replies; 12+ messages in thread From: Ben L. Titzer @ 2011-08-02 21:51 UTC (permalink / raw) To: Jonas Maebe; +Cc: gdb [-- Attachment #1: Type: text/plain, Size: 2537 bytes --] On Tue, Aug 2, 2011 at 1:31 PM, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote: > > On 02 Aug 2011, at 21:19, Ben L. Titzer wrote: > >> On Tue, Aug 2, 2011 at 12:00 PM, Jeffrey Walton <noloader@gmail.com> wrote: >>> Are you certain you are setting a breakpoint on an address (eg, b >>> 0x40000000)? Or is it a symbolic name (b main)? > > Just to make sure: to put a breakpoint on an address, it's "b *0x40000000" (i.e., with an extra "*"; but you'd notice if you used the wrong syntax, since gdb would complain that it can't find a symbol with that name). Yes, I am using the correct syntax and gdb will list the breakpoints I have added. > >> It's an address. I ænow for sure it's being executed because it's the >> first instruction in the binary. > > Actually, I've noticed on many platforms that breakpoints on the very first instruction don't work. Did you also try other instructions? > Doesn't matter, no breakpoints work. I've attached a sample binary and gdb session. ------------------- % gdb /tmp/add01 GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"... (gdb) break *0x1114 Breakpoint 1 at 0x1114 (gdb) run Starting program: /private/tmp/add01 Program exited with code 04. (gdb) disass 0x1114 0x1140 Dump of assembler code from 0x1114 to 0x1140: 0x00001114: mov (%esp),%ebx 0x00001117: mov $0x0,%eax 0x0000111c: mov 0x1121(,%ebx,4),%edx 0x00001123: jmp 0x1129 0x00001125: add %al,(%eax) 0x00001127: add %al,(%eax) 0x00001129: call 0x1148 0x0000112e: push %eax 0x0000112f: mov %esp,%ebx 0x00001131: push $0x4 0x00001133: push %ebx 0x00001134: push $0x1 0x00001136: push $0x0 0x00001138: mov $0x4,%eax 0x0000113d: int $0x80 0x0000113f: push %eax End of assembler dump. (gdb) break 01148 No symbol table is loaded. Use the "file" command. (gdb) break *0x1148 Breakpoint 2 at 0x1148 (gdb) run Starting program: /private/tmp/add01 Program exited with code 04. (gdb) info breakpoints Num Type Disp Enb Address What 1 breakpoint keep y 0x00001114 2 breakpoint keep y 0x00001148 (gdb) [-- Attachment #2: add01 --] [-- Type: application/octet-stream, Size: 4152 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Break at address on darwin 2011-08-02 21:51 ` Ben L. Titzer @ 2011-08-03 8:09 ` Tristan Gingold 2011-08-03 9:00 ` Pedro Alves 1 sibling, 0 replies; 12+ messages in thread From: Tristan Gingold @ 2011-08-03 8:09 UTC (permalink / raw) To: Ben L. Titzer; +Cc: Jonas Maebe, gdb On Aug 2, 2011, at 11:51 PM, Ben L. Titzer wrote: > On Tue, Aug 2, 2011 at 1:31 PM, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote: >> >> On 02 Aug 2011, at 21:19, Ben L. Titzer wrote: >> >>> On Tue, Aug 2, 2011 at 12:00 PM, Jeffrey Walton <noloader@gmail.com> wrote: >>>> Are you certain you are setting a breakpoint on an address (eg, b >>>> 0x40000000)? Or is it a symbolic name (b main)? >> >> Just to make sure: to put a breakpoint on an address, it's "b *0x40000000" (i.e., with an extra "*"; but you'd notice if you used the wrong syntax, since gdb would complain that it can't find a symbol with that name). > > Yes, I am using the correct syntax and gdb will list the breakpoints I > have added. > >> >>> It's an address. I ænow for sure it's being executed because it's the >>> first instruction in the binary. >> >> Actually, I've noticed on many platforms that breakpoints on the very first instruction don't work. Did you also try other instructions? >> > > Doesn't matter, no breakpoints work. > > I've attached a sample binary and gdb session. Ben, you are using the Apple version of gdb. Please talk with Apple about this issue. Tristan. > > ------------------- > % gdb /tmp/add01 > GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011) > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "x86_64-apple-darwin"... > (gdb) break *0x1114 > Breakpoint 1 at 0x1114 > (gdb) run > Starting program: /private/tmp/add01 > > Program exited with code 04. > (gdb) disass 0x1114 0x1140 > Dump of assembler code from 0x1114 to 0x1140: > 0x00001114: mov (%esp),%ebx > 0x00001117: mov $0x0,%eax > 0x0000111c: mov 0x1121(,%ebx,4),%edx > 0x00001123: jmp 0x1129 > 0x00001125: add %al,(%eax) > 0x00001127: add %al,(%eax) > 0x00001129: call 0x1148 > 0x0000112e: push %eax > 0x0000112f: mov %esp,%ebx > 0x00001131: push $0x4 > 0x00001133: push %ebx > 0x00001134: push $0x1 > 0x00001136: push $0x0 > 0x00001138: mov $0x4,%eax > 0x0000113d: int $0x80 > 0x0000113f: push %eax > End of assembler dump. > (gdb) break 01148 > No symbol table is loaded. Use the "file" command. > (gdb) break *0x1148 > Breakpoint 2 at 0x1148 > (gdb) run > Starting program: /private/tmp/add01 > > Program exited with code 04. > (gdb) info breakpoints > Num Type Disp Enb Address What > 1 breakpoint keep y 0x00001114 > 2 breakpoint keep y 0x00001148 > (gdb) > <add01> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Break at address on darwin 2011-08-02 21:51 ` Ben L. Titzer 2011-08-03 8:09 ` Tristan Gingold @ 2011-08-03 9:00 ` Pedro Alves 2011-08-03 9:05 ` Jonas Maebe 1 sibling, 1 reply; 12+ messages in thread From: Pedro Alves @ 2011-08-03 9:00 UTC (permalink / raw) To: gdb; +Cc: Ben L. Titzer, Jonas Maebe On Tuesday 02 August 2011 22:51:22, Ben L. Titzer wrote: > (gdb) disass 0x1114 0x1140 > Dump of assembler code from 0x1114 to 0x1140: > 0x00001114: mov (%esp),%ebx > 0x00001117: mov $0x0,%eax ... > (gdb) break *0x1148 > Breakpoint 2 at 0x1148 > Num Type Disp Enb Address What > 1 breakpoint keep y 0x00001114 > 2 breakpoint keep y 0x00001148 Does the program really load at those addresses? They look suspiciously low. -- Pedro Alves ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Break at address on darwin 2011-08-03 9:00 ` Pedro Alves @ 2011-08-03 9:05 ` Jonas Maebe 2011-08-03 13:45 ` Ben L. Titzer 0 siblings, 1 reply; 12+ messages in thread From: Jonas Maebe @ 2011-08-03 9:05 UTC (permalink / raw) To: Pedro Alves; +Cc: GDB Users, Ben L. Titzer On 03 Aug 2011, at 10:59, Pedro Alves wrote: > On Tuesday 02 August 2011 22:51:22, Ben L. Titzer wrote: >> Num Type Disp Enb Address What >> 1 breakpoint keep y 0x00001114 >> 2 breakpoint keep y 0x00001148 > > Does the program really load at those addresses? > They look suspiciously low. They're probably correct. Darwin/i386 generally does load programs starting at 0x1000. Jonas ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Break at address on darwin 2011-08-03 9:05 ` Jonas Maebe @ 2011-08-03 13:45 ` Ben L. Titzer 2011-08-03 14:06 ` Pedro Alves 0 siblings, 1 reply; 12+ messages in thread From: Ben L. Titzer @ 2011-08-03 13:45 UTC (permalink / raw) To: Jonas Maebe; +Cc: Pedro Alves, GDB Users On Wed, Aug 3, 2011 at 2:05 AM, Jonas Maebe <jonas.maebe@elis.ugent.be> wrote: > > On 03 Aug 2011, at 10:59, Pedro Alves wrote: > >> On Tuesday 02 August 2011 22:51:22, Ben L. Titzer wrote: >>> >>> Num Type Disp Enb Address What >>> 1 breakpoint keep y 0x00001114 >>> 2 breakpoint keep y 0x00001148 >> >> Does the program really load at those addresses? Yes I am 100% sure this program actually runs to completion and produces what it should. As I mentioned, if I insert an int3 or illegal instruction manually somewhere in its code, the program will trap appropriately. However, I need to debug other programs with gdb, e.g. by single-stepping through their execution. >> They look suspiciously low. > > They're probably correct. Darwin/i386 generally does load programs starting > at 0x1000. Yes, 0x1000 is where the program loads its first text page, which is mapped to file offset 0. 0x01114 happens to be the entrypoint instruction. 0x01148 is the address of the first function it calls, which you can see from the assembly listing. Output from the otool -l command for this binary: /tmp/add01: Load command 0 cmd LC_SEGMENT cmdsize 56 segname __PAGEZERO vmaddr 0x00000000 vmsize 0x00001000 fileoff 0 filesize 0 maxprot 0x00000000 initprot 0x00000000 nsects 0 flags 0x0 Load command 1 cmd LC_SEGMENT cmdsize 56 segname __TEXT vmaddr 0x00001000 vmsize 0x00001000 fileoff 0 filesize 4096 maxprot 0x00000007 initprot 0x00000005 nsects 0 flags 0x0 Load command 2 cmd LC_SEGMENT cmdsize 56 segname __DATA vmaddr 0x00002000 vmsize 0x00000000 fileoff 4096 filesize 0 maxprot 0x00000003 initprot 0x00000003 nsects 0 flags 0x0 Load command 3 cmd LC_UNIXTHREAD cmdsize 80 flavor i386_THREAD_STATE count i386_THREAD_STATE_COUNT eax 0x00000000 ebx 0x00000000 ecx 0x00000000 edx 0x00000000 edi 0x00000000 esi 0x00000000 ebp 0x00000000 esp 0x00000000 ss 0x00000000 eflags 0x00000000 eip 0x00001114 cs 0x00000000 ds 0x00000000 es 0x00000000 fs 0x00000000 gs 0x00000000 -B ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Break at address on darwin 2011-08-03 13:45 ` Ben L. Titzer @ 2011-08-03 14:06 ` Pedro Alves 2011-08-03 21:00 ` Ben L. Titzer 0 siblings, 1 reply; 12+ messages in thread From: Pedro Alves @ 2011-08-03 14:06 UTC (permalink / raw) To: gdb; +Cc: Ben L. Titzer, Jonas Maebe On Wednesday 03 August 2011 14:45:11, Ben L. Titzer wrote: > Yes, 0x1000 is where the program loads its first text page, which is > mapped to file offset 0. 0x01114 happens to be the entrypoint > instruction. 0x01148 is the address of the first function it calls, > which you can see from the assembly listing. Okay. I know close to nothing about Darwin. Apple have their own heavilly modified version of gdb, forked from the FSF tree eons ago, so as Tristan said, you need to contact them. Or try current FSF gdb. -- Pedro Alves ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Break at address on darwin 2011-08-03 14:06 ` Pedro Alves @ 2011-08-03 21:00 ` Ben L. Titzer 2011-08-04 7:19 ` Tristan Gingold 0 siblings, 1 reply; 12+ messages in thread From: Ben L. Titzer @ 2011-08-03 21:00 UTC (permalink / raw) To: Pedro Alves; +Cc: gdb, Jonas Maebe On Wed, Aug 3, 2011 at 7:05 AM, Pedro Alves <pedro@codesourcery.com> wrote: > On Wednesday 03 August 2011 14:45:11, Ben L. Titzer wrote: > >> Yes, 0x1000 is where the program loads its first text page, which is >> mapped to file offset 0. 0x01114 happens to be the entrypoint >> instruction. 0x01148 is the address of the first function it calls, >> which you can see from the assembly listing. > > Okay. I know close to nothing about Darwin. Apple > have their own heavilly modified version of gdb, forked from > the FSF tree eons ago, so as Tristan said, you need to contact > them. Or try current FSF gdb. > Fair enough. I downloaded and built gdb 7.3 for darwin. It segfaults trying to load symbols from this binary (there are none). % gdb /tmp/add01 GNU gdb (GDB) 7.3 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-apple-darwin10.8.0". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /private/tmp/add01...Segmentation fault > -- > Pedro Alves > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Break at address on darwin 2011-08-03 21:00 ` Ben L. Titzer @ 2011-08-04 7:19 ` Tristan Gingold 0 siblings, 0 replies; 12+ messages in thread From: Tristan Gingold @ 2011-08-04 7:19 UTC (permalink / raw) To: Ben L. Titzer; +Cc: Pedro Alves, gdb, Jonas Maebe On Aug 3, 2011, at 11:00 PM, Ben L. Titzer wrote: > On Wed, Aug 3, 2011 at 7:05 AM, Pedro Alves <pedro@codesourcery.com> wrote: >> On Wednesday 03 August 2011 14:45:11, Ben L. Titzer wrote: >> >>> Yes, 0x1000 is where the program loads its first text page, which is >>> mapped to file offset 0. 0x01114 happens to be the entrypoint >>> instruction. 0x01148 is the address of the first function it calls, >>> which you can see from the assembly listing. >> >> Okay. I know close to nothing about Darwin. Apple >> have their own heavilly modified version of gdb, forked from >> the FSF tree eons ago, so as Tristan said, you need to contact >> them. Or try current FSF gdb. >> > > Fair enough. I downloaded and built gdb 7.3 for darwin. It segfaults > trying to load symbols from this binary (there are none). > > % gdb /tmp/add01 > GNU gdb (GDB) 7.3 > Copyright (C) 2011 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-apple-darwin10.8.0". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /private/tmp/add01...Segmentation fault Try the development version (from cvs). I think it works. Tristan. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-08-04 7:19 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-08-02 16:47 Break at address on darwin Ben L. Titzer 2011-08-02 19:00 ` Jeffrey Walton 2011-08-02 19:19 ` Ben L. Titzer 2011-08-02 20:31 ` Jonas Maebe 2011-08-02 21:51 ` Ben L. Titzer 2011-08-03 8:09 ` Tristan Gingold 2011-08-03 9:00 ` Pedro Alves 2011-08-03 9:05 ` Jonas Maebe 2011-08-03 13:45 ` Ben L. Titzer 2011-08-03 14:06 ` Pedro Alves 2011-08-03 21:00 ` Ben L. Titzer 2011-08-04 7:19 ` Tristan Gingold
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox