Nico Heinze wrote: > --- In [email protected], raju raju <[EMAIL PROTECTED]> wrote: >> its simple..From the command prompt just give the gdb >> executable name and then from the gdb prompt type break >> file name:Line number.Then from the gdb prompt type run. >> It will take you that break point.For more info use gdb >> help. Also make sure you compile the binary using the -g >> option with your compiler. >> Thanks >> -A >> >> imran pathan <[EMAIL PROTECTED]> wrote: >> Hi, >> Well if you are using linux desktop then you have DDD >> (graphical debugger), where you can specify binary to >> open (it should have debug symbols). >> It opens source code as well. And you can give break points, >> watch window,variables,execution window, graphs etc. >> More ever it looks like sdk. >> >> Other option to debug your program is to compile it with insecure. >> >> Regards >> imran. >> >> dvergnaud <[EMAIL PROTECTED]> wrote: >> Hi, >> >> does anyone know whether it's possible to "set breakpoints" >> for gdb *in the source code*? like on windows, you can use >> the __asm int 3 command to have your program break at the >> specified line. is something like that possible with gdb? >> i'm compiling with gcc 4.2.0, and am using GNU gdb 6.3-debian. > > May I suggest that those who try to respond to this question read the > post more carefully? David asked how to set breakpoints during > compilation, not from within a debugger. > Your suggestions regarding gdb and ddd are nice but won't be of much > help for him. > > [This also concerns me, as many of you know:] > Please, before responding, first read the post completely and > carefully. Useless "responses" which completely miss the target of the > post don't help anyone. > > Regards, > Nico
Well, I don't know the exact answer to the question, but gdb has source code available. Debug breakpoints are usually interrupt driven on Intel architectures. That's the sane way of doing it. So to figure it out myself, I'd search the gdb source code. gdb has to be able to set a breakpoint by altering the memory of the target process. That means there is source code that does the altering. I'd look for one of two different things: A hardcoded opcode sequence that represents an interrupt (usually stuffed in a char *) or assembler instructions that are assembled at compile-time. However, be aware that gdb might not be prepared to handle manual breakpoints. That is, gdb might catch the breakpoint, try to find something in its memory for that breakpoint when you try to resume, not find anything, and then crash. Just a thought to keep in mind. Alternatively, gdb _DOES_ have a mailing list. You can always ask: http://sourceware.org/gdb/mailing-lists/ The 'gdb' list claims to be low-volume, but it seems to have a decent number of users. My few Google searches turned up nothing. Either no one does it (it could just be impossible to do) OR no one important has tried to do it OR someone important has done it but didn't bother to document the experience on the Internet OR it is frowned upon. But don't worry! You aren't the only one digging for obscure stuff. I've spent this entire week with my nose stuck in completely obscure realms. -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* VerifyMyPC 2.5 Change tracking and management tool. Reduce tech. support times from 2 hours to 5 minutes. http://www.CubicleSoft.com/VerifyMyPC/
