From: "Ben L. Titzer" <ben.titzer@gmail.com>
To: gdb@sourceware.org
Subject: Break at address on darwin
Date: Tue, 02 Aug 2011 16:47:00 -0000 [thread overview]
Message-ID: <CAL9pw=_BKUYDX_Bd0WGV796A6az9Wuw20gayb24Zuqxuw5RjSA@mail.gmail.com> (raw)
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
next reply other threads:[~2011-08-02 16:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-02 16:47 Ben L. Titzer [this message]
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
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='CAL9pw=_BKUYDX_Bd0WGV796A6az9Wuw20gayb24Zuqxuw5RjSA@mail.gmail.com' \
--to=ben.titzer@gmail.com \
--cc=gdb@sourceware.org \
/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