Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
Japheth

Homepage

Germany (South),
13.04.2009, 18:35
 

FD Debug 1.15 (Announce)

FD Debug needed an update:

http://www.japheth.de/debxxf.html

there was a bug in v1.04-1.14 which has been fixed.

btw, GRDB also has got an update very recently! See LADSoft site!

---
MS-DOS forever!

Ninho

E-mail

17.04.2009, 11:07

@ Japheth
 

FD Debug 1.15

> FD Debug needed an update:
>
> http://www.japheth.de/debxxf.html

Are you the official maintainer ? There's a small annoyment in this and one (or a few more?) previous versions of the (free) debug : after breaking on int3 (one present in the debuggee, not one inserted by debug for processing BP) we want the "g" command (no parameters) to restart at the next instruction after the int3.

It maybe a matter of preference, but having used debug - or sid, its DRDOS counterpart - almost every single day for over 20 years I think I know what's convenient to a user and what's not.

When stopping on "unexpected" int3 please increment user ip before displaying instruction & registers. Whether you do this though, or prefer to display at the position of the int 3, absolutely please ensure that a "g" command without an explicit restart address continues execution after the int 3 !

---
Ninho

Japheth

Homepage

Germany (South),
18.04.2009, 08:12

@ Ninho
 

FD Debug 1.15

> Are you the official maintainer ? There's a small annoyment in this and
> one (or a few more?) previous versions of the (free) debug : after
> breaking on int3 (one present in the debuggee, not one inserted by debug
> for processing BP) we want the "g" command (no parameters) to restart at
> the next instruction after the int3.

Yes, this is a bug in v1.14-1.15.

---
MS-DOS forever!

rCX

Maryland, USA,
18.04.2009, 04:26

@ Japheth
 

FD Debug 1.15

> FD Debug needed an update:
>
> http://www.japheth.de/debxxf.html
>
> there was a bug in v1.04-1.14 which has been fixed.

Thanks for the update :-)

rCX

Maryland, USA,
20.04.2009, 21:22

@ Japheth
 

FD Debug 1.15

> http://www.japheth.de/debxxf.html

Hey Japheth, the link to the DEBUG tutorial is broken. I think it should be this...

http://www.japheth.de/Debug/Debug.txt

... instead of ...
http://www.japheth.de/Debug\Debug.txt

Japheth

Homepage

Germany (South),
20.04.2009, 22:03

@ rCX
 

FD Debug 1.16

> Hey Japheth, the link to the DEBUG tutorial is broken. I think it should
> be this...
>
> http://www.japheth.de/Debug/Debug.txt
>
> ... instead of ...
> http://www.japheth.de/Debug\Debug.txt

Fixed! There's now also a v1.16 which fixes the other bug mentioned recently (and some more).

---
MS-DOS forever!

Ninho

E-mail

21.04.2009, 13:17

@ Japheth
 

FD Debug 1.16

> Fixed! There's now also a v1.16 which fixes the other bug mentioned
> recently (and some more).

Thanks; still buggy though :=(

> m 1000 1007, 1010

... doesn't work (with or without commas, which BTW should always be optional, since nobody can remember where they are/aren't needed). It does not emit an error, but the move is not effected (or maybe /some/ undesired move is ?)

> m 1000L8 1010

works as awaited.

Regards...

---
Ninho

Japheth

Homepage

Germany (South),
23.04.2009, 13:02

@ Ninho
 

FD Debug 1.16

> Thanks; still buggy though :=(
>
> > m 1000 1007, 1010
>
> ... doesn't work (with or without commas, which BTW should always be
> optional, since nobody can remember where they are/aren't needed). It does
> not emit an error, but the move is not effected (or maybe /some/ undesired
> move is ?)

I'm unable to see the problem. Probably if you can post a more detailed error description a bug fix may be possible for v1.17 (which will come out soon because v1.16 contains a small regression which is to be fixed with v1.17).

---
MS-DOS forever!

Ninho

E-mail

23.04.2009, 20:41

@ Japheth
 

FD Debug 1.16

> I'm unable to see the problem. Probably if you can post a more detailed
> error description a bug fix may be possible for v1.17 (which will come out
> soon because v1.16 contains a small regression which is to be fixed with
> v1.17).

It's a very strange bug indeed, sometimes the move works and immediately afterwards a similar move doesn't. I don't have the time to dig now, honest - I just did this :

m 1000 1007 1010 (it worked)
m 1000 1007, 1020 (didn't work)
m 1000 1007, 1020 (again, didn't work)
m 1000 1007 1020 (no comma. worked!)

Don't focus on the comma, it may or may not be related to this bug. Sorry I must leave you now

---
Ninho

Ninho

E-mail

27.04.2009, 17:22

@ Japheth
 

FD Debug 1.16

> I'm unable to see the problem. Probably if you can post a more detailed
> error description a bug fix may be possible for v1.17 (which will come out
> soon because v1.16 contains a small regression which is to be fixed with
> v1.17).

Have you been able to locate the problem ? A little more exercising the interface, while not extensively, makes it look like I've been hitting a bug in the command parser - probably not limited to the "move" command : the bug seems to happen only when the command letter ("m" in this case) is immediately followed by the argument without intervening "blank". Then the move is (sometimes?) not effected and yet no error signaled! Either flag the absence of a blank after a command "verb" as an error - but it is valid syntax in both MSDOS debug/DRDOS sid - or ensure that the arguments are still parsed properly.

Regards

---
Ninho

Japheth

Homepage

Germany (South),
27.04.2009, 18:29

@ Ninho
 

FD Debug 1.16

> the bug seems to happen only when the command letter ("m" in this case) is
> immediately followed by the argument without intervening "blank".

Yes, a blank is needed to avoid ambiguity. Some commands consist of 2 letters, and if the second letter can be interpreted as a hex number, the parser has a tiny problem. This affects:

M - MC
I - ID
O - OD

There are no plans to change this.

---
MS-DOS forever!

Ninho

E-mail

27.04.2009, 21:12

@ Japheth
 

FD Debug 1.16

> Yes, a blank is needed to avoid ambiguity.
> M - MC
> I - ID
> O - OD

Ack.,

> There are no plans to change this.

But this is /bad/ if no feedback/warning/error is given on bad/ambiguous commands ! Furthermore, a command such as : m1000L8 1010 is nowhere ambiguous, yet it (seems to be) silently ignored by Fdebug !

IOW, the bug is not that a space is required after the "m" command (etc.), it is your choice, but the bug is that you do not emit an error message when the blank is missing. That needs repair IMHO ;=)

---
Ninho

Japheth

Homepage

Germany (South),
28.04.2009, 07:58

@ Ninho
 

FD Debug 1.17

> But this is /bad/ if no feedback/warning/error is given on bad/ambiguous
> commands ! Furthermore, a command such as : m1000L8 1010 is nowhere
> ambiguous, yet it (seems to be) silently ignored by Fdebug !
>
> IOW, the bug is not that a space is required after the "m" command (etc.),
> it is your choice, but the bug is that you do not emit an error message
> when the blank is missing. That needs repair IMHO ;=)

Ok, now there's an error msg in such cases.
v1.17 also fixes a regression in v1.16's R command.

---
MS-DOS forever!

Ninho

E-mail

28.04.2009, 12:00

@ Japheth
 

FD Debug 1.17

>> you do not emit an error message
>> when the blank is missing. That needs repair IMHO ;=)
>
> Ok, now there's an error msg in such cases.

Sweet !

-m1000 1007 1010
          ^ Error

I'd prefer the caret to appear under the first "1" rather than the blank after "1000", but admittedly it is now little more than a cosmetic fix.

> v1.17 also fixes a regression in v1.16's R command.

Regards...

---
Ninho

Japheth

Homepage

Germany (South),
19.05.2009, 10:22

@ Japheth
 

Debug 1.18

http://www.japheth.de/debxxf.html

---
MS-DOS forever!

Ninho

E-mail

19.05.2009, 12:31

@ Japheth
 

Debug 1.18

Thanks!

Here's a suggestion for enhancement - which you may like or not : add accelerated trace, from branch to branch instruction, using the DebugMSR [if present; else emulate the feature by doing an ordinary x86 trace but display only branch instructions to the user]

Regards,

---
Ninho

Back to index page
Thread view  Board view
22632 Postings in 2109 Threads, 402 registered users, 412 users online (0 registered, 412 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum