jacob said:
Geee How impressing pal...
I am speechless. WOW!!!
You shouldn't be. You say you've worked on embedded systems so you
should be familiar with some of the other wonderful tools available.
BUT
(Psss... You are in the debugger. So, your camera is still sending
stuff anyway, as you say, during the time when you look at the
name of the function the camera is still sending stuff.)
No, I used a variety of tools *including* debuggers, but not debuggers
exclusively.
This is typical of contributions where the only objective is to
impress other people with "stories". Reminds me of the discussions
of old people where each one tells their hospitals horror stories...
I'm not that old, and some of the people I know who are that old are
more interested in learning things than you seem to be.
Geee, how impressing. And when the software crashes, what happens?
Well, on that particular piece of software I used a variety of methods...
Getting a hardware engineer to hook up a logic analyser and set up
tracing on specific items of data so I could monitor them over a long
period (a second being a very long time)...
Reading the comments in the code and comparing what was actually done to
what the comments said (which showed up several serious errors)...
Because, (as you know) software crashes do happen.
We were in the debugger remember?
No, I wasn't. That was not, on this occasion, the best tool I had available.
This discussion is about how to easy the debugging tasks. Obviously
(like other "regulars" here), "Flash Gordon" never uses a debugger.
I do use debuggers, I just don't use them all the time. Some times it is
not practical for all sorts of reasons, other times it is the fastest
method (if you get a segmentation violation it is the easiest way to see
what line of code and then work your way up the backtrace to see what
was passed in).
Discussion in this group reminds me of my school days, when each
told "stories" designed to represent the one telling it in
the most heroic way...
How far away from software engineering.
No, it's real software engineering in the real world where you use the
best tool available, which is not always a debugger.
Heroic, yes. That is the word. The lone heroic story teller.
No, it was very easy. Get the logic analyser hooked up, tell it to
capture the relevant data, tell it to plot it on a graph, then look at
the graph. After the initial setup of the logic analyser (which took the
hardware engineer a while) it was only a matter of minutes of work to
get data captured and graphed.
Sure pal. You are a HERO!
No, and I actually used a debugger to solve it. It's just that the
methods you describe were not appropriate. I set it to break on a
specific data value it should hit and found it didn't. Then I tried
another value, and with a bit of experimentation (restarting the
software from scratch each time because I knew memory was corrupted) I
found approximately when it was crashing. Since the software could
obviously not cause the effect being seen I did some experimentation
writing values to the RAM and found the patterns that were not working.
But we were talking (at least I was talking) about how we can
write programs so that they are easier to debug. Among other
things, I proposed to avoid modifying the arguments so that
functions are restartable in the debugger. Obviously you
(as the other "regulars" like Mr Keighley) do not use a
debugger. Fine.
I never said that I never use a debugger. I've never used the method you
described, and often it would not be practical for reasons nothing to do
with what you describe.
Perhaps rather than being sarcastic you should accept that your method
is only one of MANy methods of debugging. Some of us will use whichever
method seems most appropriate at any given time.
Yes, but then you have to:
(1) jump to the end of the function
(2) Execute the epilogue
(3) then restart it when the call returns.
And all that could be avoided just by using a simple rule in the source
code.
Or you avoid ALL of that by...
(1) reading the disassemble to see how much the stack pointer (or
whatever) has been adjusted and set it back
(2) set the program counter (or equivilent) to the address of the code
where the arguments are evaluated and placed in to the parameters
(3) do any other required adjustments (which you missed in your
description above)
(4) start stepping through it.
No need to finish running the current run.
Oh, and I have sometimes used a debugger to set up parameters and start
a specific function manually. In fact, on one project, that was how ALL
of our unit tests were implemented!
Sure, I have done that too so what?
Then you should know it is easy.
It is something that I do not like
to do since requires a lot of effort for nothing!
gdb> frame 1
Examine line of code which does the call
Copy the expression for the first parameter using the mouse. Press "p"
followed by the space key, then paste the expression and hit return.
Repeat for each of the other parameters.
Quick and simple.
You are the one who thinks debuggers are wonderful, so you should know
how to do simple things like this quickly and easily! If it isn't easy
in your debugger then perhaps your debugger needs a bit more work doing
on it!
I just modify
the function so that the parameters aren't changed and I spare myself
all that work.
Unless, as other people have pointed out (and you ignored) the optimiser
has done the sensible thing and reused the space (or register) when it
was no longer needed even though your code did not change the parameter.
Yes, some of us use optimisers on our code!
But that is too much for an heroic "Flash Gordon"... obviously!
I may use the mane of a "super hero" as my nick, but there is nothing
heroic about any of the techniques I used.
Come on, grow up, will you?
I did a long time ago. Why don't you try it and learn that there are
other ways of doing things that are different.
I didn't even say that your method is never appropriate. I just said
that it is not always possible for any of a number of reasons.
