Return to Answer

From http://www.delorie.com/gnu/docs/gdb/gdb_29.html:

GDB normally ignores breakpoints when it resumes execution, until at least one instruction has been executed. If it did not do this, you would be unable to proceed past a breakpoint without first disabling the breakpoint. This rule applies whether or not the breakpoint already existed when your program stopped.

You might just get bitten by this; when loading, gdb puts the instruction pointer at the first instruction, and it won't break on this when starting the program.

According to this question and answer, this seems to be dependent on the version of gdb you're using, and disabling ASLR might help (i don't think that happens in your case though, since you checked the entry point after loading the specific instance of your program).

But i found this question that has a trick to break on the very first instruction that's getting executed; when i tested it, it even stopped within the dynaloader before passing execution to the entry point.

Still, i fail to see why you absolutely need to have a breakpoint at the entry point. If you want to change anything before the program executes its first instruction, just do it before running your program. You could, for example, change the instructions at the entry point to jmp my_special_function, which will probably need a few more bytes than just one instruction at _start, and have your special function end in the 4 instruction before the push, then jmp to 8048458. You can do all this after loading the program and run it afterwards.

From http://www.delorie.com/gnu/docs/gdb/gdb_29.html:

GDB normally ignores breakpoints when it resumes execution, until at least one instruction has been executed. If it did not do this, you would be unable to proceed past a breakpoint without first disabling the breakpoint. This rule applies whether or not the breakpoint already existed when your program stopped.

You might just get bitten by this; when loading, gdb puts the instruction pointer at the first instruction, and it won't break on this when starting the program.

According to this question and answer, this seems to be dependent on the version of gdb you're using, and disabling ASLR might help (i don't think that happens in your case though, since you checked the entry point after loading the specific instance of your program).

But i found this question that has a trick to break on the very first instruction that's getting executed; when i tested it, it even stopped within the dynaloader before passing execution to the entry point.

Still, i fail to see why you absolutely need to have a breakpoint at the entry point. If you want to change anything before the program executes its first instruction, just do it before running your program. You could, for example, change the instructions at the entry point to jmp my_special_function, which will probably need a few more bytes than just one instruction at _start, and have your special function end in the 4 instruction before the push, then jmp to 8048458. You can do all this after loading the program and run it afterwards.

From http://www.delorie.com/gnu/docs/gdb/gdb_29.html:

GDB normally ignores breakpoints when it resumes execution, until at least one instruction has been executed. If it did not do this, you would be unable to proceed past a breakpoint without first disabling the breakpoint. This rule applies whether or not the breakpoint already existed when your program stopped.

You might just get bitten by this; when loading, gdb puts the instruction pointer at the first instruction, and it won't break on this when starting the program.

According to this question and answer, this seems to be dependent on the version of gdb you're using, and disabling ASLR might help (i don't think that happens in your case though, since you checked the entry point after loading the specific instance of your program).

But i found this question that has a trick to break on the very first instruction that's getting executed; when i tested it, it even stopped within the dynaloader before passing execution to the entry point.

Still, i fail to see why you absolutely need to have a breakpoint at the entry point. If you want to change anything before the program executes its first instruction, just do it before running your program. You could, for example, change the instructions at the entry point to jmp my_special_function, which will probably need a few more bytes than just one instruction at _start, and have your special function end in the 4 instruction before the push, then jmp to 8048458. You can do all this after loading the program and run it afterwards.

From http://www.delorie.com/gnu/docs/gdb/gdb_29.html:

GDB normally ignores breakpoints when it resumes execution, until at least one instruction has been executed. If it did not do this, you would be unable to proceed past a breakpoint without first disabling the breakpoint. This rule applies whether or not the breakpoint already existed when your program stopped.

You might just get bitten by this; when loading, gdb puts the instruction pointer at the first instruction, and it won't break on this when starting the program.

According to this question and answer, this seems to be dependent on the version of gdb you're using, and disabling ASLR might help (i don't think that happens in your case though, since you checked the entry point after loading the specific instance of your program).

But i found this question that has a trick to break on the very first instruction that's getting executed; when i tested it, it even stopped within the dynaloader before passing execution to the entry point.

Still, i fail to see why you absolutely need to have a breakpoint at the entry point. If you want to change anything before the program executes its first instruction, just do it before running your program. You could, for example, change the instructions at the entry point to jmp my_special_function, which will probably need a few more bytes than just one instruction at _start, and have your special function end in the 4 instruction before the push, then jmp to 8048458. You can do all this after loading the program and run it afterwards.

From http://www.delorie.com/gnu/docs/gdb/gdb_29.html:

GDB normally ignores breakpoints when it resumes execution, until at least one instruction has been executed. If it did not do this, you would be unable to proceed past a breakpoint without first disabling the breakpoint. This rule applies whether or not the breakpoint already existed when your program stopped.

You might just get bitten by this; when loading, gdb puts the instruction pointer at the first instruction, and it won't break on this when starting the program.

According to this question and answer, this seems to be dependent on the version of gdb you're using, and disabling ASLR might help (i don't think that happens in your case though, since you checked the entry point after loading the specific instance of your program).

Still, i fail to see why you absolutely need to have a breakpoint at the entry point. If you want to change anything before the program executes its first instruction, just do it before running your program. You could, for example, change the instructions at the entry point to jmp my_special_function, which will probably need a few more bytes than just one instruction at _start, and have your special function end in the 4 instruction before the push, then jmp to 8048458. You can do all this after loading the program and run it afterwards.

From http://www.delorie.com/gnu/docs/gdb/gdb_29.html:

GDB normally ignores breakpoints when it resumes execution, until at least one instruction has been executed. If it did not do this, you would be unable to proceed past a breakpoint without first disabling the breakpoint. This rule applies whether or not the breakpoint already existed when your program stopped.

You might just get bitten by this; when loading, gdb puts the instruction pointer at the first instruction, and it won't break on this when starting the program.

According to this question and answer, this seems to be dependent on the version of gdb you're using, and disabling ASLR might help (i don't think that happens in your case though, since you checked the entry point after loading the specific instance of your program).

But i found this question that has a trick to break on the very first instruction that's getting executed; when i tested it, it even stopped within the dynaloader before passing execution to the entry point.

Still, i fail to see why you absolutely need to have a breakpoint at the entry point. If you want to change anything before the program executes its first instruction, just do it before running your program. You could, for example, change the instructions at the entry point to jmp my_special_function, which will probably need a few more bytes than just one instruction at _start, and have your special function end in the 4 instruction before the push, then jmp to 8048458. You can do all this after loading the program and run it afterwards.