Jose Paul | 1 Aug 06:34 2003

GDB does not returns


Hi All,

Hi Alain,

Here is the program I am using.

/*----------------------------------------------------
 * eCos 'Hello world' example
 * --------------------------------------------------*/

#include <stdio.h>
//#include "library_example.h"

int main(int argc, char* argv[])
{
    int i;

    for (i=0; i<10; i++)
    {
      printf("Hello world!\n\r");
     }
    return 0;
}

I am using GDB  mipsel-elf-gdb.exe build GNU gdb 20030516.
My problem is that when I run the above program in command line it prints
Hello world
and is not returning to GDB.

(Continue reading)

Robin Rowe | 1 Aug 09:06 2003

Single-step runaway

I have a program that gdb doesn't seem to be able to enforce a breakpoint
on. As I single step through my code gdb suddenly takes the bit in its teeth
and slips away to run the program forward as though I had issued continue.
When I reach a particular function call in my code it simply takes off and
runs to completion (it's a batch process) rather than stepping into the call
as it should. If I stepi half a dozen times I can get inside the call and
single-stepping mostly works from there forward -- but not consistently so.
As a debugger it is almost unusable with this flaw. It would be faster to
use printf.

Other gdb users tell me they have encountered erratic behaviour like this
from time to time. Is this a known bug? Why is it happening? What can be
done about it?

FYI, there is nothing exotic about the function call that runs away. It is a
statically linked library C call. That library uses C++ internally, but the
interface is an extern "C" function call that passes a straight C struct.
All the code involved is code I wrote myself and compiled at the same time.
I'm running on RedHat 7.1. Tried compiling gdb 5.3 from source, but no
difference.

Suggestions?

Thanks,

Robin
---------------------------------------------------------------------------
Robin.Rowe <at> MovieEditor.com   Hollywood, California
www.CinePaint.org   Free motion picture and still image editing software

(Continue reading)

zhao mindong | 1 Aug 11:56 2003
Picon

Is there something wrong when disassemble?

void string_copy(char *str_from, char *str_to)
{  int i=0; // -------------------------------------------------------line 8
    for(; (*(str_to+i)=*(str_from+i))!='\0'; i++) ;
}
main()
{  static char array_str1[20]="I am a teacher.";
    char array_str2[20];
    string_copy(array_str1, array_str2);
}
(gdb) info line 8
Line 8 of "E:\BdxIDE\Bin\TestCase\main.c"
   starts at address 0x8100c038 <string_cop
   and ends at 0x8100c042 <string_copy+10>.
(gdb) info line *0x8100c044
Line 8 of "E:\BdxIDE\Bin\TestCase\main.c"
   starts at address 0x8100c042 <string_copy+10>
   and ends at 0x8100c046 <string_copy+14>.

why it is so diffrent??? wrong?
if i move" int i =0 " to next line then all is OK.how??

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Daniel Jacobowitz | 1 Aug 15:05 2003

Re: Single-step runaway

On Fri, Aug 01, 2003 at 12:06:48AM -0700, Robin Rowe wrote:
> I have a program that gdb doesn't seem to be able to enforce a breakpoint
> on. As I single step through my code gdb suddenly takes the bit in its teeth
> and slips away to run the program forward as though I had issued continue.
> When I reach a particular function call in my code it simply takes off and
> runs to completion (it's a batch process) rather than stepping into the call
> as it should. If I stepi half a dozen times I can get inside the call and
> single-stepping mostly works from there forward -- but not consistently so.
> As a debugger it is almost unusable with this flaw. It would be faster to
> use printf.
> 
> Other gdb users tell me they have encountered erratic behaviour like this
> from time to time. Is this a known bug? Why is it happening? What can be
> done about it?
> 
> FYI, there is nothing exotic about the function call that runs away. It is a
> statically linked library C call. That library uses C++ internally, but the
> interface is an extern "C" function call that passes a straight C struct.
> All the code involved is code I wrote myself and compiled at the same time.
> I'm running on RedHat 7.1. Tried compiling gdb 5.3 from source, but no
> difference.
> 
> Suggestions?

This usually means that GDB's stack unwinder has gotten confused.  You
may want to try using a compiler recent enough to emit DWARF CFI
information (GCC 3.2/3.3 should do; I don't know whether RH7.1's
compiler does or not) and a snapshot of GDB 6.0.  That combination
seems to be rather more robust.

(Continue reading)

David Carlton | 1 Aug 17:49 2003

-Wformat

I just downloaded mainline GDB for the first time in far too long, and
the recent -Wformat-nonliteral change breaks -Werror for me (compiling
with GCC 3.2.3).  I'll include the stderr output of 'make -k' from
within gdb/ after my signature; I haven't investigated them
thoroughly, but what I've look at makes me think that
-Wformat-nonliteral isn't a good idea.

David Carlton
carlton <at> kealia.com

cc1: warnings being treated as errors
breakpoint.c: In function `insert_breakpoints':
breakpoint.c:916: warning: format not a string literal, argument types not checked
breakpoint.c: In function `bpstat_stop_status':
breakpoint.c:2612: warning: format not a string literal, argument types not checked
breakpoint.c: In function `delete_breakpoint':
breakpoint.c:6545: warning: format not a string literal, argument types not checked
breakpoint.c: In function `breakpoint_re_set':
breakpoint.c:6948: warning: format not a string literal, argument types not checked
make: *** [breakpoint.o] Error 1
cc1: warnings being treated as errors
charset.c: In function `cached_iconv_convert':
charset.c:449: warning: format not a string literal, argument types not checked
make: *** [charset.o] Error 1
cc1: warnings being treated as errors
source.c: In function `forward_search_command':
source.c:1364: warning: format not a string literal and no format arguments
source.c: In function `reverse_search_command':
source.c:1460: warning: format not a string literal and no format arguments
make: *** [source.o] Error 1
(Continue reading)

Andrew Cagney | 1 Aug 18:07 2003
Picon

Re: -Wformat

> I just downloaded mainline GDB for the first time in far too long, and
> the recent -Wformat-nonliteral change breaks -Werror for me (compiling
> with GCC 3.2.3).  I'll include the stderr output of 'make -k' from
> within gdb/ after my signature; I haven't investigated them
> thoroughly, but what I've look at makes me think that
> -Wformat-nonliteral isn't a good idea.

`works for me'.  I tested it with:
gcc version 2.95.3 20010315 (release) (NetBSD nb3)
gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)

Looking at the first problem:

breakpoint.c: In function `insert_breakpoints':
breakpoint.c:916: warning: format not a string literal, argument types 
not checked

it revealed this little `gem':

   static char message1[] = "Error inserting catchpoint %d:\n";
   static char message[sizeof (message1) + 30];
	...
         sprintf (message, message1, b->number);

While getting the option working with a current GCC could mean more 
work, I'm not convinced that it's a bad idea.

Andrew

(Continue reading)

David Carlton | 1 Aug 18:18 2003

Re: -Wformat

On Fri, 01 Aug 2003 12:07:26 -0400, Andrew Cagney <ac131313 <at> redhat.com> said:

>> I just downloaded mainline GDB for the first time in far too long, and
>> the recent -Wformat-nonliteral change breaks -Werror for me (compiling
>> with GCC 3.2.3).  I'll include the stderr output of 'make -k' from
>> within gdb/ after my signature; I haven't investigated them
>> thoroughly, but what I've look at makes me think that
>> -Wformat-nonliteral isn't a good idea.

> `works for me'.  I tested it with:
> gcc version 2.95.3 20010315 (release) (NetBSD nb3)
> gcc version 2.96 20000731 (Red Hat Linux 7.2 2.96-112.7.2)

Actually, I lied slightly: I used GCC 3.2 Red Hat.  But I would assume
that any recent GCC would show this; the warnings are legitimate.

> Looking at the first problem:

> breakpoint.c: In function `insert_breakpoints':
> breakpoint.c:916: warning: format not a string literal, argument types
> not checked

> it revealed this little `gem':

>    static char message1[] = "Error inserting catchpoint %d:\n";
>    static char message[sizeof (message1) + 30];
> 	...
>          sprintf (message, message1, b->number);

Yup.  And further down in the log, you'll run into stuff like
(Continue reading)

Andrew Cagney | 1 Aug 18:29 2003
Picon

Re: -Wformat

> 
> Yup.  And further down in the log, you'll run into stuff like
> 
>   fprintf_filtered (stream, local_octal_format_prefix ());
> 
> which could easily be fixed by using fputs_filtered.

Outch, that's just bad.

>> While getting the option working with a current GCC could mean more
>> work, I'm not convinced that it's a bad idea.
> 
> 
> You're right: I was too pessimistic.  I just want the
> -Wformat-nonliteral patch reverted in the meantime. :-) (Actually, if
> you want to fix the warnings in question quickly, that's fine with me
> too: I can easily revert it on my local tree.)

But it `works for me'.  Can you fix the obvious ones and leave me with 
the messier problems, say?

Andrew

Daniel Jacobowitz | 1 Aug 18:33 2003

Re: -Wformat

On Fri, Aug 01, 2003 at 12:29:58PM -0400, Andrew Cagney wrote:
> >
> >Yup.  And further down in the log, you'll run into stuff like
> >
> >  fprintf_filtered (stream, local_octal_format_prefix ());
> >
> >which could easily be fixed by using fputs_filtered.
> 
> Outch, that's just bad.
> 
> >>While getting the option working with a current GCC could mean more
> >>work, I'm not convinced that it's a bad idea.
> >
> >
> >You're right: I was too pessimistic.  I just want the
> >-Wformat-nonliteral patch reverted in the meantime. :-) (Actually, if
> >you want to fix the warnings in question quickly, that's fine with me
> >too: I can easily revert it on my local tree.)
> 
> But it `works for me'.  Can you fix the obvious ones and leave me with 
> the messier problems, say?

It's hardly David's fault you're still using a stone-age compiler :)

*ducks*

--

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

(Continue reading)

David Carlton | 1 Aug 18:46 2003

Re: -Wformat

On Fri, 01 Aug 2003 12:29:58 -0400, Andrew Cagney <ac131313 <at> redhat.com> said:

> But it `works for me'.

I was wondering about that.  Am I the only person who compiles with
-Werror and who uses GCC 3.x?  I would have expected somebody else to
have noticed.  Still, it's only been in the tree for a week.

> Can you fix the obvious ones and leave me with the messier problems,
> say?

Sure, that should be easy enough.

David Carlton
carlton <at> kealia.com


Gmane