Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #72506 > unrolled thread

Getting sensible information from gdb

Back to article view | Back to comp.lang.c

Contents

  Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-11 21:21 +0200
    Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 14:47 -0700
      Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 00:07 +0200
        Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 16:15 -0700
          Re: Getting sensible information from gdb James Kuyper <jameskuyper@verizon.net> - 2015-10-11 21:02 -0400
            Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 18:55 -0700
              Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 04:04 +0200
                Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 19:37 -0700
                  Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 05:16 +0200
              Re: Getting sensible information from gdb James Kuyper <jameskuyper@verizon.net> - 2015-10-12 00:01 -0400
                Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 06:06 +0200
                  Re: Getting sensible information from gdb James Kuyper <jameskuyper@verizon.net> - 2015-10-12 00:48 -0400
                    Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 07:08 +0200
            Re: Getting sensible information from gdb Keith Thompson <kst-u@mib.org> - 2015-10-11 18:56 -0700
      Re: Getting sensible information from gdb Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-11 18:14 -0400
        Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 00:20 +0200
          Re: Getting sensible information from gdb James Kuyper <jameskuyper@verizon.net> - 2015-10-11 21:07 -0400
            Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 03:59 +0200
              Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 23:21 -0700
                Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 23:32 -0700
                  Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 08:42 +0200
                    Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-12 17:13 +0100
                      Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 23:50 +0200
                        Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-13 01:39 +0100
                          Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 03:04 +0200
                            Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-13 14:13 +0100
                              Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 16:26 +0200
                                Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-13 17:16 +0100
                                  Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-13 18:27 +0200
                                    Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-14 00:17 +0100
                                      Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 02:26 +0200
                                        Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-14 03:59 +0200
                                          Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-14 13:04 +0100
                                            Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-15 12:48 +0200
                Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 08:41 +0200
        Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 16:18 -0700
          Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 01:22 +0200
            Re: Getting sensible information from gdb Geoff <geoff@invalid.invalid> - 2015-10-11 16:42 -0700
              Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 02:16 +0200
    Getting sensible information from gdb "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-11 18:59 -0700
      Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 04:09 +0200
        Re: Getting sensible information from gdb "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-11 19:28 -0700
          Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 04:59 +0200
            Re: Getting sensible information from gdb "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-12 07:10 -0700
              Re: Getting sensible information from gdb Rosario19 <Ros@invalid.invalid> - 2015-10-12 19:41 +0200
    Re: Getting sensible information from gdb Ian Collins <ian-news@hotmail.com> - 2015-10-12 17:59 +1300
      Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 07:36 +0200
        Re: Getting sensible information from gdb Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-11 22:59 -0700
          Re: Getting sensible information from gdb "Morten W. Petersen" <morphex@gmail.com> - 2015-10-12 08:27 +0200
            Re: Getting sensible information from gdb Johann Klammer <klammerj@NOSPAM.a1.net> - 2015-10-12 10:55 +0200
            Re: Getting sensible information from gdb Keith Thompson <kst-u@mib.org> - 2015-10-12 08:04 -0700
            Re: Getting sensible information from gdb Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-12 17:35 +0100
        Re: Getting sensible information from gdb Keith Thompson <kst-u@mib.org> - 2015-10-12 08:00 -0700
        Re: Getting sensible information from gdb James Kuyper <jameskuyper@verizon.net> - 2015-10-12 12:25 -0400

Page 3 of 3 — ← Prev page 1 2 [3]

#72552

On 12.10.2015 03:59, Rick C. Hodgin wrote:
> Morten W. Petersen wrote:
>> Is there something I can do to get
>> information of what's going on?
>
> Switch to Visual Studio and use a real debugger.
> You'll be amazed how much more capable that
> toolset is over gcc+gdb, and how much more
> productive you are with the Code Definition
> window, watches, autos, etc.  There is no comparison.
> Microsoft's VS buries all tools on *nix by an order
> of magnitude in my opinion.
>
> After you get it debugged, switch back.

I was thinking of using different debuggers and compilers
to reveal defects and find out why something doesn't work.

That said, there are different front-ends for gdb that can
make it more practical to use.  And if I need to log in via
a terminal to for example my Raspberry Pi, I can run gdb
locally on the Pi.

Do you have some examples of where the VS debugger was better
to use than gdb?

-Morten

[toc] | [prev] | [next] | [standalone]

#72554

Morten W. Petersen wrote:
> [Do you have an example...]

I made this a while back.

     http://www.visual-freepro.org/videos/2014_02_13__demonstrate_x86_debugger.ogv

It shows edit-and-continue, and you can see some
of its helper windows and full IDE/editor integration.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#72559

On 12.10.2015 04:28, Rick C. Hodgin wrote:
> Morten W. Petersen wrote:
>> [Do you have an example...]
>
> I made this a while back.
>
>       http://www.visual-freepro.org/videos/2014_02_13__demonstrate_x86_debugger.ogv
>
> It shows edit-and-continue, and you can see some
> of its helper windows and full IDE/editor integration.

Looks cool.  Fun to listen to as well. :)

-Morten

[toc] | [prev] | [next] | [standalone]

#72615

On Sunday, October 11, 2015 at 10:58:48 PM UTC-4, Morten W. Petersen wrote:
> On 12.10.2015 04:28, Rick C. Hodgin wrote:
> > Morten W. Petersen wrote:
> >> [Do you have an example...]
> >
> > I made this a while back.
> >
> >       http://www.visual-freepro.org/videos/2014_02_13__demonstrate_x86_debugger.ogv
> >
> > It shows edit-and-continue, and you can see some
> > of its helper windows and full IDE/editor integration.
> 
> Looks cool.  Fun to listen to as well. :)
> 
> -Morten

There is another feature I didn't show in that video.  Microsoft's
debugger has the ability to hover over any variable and inspect its
value in a popup window.  It can also hover over any pointer and
inspect its members in a popup window, with navigation into sub-pointers,
and into sub-pointers, and into sub-pointers, ... inspecting members
at each level.  You can also edit those members by clicking on the
value and changing it.

In the source code window or Code Definition Window, you can double-
click on a variable name to highlight it, and then drag-and-drop
into the watch window area, or into a memory window.

In short, it has a lot of GUI features which greatly speed up debugging.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#72652

On Mon, 12 Oct 2015 07:10:24 -0700 (PDT), "Rick C. Hodgin" wrote:
>On Sunday, October 11, 2015 at 10:58:48 PM UTC-4, Morten W. Petersen wrote:
>> On 12.10.2015 04:28, Rick C. Hodgin wrote:
>> > Morten W. Petersen wrote:
>> >> [Do you have an example...]
>> >
>> > I made this a while back.
>> >
>> >       http://www.visual-freepro.org/videos/2014_02_13__demonstrate_x86_debugger.ogv
>> >
>> > It shows edit-and-continue, and you can see some
>> > of its helper windows and full IDE/editor integration.
>> 
>> Looks cool.  Fun to listen to as well. :)
>> 
>> -Morten
>
>There is another feature I didn't show in that video.  Microsoft's
>debugger has the ability to hover over any variable and inspect its
>value in a popup window.  It can also hover over any pointer and
>inspect its members in a popup window, with navigation into sub-pointers,
>and into sub-pointers, and into sub-pointers, ... inspecting members
>at each level.  You can also edit those members by clicking on the
>value and changing it.
>
>In the source code window or Code Definition Window, you can double-
>click on a variable name to highlight it, and then drag-and-drop
>into the watch window area, or into a memory window.
>
>In short, it has a lot of GUI features which greatly speed up debugging.
>
>Best regards,
>Rick C. Hodgin

2 or 3 days ago i had done this what in the C language you can read is

unsigned  *p;

p=(unsigned*)malloc(len);

where the correct statement was

p=(unsigned*)malloc( len*sizeof(unsigned) );
or
p=           malloc( len*sizeof(unsigned) );

it was very good the program warn me there is one error for
one write out of bound...

do someone know gaussian elimination for matrix of bit?

there are many years i had to write that...in 3 days done...

when see how it work i think it is a miracle...
i can never debug at full that code [how?]
i make only some try with numbers for see if it is ok
for the easy case...

the debug was only for 'easy' 32x32 bit matrix because one more little
bit matrix for my code is not possible...

for factoring one little number of [40+40]80 bit [some second with
ECM] it was very slow with quadratic sieve [i think minutes] and here
at end print 2-20 lines of primes^(2*numbers) and 
90% of time find the result

the problem is find numbers a: a^2%n=factoredFromFactorBase
and not the matrix, even if i try to make value 
500000 for factor base and program seg fault in memory allocation fase
[but the problem is not the memory because the program run in few
MB... possible it is somewhere some number for allocation memory that
i thought can not be...]

[toc] | [prev] | [next] | [standalone]

#72572

Morten W. Petersen wrote:
>
> The version of the project that gives this error is here:
>
> https://github.com/morphex/smash_xml/tree/25221c21d163ec106abca704b0619e1375e5409c
>
> Is there something I can do to get information of what's going on?

A couple of small niggles that I don't think anyone else has pointed out:

"#define CHAR_SIZE sizeof(char)"

Why do you have this?   sizeof(char) is, by definition, one.

"#define CONST const"

Why would you male const optional?  What is const is and what isn't isn't!

Various _index types: just use size_t.

Already mentioned but worth repeating: ditch the inline stuff.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#72575

On 12.10.2015 06:59, Ian Collins wrote:
> Morten W. Petersen wrote:
>>
>> The version of the project that gives this error is here:
>>
>> https://github.com/morphex/smash_xml/tree/25221c21d163ec106abca704b0619e1375e5409c
>>
>>
>> Is there something I can do to get information of what's going on?
>
> A couple of small niggles that I don't think anyone else has pointed out:
>
> "#define CHAR_SIZE sizeof(char)"
>
> Why do you have this?   sizeof(char) is, by definition, one.

OK.

> "#define CONST const"
>
> Why would you male const optional?  What is const is and what isn't isn't!

Profiling.  What are the speed benefits of constants..  mostly
out of curiosity.

> Various _index types: just use size_t.

I'll need to take another look at those types and the ranges they
should have..  but I think some of those index ranges can safely
be 32 bits, while others like the read from file index should be 64
bits on 64 bit systems.

Now the majority of data in memory should be Unicode characters which
are stored as 32 bits, so there might be little advantage of working
with numbers "here and there" that are small.

Should I use size_t for everything or are there cases where there
are benefits of using a smaller type?

I know the width of the processor, 32 or 64 for example, means that
it is easier and faster to work with whole numbers instead of shifting
and masking.

> Already mentioned but worth repeating: ditch the inline stuff.

Yeah, I removed from the functions but the macro was hanging
around in globals.h

-Morten

[toc] | [prev] | [next] | [standalone]

#72576

On Monday, October 12, 2015 at 6:35:45 AM UTC+1, Morten W. Petersen wrote:
>
> Should I use size_t for everything or are there cases where there
> are benefits of using a smaller type?
> 
This is the problem.
size_t was invented as type to hold an amount of memory, without
the designers realising the implications. It's not much use passing
a size_t as the element size argument to qsort unless you also
use the same type for the count argument, otherwise the interface
could still break. So size_t is used for variables which hold amounts 
of memory in bytes, variables that hold counts of items in memory,
and so, logically, also index variables.

But that's practically all the integers in the program. int just
disappears. But it's poorly-named, and it's unsigned. None of 
these values can be negative, but that's a characteristic of negative
number, they don't actually have a physical meaning, they're 
imaginary numbers, a notational convenience to make a certain
system of symbol manipulation easier. Intermediate  calculations
can and frequently do go negative. Simple code like

Point2 *zigzag;
size_t Nzigzags;
size_t i;

for(i=0;i<Nzigzags-1;i++)
  drawline(zigzag[i], zigzag[i+1]); 

fails when zigzag is empty. The only gain you get, in practice, 
is that you can declare an array of chars which takes up more than 
half the program's address space. How many programs are designed 
to operate on a single monster string?
 

[toc] | [prev] | [next] | [standalone]

#72581

On 12.10.2015 07:59, Malcolm McLean wrote:
> On Monday, October 12, 2015 at 6:35:45 AM UTC+1, Morten W. Petersen wrote:
>>
>> Should I use size_t for everything or are there cases where there
>> are benefits of using a smaller type?
>>
> This is the problem.
> size_t was invented as type to hold an amount of memory, without
> the designers realising the implications. It's not much use passing
> a size_t as the element size argument to qsort unless you also
> use the same type for the count argument, otherwise the interface
> could still break. So size_t is used for variables which hold amounts
> of memory in bytes, variables that hold counts of items in memory,
> and so, logically, also index variables.

Well I googled and read, and it was mentioned together with mem*
functions and some string functions.

Makes sense to be able to initialize large sections of memory to
zero for example.  Or clone a huge section of memory.

> But that's practically all the integers in the program. int just
> disappears. But it's poorly-named, and it's unsigned. None of
> these values can be negative, but that's a characteristic of negative
> number, they don't actually have a physical meaning, they're
> imaginary numbers, a notational convenience to make a certain
> system of symbol manipulation easier. Intermediate  calculations
> can and frequently do go negative. Simple code like
>
> Point2 *zigzag;
> size_t Nzigzags;
> size_t i;
>
> for(i=0;i<Nzigzags-1;i++)
>    drawline(zigzag[i], zigzag[i+1]);
>
> fails when zigzag is empty. The only gain you get, in practice,
> is that you can declare an array of chars which takes up more than
> half the program's address space. How many programs are designed
> to operate on a single monster string?

I don't get this example.  You mean when Nzigzags is zero?

-Morten

[toc] | [prev] | [next] | [standalone]

#72604

On 10/12/2015 08:27 AM, Morten W. Petersen wrote:
> 
> I don't get this example.  You mean when Nzigzags is zero?
> 
> -Morten
> 
yes, and it will underflow in the compare to the size_t maximum value.

[toc] | [prev] | [next] | [standalone]

#72619

"Morten W. Petersen" <morphex@gmail.com> writes:
> On 12.10.2015 07:59, Malcolm McLean wrote:
>> On Monday, October 12, 2015 at 6:35:45 AM UTC+1, Morten W. Petersen wrote:
>>>
>>> Should I use size_t for everything or are there cases where there
>>> are benefits of using a smaller type?
>>>
>> This is the problem.
>> size_t was invented as type to hold an amount of memory, without
>> the designers realising the implications. It's not much use passing
>> a size_t as the element size argument to qsort unless you also
>> use the same type for the count argument, otherwise the interface
>> could still break. So size_t is used for variables which hold amounts
>> of memory in bytes, variables that hold counts of items in memory,
>> and so, logically, also index variables.
>
> Well I googled and read, and it was mentioned together with mem*
> functions and some string functions.
>
> Makes sense to be able to initialize large sections of memory to
> zero for example.  Or clone a huge section of memory.

You should be aware that Malcolm's dislike of size_t is a minority
position.  My own opinion, and probably that of most C programmers,
is that size_t is usually the right type to use for sizes and for
counts of objects in memory.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#72634

"Morten W. Petersen" <morphex@gmail.com> writes:

> On 12.10.2015 07:59, Malcolm McLean wrote:
<snip>
>> [...] Intermediate  calculations
>> can and frequently do go negative. Simple code like
>>
>> Point2 *zigzag;
>> size_t Nzigzags;
>> size_t i;
>>
>> for(i=0;i<Nzigzags-1;i++)
>>    drawline(zigzag[i], zigzag[i+1]);

  for (size_t s = 1; s < Nzigzags; s++)
      drawline(zizgag[s - 1], zigzag[s]);

(a) putting the declaration in the for loop make the type obvious at a
glance;
(b) starting at 1 means you never subtract from an unsigned zero;
(c) calling the counter s avoids the casual assumption that i is an int.

>> fails when zigzag is empty. The only gain you get, in practice,
>> is that you can declare an array of chars which takes up more than
>> half the program's address space. How many programs are designed
>> to operate on a single monster string?
>
> I don't get this example.  You mean when Nzigzags is zero?

Yes, when Nzigzags is zero the test in the loop compares i with the
largest representable size_t.

One's history can make a difference here.  I started with C when int was
often 16 bits and size_t was very handy.  As a result I learned how to
loop over unsigned values early on.  If you are used to ints being large
enough to index any array you are likely to make, then size_t probably
looks like an anachronism with programming pitfalls lurking for the
uninitiated.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#72618

"Morten W. Petersen" <morphex@gmail.com> writes:
> On 12.10.2015 06:59, Ian Collins wrote:
[...]
>> "#define CONST const"
>>
>> Why would you male const optional?  What is const is and what isn't isn't!
>
> Profiling.  What are the speed benefits of constants..  mostly
> out of curiosity.

"const" and "constant" are two very different things, even though
the keyword "const" is obviously derived from the English word
"constant".

The "const" keyword really means "read-only".  A "constant" is a
literal, such as 42, 1.23, or 'x'.  A "constant expression" is one
that can be evaluated at compile time.

For example, this:
    const int r = rand();
is perfectly valid and meaningful; r is const, but obviously not
constant.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#72628

On 10/12/2015 01:36 AM, Morten W. Petersen wrote:
> On 12.10.2015 06:59, Ian Collins wrote:
...
>> "#define CONST const"
>>
>> Why would you male const optional?  What is const is and what isn't isn't!
> 
> Profiling.  What are the speed benefits of constants..  mostly
> out of curiosity.

The main benefit of 'const' is the error messages when it triggers when
it is mis-used. If you deal with those error messages correctly, then
you will have fixed a corresponding defect in your code, if you deal
with them incorrectly, you will have effectively disabled 'const',
covering up that same defect, without actually removing it. In the
unlikely event that you and everyone else who will have to maintain your
code are incapable of making such errors, then there's no need to use
'const'. Occasionally it allows the compiler to identify optimization
possibilities, but that's more the case in C++, where 'const' can
determine which overloaded function to call.
-- 
James Kuyper

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web