| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1311.1 | p,px,po work OK with ladebug (aka decladebug) | SUBPAC::FARICELLI | | Thu May 22 1997 09:49 | 27 |
|
The problem with dbx seems to be a bug. It works OK with ladebug,
which is the preferred debugger for Fortran 77 and 90.
fermi-537> ladebug ~/a.out
Welcome to the Ladebug Debugger Version 4.0-14A
------------------
object file name: /uogsrv_u2/faricell/a.out
Reading symbolic information ...stop at 2
done
(ladebug) stop at 2
[#1: stop at "zot.f":2 ]
(ladebug) run
[1] stopped at [test:2 0x1200017a4]
2 I=100
(ladebug) step
stopped at [test:3 0x1200017b0]
3 end
(ladebug) p i
100
(ladebug) px i
0x64
(ladebug) po i
0144
(ladebug) quit
-- John Faricelli
|
| 1311.2 | Want to QAR it? | QUARRY::petert | rigidly defined areas of doubt and uncertainty | Thu May 22 1997 13:14 | 19 |
| Well, yeah, its a small bug. The fortran process just prints integers
as integers, and pays no attention to the mode you want to print
things in. Ladebug, on the other hand, doesn't bother going through
a routine to print this, but just uses the printf routine through
an alias. So 'px' is really printf "0x%lx". If you were to feed
the same printf command to dbx, you would get the desired results.
But fixnig dbx to do the right thing is fairly simple. You
might want to enter a QAR on the matter, but if you don't I probably
will.
Note that currently po in ladebug is just printf "0%o", and will
truncate any sufficiently large number. I've pointed this out to
them though, so they should be changing it, I would hope.
Of course I got a QAR just this morning that complains that since
his .dbxinit file asks to print things in hex, one of the commands he
uses complains because the number IS hex. Sigh...
PeterT
|
| 1311.3 | need more info | TLE::WHITLOCK | Stan Whitlock | Sat May 24 1997 10:21 | 24 |
| >> When using DBX in UNIX 4.0b with fortran 4.1, a very simple program
>> could produce some problem.
>> The program is:
>> Program
>> I=100
>> end
>> compiler command is :
>> f77 -g test.f
>> The other problem is run time error.
>> A program has been running successfully on alphaserver1000 system with
>> UNIX 3.2G and fortran 3.7 or fortran 3.8. But when running it on the
>> alpha system with UNIX 4.0B and fortran 4.1, it produces a run time
>> error FPE: 65. The last macro command executed before the error is :
>> CALL PIL.
>> Any idea for solve the problem?
No idea - I don't see this error and I have no idea where it's coming from. And
what is "CALL PIL"?
When run under dbx, what error do you see exactly? Can you show us the
messages?
Thanks /Stan
|
| 1311.4 | 2 problems and 2 programs, right? | QUARRY::petert | rigidly defined areas of doubt and uncertainty | Tue May 27 1997 11:37 | 14 |
| Stan, I think they are writting about 2 different problems here.
The first is about dbx, and that it doesn't print in octal or hex
when asked to with the po or px command. No particular error messages,
just not the output you would expect to see. I know what the
problem is here, and I should be putting in a fix soon.
I think they have an entirely different program that results in
a floating point error, and that is the one that produces a
reference to call PIL. At least that's how I interpret it, though
I had also thought it was one program illustrating all the errors
when I first looked at this. We don't have the source for the second
problem...
PeterT
|
| 1311.5 | we need more info | TLE::WHITLOCK | Stan Whitlock | Wed May 28 1997 10:09 | 10 |
| RE: .4
>>I think they have an entirely different program that results in
>>a floating point error, and that is the one that produces a
>>reference to call PIL.
Ah, yes... I see. So, to "LAURAXU" in .0, please provide us with the example
{source and failing output} of the "call PIL" problem.
Thanks /Stan
|