What is a stack frame?

M

Morris Dovey

Richard said:
With every release gdb gets better in that respect. Having said that its
not something I know too much about (embedded systems that is).

"Embedded systems" spans quite a range - using devices that
barely qualify as CPU's to truly huge monsters that are nearly
indistinguishable from mainframes. In my experience, the primary
difference has been that the embedded critter has been limited in
purpose and has been shoehorned into the least amount of silicon
that could be managed - with (frequently) more stringent
performance and reliability demands. I enjoy working "close to
the hardware" and I seem to have a knack for small/fast/reliable
code. There are a lot of talents I /don't/ have, but those have
served me well in the work I've done.
clc is the only place I have seen so much resistance to debugging. Some
mean it. Most are simply posing for the camera I think.

I don't think there's much posing going on here. There /are/ a
fair number of people here who did a lot of debugging before
there were debuggers and who developed other techniques that
serve their needs in the particular kinds of work they do. Some
/could/ use debuggers but don't seem to actually need 'em - and
some /need/ 'em but can't find one adequate for the task at hand
in the problem environment.

I'd probably be one of the few people saying that I don't use a
debugger, but if you pressed me I'd have to admit that on more
than one occasion I've _written_ a special-purpose debugger to
solve some particularly nasty problem. It's not that I don't like
debuggers, it's just that the one I needed never seemed to be
around.
 
R

Richard

It *is* just posturing. The regs (and reg wannabees like David) want to
feel like mathematicians - who are able to prove their programs correct,
w/o any testing. As we all know, this is a very appealing thought, but
one without much real world traction.

I have been involved in and managed large teams on big code
bases. Frankly the purists from this group would generally be out on
their ear within a few days.
 
R

Richard Heathfield

Richard said:

clc is the only place I have seen so much resistance to debugging. Some
mean it. Most are simply posing for the camera I think.

I think it's a mistake to equate not using a debugger with being resistant
to debugging. We all have to get the bugs out - that is, we all have to
debug - but we don't all have to do it in the same way.

I used to use debuggers heavily, until I discovered that I could find bugs
much quicker without them! Nowadays, like one or two others here, I
generally use gdb just to get a stack trace (not, of course, that there is
any such thing as a stack, as we all know), and that points me to the
right place to start looking, and I normally nail it down pretty quickly
after that. When I *don't*... ah, that's where the fun starts.

I certainly have no "religious" objections to using a debugger for stepping
through code or running to a breakpoint or whatever. A debugger just a
tool. When I think it's the best way to find a bug, I'll be the first to
reach for it. It's just that normally I don't find it necessary. That is
*not* a claim that I write bug-free code, and it's *not* a claim that I
don't need to do debugging - neither is true. It's just that I've found
debugging techniques that, for me, are a lot faster than using a debugger.
That doesn't mean that the same techniques would be faster for other
people.

My view is - catch the bug any way you can, and who *cares* how you did it?
 
R

Richard

Richard Heathfield said:
Richard said:



I think it's a mistake to equate not using a debugger with being resistant
to debugging. We all have to get the bugs out - that is, we all have to
debug - but we don't all have to do it in the same way.

A debugger is an intrinsic part of finding a deep rooted bug swiftly and
economically. It's why this exist.
I used to use debuggers heavily, until I discovered that I could find bugs
much quicker without them! Nowadays, like one or two others here, I

On what kind of code base? What size? How many contributors? How long
had you worked on that code? Who designed that code?
generally use gdb just to get a stack trace (not, of course, that there is
any such thing as a stack, as we all know), and that points me to the
right place to start looking, and I normally nail it down pretty quickly
after that. When I *don't*... ah, that's where the fun starts.

Yup. Set a HW breakpoint on the conditions the stack trace showed to
cause the crash. And not ALL bugs cause crashes dont forget. You need to
detect erroneous conditions which still allow the program to
continue. Another vote for HW break points.
I certainly have no "religious" objections to using a debugger for stepping
through code or running to a breakpoint or whatever. A debugger just a
tool. When I think it's the best way to find a bug, I'll be the first to
reach for it. It's just that normally I don't find it necessary. That
is
*not* a claim that I write bug-free code, and it's *not* a claim that I
don't need to do debugging - neither is true. It's just that I've found
debugging techniques that, for me, are a lot faster than using a
debugger.

What are these techniques? And please do not say printf....
That doesn't mean that the same techniques would be faster for other
people.

My view is - catch the bug any way you can, and who *cares* how you
did it?

My view is similar. But different. Learn how to use a good debugger
properly and then convince me that other hotch potch methods of
detecting a hard to find bug are better and totally preclude the use of
a debugger and all the tools it brings to "debug". They're so named for
a reason ...

Most people who I have met who "dont need a debugger" ended up being
totally clueless on what one does or how to use it properly. I do not
accuse you of that I might add.
 
I

Ian Collins

Richard said:
Richard said:



I think it's a mistake to equate not using a debugger with being resistant
to debugging. We all have to get the bugs out - that is, we all have to
debug - but we don't all have to do it in the same way.
The same applies to developing new code. I used to step through code to
check that it "worked", now I develop test first and simply revert
changes if they cause tests to fail.

The debugger is a good tool and it would be foolish not to use it,
especially when working with unfamiliar code. The problems start when
it becomes a crutch.

If you want to hone your testing and debugging skills, try spending some
time developing in a language without a decent debugger for a while. I
used to do PHP full time and I never did find a debugger for it.
My view is - catch the bug any way you can, and who *cares* how you did it?
A big +1 to that!
 
D

David Resnick

If you don't think the ability to set HW break points/watch conditions on
complex matches in order to stop the process possibly hours into a run
is not useful then I really do not know what to say. if you dont think
the ability to dynamically change run time parameters to force certain
trigger parameters is useful then I'm astonished.

The only thing I can guess is that you work on very small, well
structured code bases for which you are almost solely responsible for.

Nah, couple hundred thousand lines of code in the parts I work on
often, more in other parts, fairly complex realtime app. And you use
it I can say with moderate confidence (assuming you have a cell phone
with voice mail or call people with such, and don't blame me for the
UI, largely up to the phone companies).

That said, often our problems occur on customer sites with local
setups (e.g. very expensive switches) we don't have here. We can't
run under the debugger in their network on live systems. We need to
be able to do most of our debugging from logs and core files. And so
we try to make our log files very good...
And fair enough.

But some people here recommend against using them. There is a
difference.

I can't see recommending against what works for others. Mind you,
being too dependent on them wouldn't work well on our app, as
explained above.
Fair enough. Possibly. But I suspect your productivity would be much
better if you used one regularly. maybe. Maybe not. We'll not agree I'm
sure.


No. I would not.

I'd take them any day :)
"or the value of a variable or two". This is so open to interpretation
it is unbelievable. And as for the stack trace! What? There is NO
stack. Remember :-;


I disagree with them. Of course I respect them. I wonder how many
existing code bases they maintained and extended? I wonder how good
debuggers were back then? TBH, I'm sick of seeing that quote trotted
out. I know what a debugger can do. I use it to do it. There is NO WAY I
could find those bugs from a print out of a 2.5 Million line code
base. I suspect that the debuggers available then were a fraction of
what is available now.

Practice of Programming edition I had was 1999. Could be they've
changed their attitude since. Doubt it though, from what they wrote.
I would be interested to hear which bits of the following article you
disagree with:

http://dirac.org/linux/gdb/01-Introduction.php

Or is that guy wrong? Is Stallman wrong?

Um, that article was written by Peter J. Salzman? Where did Stallman
come into this? He is author of gdb, but ? I said it is a matter of
opinion. Anyway, Stallman is not a god (having seen him talk, IMHO he
is a bit of an odd duck. Anyway, there is no doubt he has written
some incredible apps). Neither are Kernighan and Pike. And their
quote starts "As a personal choice". What I was trying to show (and
think I said clearly) is not that it is bad practice/wrong/useless to
use a debugger. But that some experienced well regarded developers go
the other way and use it only sparingly.
It is IMO. Note the IMO. Maybe we have worked on different things. I can
only have my reasoned opinion. Developing code without using a good
debugger is, IMO, madness.

I guess that it is IMO makes it impossible to call you wrong, but can
you not see that "madness" is mighty strong? Developing with
relatively little use of the debugger works well for lots of people..
I do. And more importantly familiarisation.

How the heck do you familiarize yourself with 2.5 million lines of
code with a debugger? High level design documents would seem more
like it?
Valgrind is essential too.

I love Valgrind. I run our whole regression suite under valgrind,
really helps keep hard to find memory corruption errors from getting
to the field.
Emacs is falling behind the curve unfortunately. I use it too. I would
be interested to hear about your setup.

I gave up using ecb as it added no value. Semantic doesn't seem to do
much. Cscope and etags are ok. I never got code completion working
properly.

I use etags too. I mostly just use emacs for editing code (auto
indenting, keyword colorization, completion, etc), I don't use it as
an IDE (don't build from it, e.g.). We use clearmake and makefiles
for that... I like emacs clearcase integration as well.

-David
 
R

Richard

David Resnick said:
How the heck do you familiarize yourself with 2.5 million lines of
code with a debugger? High level design documents would seem more
like it?

Then you haven't used a good debugger enough.

A debugger enables you to set break points at the major parts of the
code as indicated by the support/API docs.

You can then look and feel the code by stepping/running through as
appropriate, modifying run time values to cause the program to take
other routes. Its just common sense really.

Your comments surprise me there.
 
R

Richard

Ian Collins said:
The debugger is a good tool and it would be foolish not to use it,
especially when working with unfamiliar code. The problems start when
it becomes a crutch.

The unfamiliar code is the #1 reason to use it.

I suspect many here espousing debugger free code rarely meddle in other
peoples code.
 
D

David Resnick

I have been involved in and managed large teams on big code
bases. Frankly the purists from this group would generally be out on
their ear within a few days.

I'd suggest hiring Kenny and Mr. Twink instead. I'm sure they are
great to work with. I expect many of the "purists" from this group,
when they don't have their (to my mind sometimes tedious/excessive)
CLC topicality hat on, do very skillful work. They do unportable
things. But I expect that they at least do them with their eyes open,
and know the tradeoffs that they are making, and isolate the non-
portable, etc. To me is one of the main virtues of know what is
strictly portable is to not unknowingly write unportable code. Having
had to take part in the migration of a big code base from MSVC/win32
to gcc/linux made me appreciate that, as did going through major gcc
version upgrades.

Kenny and Twink are destructive fools entertaining themselves and each
other. If they wanted to improve CLC they would choose other means
(e.g. actually helping posters instead of being a peanut gallery).
And wouldn't be afraid to post in their own names. Mind you, they are
wise not to do so, as I'd expect that any employer that googled them
wouldn't want to hire such "wits".

-David
 
R

Richard

David Resnick said:
I'd suggest hiring Kenny and Mr. Twink instead. I'm sure they are

You seem to mistake my opinion of some of the hard core (and after your
post I guess that includes you) with reasonable team players with a good
practical knowledge of C that muck in and help people and don't gain
satisfaction from playing one upsmanship at every opportunity.
great to work with. I expect many of the "purists" from this group,
when they don't have their (to my mind sometimes tedious/excessive)
CLC topicality hat on, do very skillful work. They do unportable

"When they don't". This is the issue you say. It's all a question of
when.
things. But I expect that they at least do them with their eyes open,
and know the tradeoffs that they are making, and isolate the non-
portable, etc. To me is one of the main virtues of know what is
strictly portable is to not unknowingly write unportable code. Having

90% of C I ever wrote never strayed from the target machine. So you
have a point about my lack of regard for overly pedantic standards
adherence.
had to take part in the migration of a big code base from MSVC/win32
to gcc/linux made me appreciate that, as did going through major gcc
version upgrades.

None of this makes one iota of a difference with regard to a stack and
using a debugger of course. I migrated a huge code base from Windows to
OS/2 and then onto Linux. It wasn't that hard. Compile, read warnings,
tinker, run, debug. repeat. Works.
Kenny and Twink are destructive fools entertaining themselves and each

I find them quite amusing. And they have a good point. I haven't seen
them savaging noobs or getting easy things wrong in their haste to show
off first.
other. If they wanted to improve CLC they would choose other means
(e.g. actually helping posters instead of being a peanut gallery).

Why aren't you telling others this?
And wouldn't be afraid to post in their own names. Mind you, they are
wise not to do so, as I'd expect that any employer that googled them
wouldn't want to hire such "wits".

Oh dear me. You let yourself down a little bit there. The "own name"
thing is ridiculous. "John Smith" could as easily be "Antonio Nonothing".
 
A

Antoninus Twink

I expect many of the "purists" from this group, when they don't have
their (to my mind sometimes tedious/excessive) CLC topicality hat on,
do very skillful work.

Some of the regulars in this group clearly have technical ability, while
others are blithering idiots (CBF and Default Loser spring to mind). But
the real point is that their obstructive attitudes and complete lack of
social skills would mean they just wouldn't fit in most programming
teams. Nowadays, with big projects being the norm, programming requires
teamwork - not a lone wolf, a strutting, egomaniacal primadonna. But
that's exactly what's valued in clc, or at least it's what's valued
inside The Clique.
Kenny and Twink are destructive fools entertaining themselves and each
other.

With respect, that's an absurd accusation. The "trolls" are constructive
rather than destructive - we want a better clc where real world C can be
discussed and sound advice dispensed.
And wouldn't be afraid to post in their own names.

What makes you think we aren't posting in our own names?
 
J

jacob navia

Richard said:
<snip>

I used to use debuggers heavily, until I discovered that I could find bugs
much quicker without them! Nowadays, like one or two others here, I
generally use gdb just to get a stack trace (not, of course, that there is
any such thing as a stack, as we all know),


Ahh you get a stack trace without stack.

It is incredible how much nonsense regulars can write in a few minutes.

Gosh!
 
D

David Resnick

Then you haven't used a good debugger enough.

A debugger enables you to set break points at the major parts of the
code as indicated by the support/API docs.

You can then look and feel the code by stepping/running through as
appropriate, modifying run time values to cause the program to take
other routes. Its just common sense really.

Your comments surprise me there.

I was talking about the scale. Within 2.5. million lines of code that
you cited, seems to me that good design documents are the better way
to understand the overall system architecture, messages flows,
interfaces, etc rather than stepping through code. I still don't see
how a "good" debugger would help. To get familiarized with a new code
base, I'd rather get a birds eye view than a worms eye view. All IMHO
of course.

And no, I'm certainly not an expert gdb user. I have used it to step
through code rarely (and disassemble it for that matter). And use it
on cores moderately often. Perhaps if I used it more I'd like it
better, but I don't feel the need.

-David
 
R

Richard

jacob navia said:
Ahh you get a stack trace without stack.

It is incredible how much nonsense regulars can write in a few minutes.

Gosh!

To defend Richard he was joking!
 
R

Richard

David Resnick said:
I was talking about the scale. Within 2.5. million lines of code that
you cited, seems to me that good design documents are the better way
to understand the overall system architecture, messages flows,

I said/meant code familiarisation.
interfaces, etc rather than stepping through code. I still don't see
how a "good" debugger would help. To get familiarized with a new code
base, I'd rather get a birds eye view than a worms eye view. All IMHO
of course.

The you really do NOT know how to use a debugger sufficiently well. And
I do not mean this as an insult. You can see the bigger picture very
quickly ESPECIALLY in conjunction with a run time profile.

Of course the high level docs are also important.

But high level docs don't necessarily help you find out why every 29 days
a end of day report crashes.
And no, I'm certainly not an expert gdb user. I have used it to step
through code rarely (and disassemble it for that matter). And use it
on cores moderately often. Perhaps if I used it more I'd like it
better, but I don't feel the need.

And gdb is the worst of the lot in terms of ease of use and UI.
 
R

Richard

Morris Dovey said:
I don't think there's much posing going on here. There /are/ a

No, you obviously don't. A shame. As it exists. You think a few of us
rebel against them for no reason?'
 
J

jacob navia

Richard said:
To defend Richard he was joking!

But the others are not

And he never really took position. The "official" position of
clc regulars is that there is no stack.
 
R

Richard

jacob navia said:
But the others are not

And he never really took position. The "official" position of
clc regulars is that there is no stack.

Which is of course, in the real world, total and utter nonsense in the C
programming world.
 
I

Ian Collins

jacob said:
But the others are not

And he never really took position. The "official" position of
clc regulars is that there is no stack.
What leads you to that conclusion?

It's obvious to all but a fool that most architectures use a stack some
or all of the time. It is also clear that there can be architectures
with conforming C implementations that do not use a stack.

The pertinent point is that the word "stack" does not appear in the C
standard.

So of course there are stacks, but they are not required in a conforming
implementation.
 
D

David Resnick

I said/meant code familiarisation.

Having moved to multiple different unrelated big chunks of code
written by different groups with different approaches and code
standards, still never felt the need. But as they say in perl land,
there's more than one way to do things.
The you really do NOT know how to use a debugger sufficiently well. And
I do not mean this as an insult. You can see the bigger picture very
quickly ESPECIALLY in conjunction with a run time profile.

No insult taken. I just don't feel the lack. I do lots of coding,
and lots of debugging of both the code I've written and that of
others. I've used profilers (quantify/oprofile) for optimization,
they were helpful. Not felt the urge otherwise.
Of course the high level docs are also important.

But high level docs don't necessarily help you find out why every 29 days
a end of day report crashes.

Again, I and a number of others are quite successful without heavy use
of a debugger for solving problems. You are convinced that we either
work on simpler systems than you do or that w'd be even more
successful if we used a debugger heavily as part of our development
process. Could be, hard to prove it is not the case. Still seems to
me that "madness" to not use a debugger as an integral part of
development is too strong, but I don't expect to convince you
otherwise.
And gdb is the worst of the lot in terms of ease of use and UI.

I'm always happy to learn new things. What debugger do you use? I
may try it. But as I said given limitations of tools available on our
customer sites (gdb for use on cores at best) I'll mostly continue to
muddle along the way I do.

-David
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top