Break at address on darwin

Break at address on darwin

[Ben L. Titzer]

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

Re: Break at address on darwin

[Jeffrey Walton]

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

Re: Break at address on darwin

[Ben L. Titzer]

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

Re: Break at address on darwin

[Jonas Maebe]

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

Re: Break at address on darwin

[Ben L. Titzer]

[-- 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 --]

Re: Break at address on darwin

[Tristan Gingold]

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>

Re: Break at address on darwin

[Pedro Alves]

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

Re: Break at address on darwin

[Jonas Maebe]

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

Re: Break at address on darwin

[Ben L. Titzer]

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

Re: Break at address on darwin

[Pedro Alves]

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

Re: Break at address on darwin

[Ben L. Titzer]

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
>

Re: Break at address on darwin

[Tristan Gingold]

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.