From: kdsfinger@gmail.com
To: "Jim Blandy" <jimb@codesourcery.com>
Cc: gdb@sourceware.org
Subject: Re: gdb breakpoint problem
Date: Tue, 12 Jun 2007 03:33:00 -0000 [thread overview]
Message-ID: <cac7ac540706112033r1c94b2ebl4b0bbb1c0b338254@mail.gmail.com> (raw)
In-Reply-To: <m3vedus8aj.fsf@codesourcery.com>
On 6/11/07, Jim Blandy <jimb@codesourcery.com> wrote:
>
> kdsfinger@gmail.com writes:
> > hi, all
> > I am new to gdb and have trouble in setting the breakpoint. The
> > problem is, the program does not stop at some of the breakpoints. I am
> > using gdb6.6 in centos4.4. Here is the detail.
> >
> > ===================================
> > /* sample.c -- Sample C program to be debugged with ddd
> > */
> > #include <stdio.h>
> > #include <stdlib.h>
> > static void shell_sort(int a[], int size){
> > int i, j;
> > int h = 1;
> > do {
> > h = h * 3 + 1;
> > } while (h <= size);
> > do {
> > h /= 3;
> > for (i = h; i < size; i++){
> > int v = a[i];
> > for (j = i; j >= h && a[j - h] > v; j -= h)
> > a[j] = a[j - h];
> > if (i != j)
> > a[j] = v;
> > }
> > } while (h != 1);
> > }
> >
> > int main(int argc, char *argv[]){
> > int *a; //line 24
> > int i; //line 25
> > a = (int *)malloc((argc - 1) * sizeof(int)); // line 26
> > for (i = 0; i < argc - 1; i++)
> > a[i] = atoi(argv[i + 1]);
> > shell_sort(a, argc);
> > for (i = 0; i < argc - 1; i++)
> > printf("%d ", a[i]);
> > printf("\n");
> > free(a);
> > return 0;
> > }
> > ========================================
> > gcc -g -o sample sample.c
> >
> > gdb sample
> > GNU gdb 6.6
> > Copyright (C) 2006 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 "i686-pc-linux-gnu"...
> > Using host libthread_db library "/lib/tls/libthread_db.so.1".
> > (gdb) break 24
> > Breakpoint 1 at 0x804850b: file sample.c, line 24.
> > (gdb) info break 1
> > Num Type Disp Enb Address What
> > 1 breakpoint keep y 0x0804850b in main at sample.c:24
> > (gdb) run 2 4 6 3 5 7
> > Starting program: /home/amdx2/drive2/cpp/testddd/sample 2 4 6 3 5 7
> >
> > Breakpoint 1, main (argc=7, argv=0xbff515c4) at sample.c:26
> > 26 a = (int *)malloc((argc - 1) * sizeof(int));
> >
> > -------------------------
> > As you can see, the program did not stop at the breakpoint on line24.
> > It stops at line26. If I add another breakpoint on line25, this 2nd
> > breakpoint is skipped as well and the program stops at line26. Why is
> > that? How can I correct it?
>
> First, thanks for providing all the details in your question. Giving
> enough information to allow a reader to reproduce the problem
> themselves is the right approach.
>
> What's probably going on is that there is no machine code generated
> for lines 24 and 25. They're just declarations. The first actual
> machine instruction in main is for line 26, so the 'addresses' of lines
> 24, 25, and 26 are probably all the same.
>
> You can try setting three breakpoints on lines 24, 25, and 26, and
> then comparing the addresses printed for each to see if this is the
> case.
>
> > On my own program which is rather big, it got the same problem. When I
> > use info break xxx, it sometimes point to a different place in "What".
> > For example, I placed the breakpoint in main line 100, but the "what"
> > points to other functions in different line. As the result, these
> > breakpoints never work. I changed my gcc flags with combinations of
> > -glevel -olevel, the problem did not solve. Thanks for your comments.
>
> Have you tried compiling with no optimization at all (-O0)? When
> optimization is enabled, the compiler may inline functions, rearrange
> code, or remove it altogether. The debugging information often
> doesn't adequately describe these rearrangements, and the debugger
> gets confused.
>
> If you have compiled your program with -O0, and setting a breakpoint
> in main still results in the breakpoint's location being reported in
> some other function, that sounds like a bug. For us to help you,
> you'll need to provide enough information for us to make the problem
> happen on our own machines.
>
Thank you all for your prompt reply. But I am still confused. Here is
another toy to demonstrate my problem.
==============================
/* Test.cpp -- Test C++ program to be debugged with ddd
*/
#include <stdio.h>
#include <stdlib.h>
#include <string>
#include <iostream>
class Test{
public:
Test();
private:
void donothing();
};
void Test::donothing(){
std::string s = "abc"; // line 16
s = s+s; // line 17
std::cout<<s<<std::endl; // line 18
}
Test::Test(){
std::string s="abc"; // line 22
s = s+s; // line 23
std::cout<<s<<std::endl; // line 24
donothing();
}
int main(int argc, char *argv[]){
Test test;
return 0;
}
=============================
c++ -g -O0 Test.cpp -o test
The breakpoints set at line 22, 23, 24 are all ignored. However, the
breakpoints set at line 16, 17, 18 are all good to break the program.
What's the difference? They are doing the same thing. Why gdb treated
them differently? Thanks for your comments.
zl2k
next prev parent reply other threads:[~2007-06-12 3:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-11 17:00 kdsfinger
2007-06-11 17:22 ` Daniel Jacobowitz
2007-06-11 17:36 ` Jim Blandy
2007-06-11 20:21 ` Eli Zaretskii
2007-06-12 3:33 ` kdsfinger [this message]
2007-06-12 11:19 ` Daniel Jacobowitz
2007-06-12 11:29 ` Dave Korn
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=cac7ac540706112033r1c94b2ebl4b0bbb1c0b338254@mail.gmail.com \
--to=kdsfinger@gmail.com \
--cc=gdb@sourceware.org \
--cc=jimb@codesourcery.com \
/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