Should this work from the assembler window? The buttons appear to step to the next source line and manually setting a breakpoint by typing in an address appears to work on some architectures (PPC) but not others (SPARC).

Yes the button should do single step (whatever gdb belives a single instruction step to be), if supported by gdb.
You can also assign keys (like alt-f8 alt-f7); or make the default f7/f8 focus sensitive (so they single-inst-step if the asm win has focus).

If it does not work for you, please open the "Debug output" window from "view" / "debug windows" and check what command is sent to gdb.

Same problem here (using the current svn version on Linux (X86 32 Bits)

The debug output is:

<-exec-step>
^running
*running,thread-id="1"
(gdb)
*stopped,reason="end-stepping-range",frame={addr="0x08193167",func="CREATETIMER",args=[{name="this",value="0xb7b5a3d0"},{name="INTERVAL",value="1000"},{name="TIMERFUNC",value="..."}],file="fpgui/fpguiobject.inc",fullname="/home/mschnell/Downloads/svn/lazarus/trunk/lcl/interfaces/fpgui/fpguiobject.inc",line="154"},thread-id="1",stopped-threads="all",core="1" (gdb)

-Michael

Just tested on windows.

the correct output should be one of the following: <-exec-next-instruction>
<-exec-step-instruction>

To be absolutely sure:
- you are using the toolbutton, not the keyboard shortcut?

Can you confirm the settings in your "key mappings" (options dialog), in the node "Run menu commands" for
Step into
step over
step into instruction
step over instruction
Step into (context)
step over (context)

Martin wrote

To be absolutely sure: - you are using the toolbutton, not the keyboard shortcut?

I tried the toolbutton, the F7-Key and the Run->Step Into menu entry.

All do the same action as if the source code editor and not the "Assembler" window would have the focus. In fact after the action the source code editor has the focus.

Can you confirm the settings in your "key mappings" (options dialog), in the node "Run menu commands" for Step into

Yep

step over

Yep

step into instruction step over instruction

Where to find this ?

Step into (context) step over (context)

Right-Click on the "Assemble" Window only shows "Copy to clipboard" and no other context menu entries.

BTW.: There are no "dots" in the Assembler window to allow for setting breakpoints. Is this intentionally ?

-Michael

- The menu always acts as step-pascal-instruction / never step-asm
- F7 may act as step-asm, if configured as "(context)" see keymap below, and disa-ass window has focus => focus should be kept, in this case.
- Toolbutton (as in the toolbutton on top of the disass window) => now that sghould always send the step-asm instuction

Note: if you use the editor toolbar, and use a toolbuttoun there, then
that may equal to the menu, and not be intended to work)

So we need to find why the toolbutton does not work for you (that certainly is a bug). Do you use 0.9.30, fixes, or trunk?

Yep, what?
configured to be "F7" ?

This refers to the "options" dialog (tools or environment menu): "editor" / "key mapping"

> step over Yep

F8?

> step into instruction > step over instruction Where to find this ?

just a few lines below, in the same section of the keymap configuration.

This is about the option dialog. not the disass window.

BTW.: There are no "dots" in the Assembler window to allow for setting breakpoints. Is this intentionally ?

Simply not implemented yet.

As for the keyboard. I thing the default is alt-f7 alt-f8.

but you can change f7/f8 to react focus sensitive.

The main menu, does not currently have focus sensitivity, since if you click the menu, focus is always with the main-window....

Martin wrote

- Toolbutton (as in the toolbutton on top of the disass window) => now that sghould always send the step-asm instuction

My silly old eyes did not see _these_ Tool buttons. In fact they do work. Thanks !

IMHO, acknowledging that the Assembler Window has the context for the "Normal" Step, Instructions would be really nice, but of course not exactly necessary.

Thanks for your patience.

-Michael

last time I tried it out (6 months ago or so), the assembler window scrolled to the right as well as down. Eventually had to try out the TP/BP clone that came with fpc (FPIDE) to get something workable to debug some assembler.

but must admit that I didn't try the new Lazarus or trunk yet.

kind regards,
Dimitri Smits

Dimitri Smits wrote

last time I tried it out (6 months ago or so), the assembler window scrolled to the right as well as down. Eventually had to try out the TP/BP clone that came with fpc (FPIDE) to get something workable to debug some assembler. but must admit that I didn't try the new Lazarus or trunk yet.

I don't recall ever having seen that. So I don't know if it is fixed.

If you can test, and if it still happens, then "steps to reproduce" will be needed.

I'm very tied up with other (non-computer) things right now, but I can confirm that in the cases I was originally looking at (Linux on SPARC and PPC) I was using the buttons associated with the assembler source window.

Good point. Only available operation appears to be selecting text.

I've been looking at this on various platforms. I can't easily test Windows due to an apparent build problem, but on Linux and Solaris:

x86 (gtk2 and Qt): "Step into" (-> -exec-step-instruction) OK. "Step Over" (-> -exec-next-instruction") OK. Intel-format assembler, formatted OK.

ARM (gtk2, emulated by Qemu, not susceptible to alignment errors): Debugger access is erratic, works best if debug windows displayed before program run. "Step into" (-> -exec-step-instruction) OK. "Step Over" (-> -exec-next-instruction") OK. Assembler window shows tabs as \t.

PPC (gtk2): "Step into" (-> -exec-step-instruction) OK. "Step Over" (-> -exec-next-instruction") runs to termination or until it finds an explicit breakpoint. Assembler formatted OK.

SPARC (gtk2): "Step into" (-> -exec-step-instruction) appears to step over the next instruction if it's a call, however this appears to be an artifact of the way calls work (i.e. with a mandatory nop appended). "Step Over" (-> -exec-next-instruction") OK provided that the above is taken into consideration. Assembler window shows tabs as \t.

SPARC Solaris: as above.

Reliability in some cases might be improved by restarting Lazarus after a debugging session, particularly if the target program hasn't run to completion.

I think that the PPC problem is real, but if so it might be a gdb rather than a Lazarus issue. Single-stepping SPARC assembler requires a good understanding of the way calls work.

All 0.9.30.1 built with bigide using 2.4.4; Linux (Debian "Lenny" or "Squeeze") using X over SSH.

...

ARM (gtk2, emulated by Qemu, not susceptible to alignment errors): Debugger access is erratic, works best if debug windows displayed before program run. "Step into" (-> -exec-step-instruction) OK. "Step Over" (-> -exec-next-instruction") OK. Assembler window shows tabs as \t.

Can you send a sample (from the debug output window) of what data-disassemble returns? So I can see some data with \t

Or send the output from this. Whichever , on e is enough.

If "-exec-step-instruction" is sent, then it is a gdb issue. (Could be debug-info encoding from fpc, if there is debug info for that. I don't know if gdb would use that for single-instruction steps

Reliability in some cases might be improved by restarting Lazarus after a debugging session, particularly if the target program hasn't run to completion.

Try "Reset debugger" from menu "run". (Afaik, ctrl-F1)

Lazarus keeps gdb running. So if gdb is unstable, that may be an issue

This is from SPARC since I can run it natively- emulated ARM is a bit slow:

moonphase.pas:1345 Assert(test_jYear); 000825F4 7ffffcf1 call 0x819b8 <TEST_JYEAR> 000825F8 01000000 nop
000825FC 80a20000 cmp %o0, %g0
00082600 1280000d bne 0x82634 <MOONPHASE_init+472> 00082604 01000000 nop
00082608 01000000 nop
0008260C 9610001e mov %fp, %o3
00082610 94102541 mov 0x541, %o2
00082614 11000d2b sethi %hi(0x34ac00), %o0 00082618 90122118 or %o0, 0x118, %o0\t! 0x34ad18 <_$MOONPHASE$_Ld121>
0008261C 92100008 mov %o0, %o1
00082620 19000d2b sethi %hi(0x34ac00), %o4 00082624 98132128 or %o4, 0x128, %o4\t! 0x34ad28 <_$MOONPHASE$_Ld122>
00082628 9010000c mov %o4, %o0

First line is emboldened. Same code compiled with fpc -al -Sa

.Lj1041:
mov %i6,%o3
mov 1346,%o2
sethi %hi(_$MOONPHASE$_Ld121),%o0
or %o0,%lo(_$MOONPHASE$_Ld121),%o0
mov %o0,%o1
sethi %hi(_$MOONPHASE$_Ld122),%o4
or %o4,%lo(_$MOONPHASE$_Ld122),%o4
mov %o4,%o0
call FPC_ASSERT
nop

Test case: ran to a breakpoint on the Assert() above, stepped one assembler op, reset debugger. Ran to breakpoint again, assembler window step buttons were greyed. Closed assembler window, reopened, buttons now OK :-)

....

00082618 90122118 or %o0, 0x118, %o0\t! 0x34ad18 <_$MOONPHASE$_Ld121>

Please test with r 32171

Ok, that is indeed a problem of the IDE, ot GDB.

It appears, if the dis-ass window is kept open between 2 runs of the app, then it does not work, in the 2nd run.

buttons disabled, I do not even get the dis-ass content.

closing/opening the window helps

Couple of questions if I may: what's the on/off button for and is it intentional that the order of the assembler buttons is reversed when compared with the main IDE?

Mark Morgan Lloyd wrote

Couple of questions if I may: what's the on/off button for and is it intentional that the order of the assembler buttons is reversed when compared with the main IDE?

1) you may :)

2) on/off
A lot of debug windows have this. the button allows to disable the window. It allows faster debugging without the need to close the windows. e.g. If you temporarilly do not need the asm, watches, or whatever, then you do not want the debugger spend time to get the info for you. You could close the window, or switch it off.

It also allows you to freeze the current content, even if you stop debugging. So you still have the content for reference.

Since it was added, some of the benefits are no longer relevant, due to other changes. For example, the debugger now stops fetching if, if you press F8 (or otherwhise run/step the app). So the speed gain is rather minimal. (you only have to wait for one gdb command to be finished (for asm that still can take a bit); before this you had to wait for all open windows to finish)

For preserving data (not asm though), there is a history window now, that allows to view the watches, locals, stack, threads, of previous breaks.

3) There is no intention about the order. I never used the buttons in the IDE, so I never realized

Btw, you can switch off the dis-ass window, and still use the single instruction steps. the current location will update, as long as you are in already disassembled lines.

This is much faster. If you reach the limits of the window, or step in/out to/of a function, then you need to power on

Thanks. I didn't see any obvious change in the button state (or text colour etc.) so it wasn't clear what was going on.

For preserving data (not asm though), there is a history window now, that allows to view the watches, locals, stack, threads, of previous breaks.

I noticed it had been added fairly recently, but I'd not explored since it only showed up on a SPARC Solaris system which I'd had to update. In general I'm trying to be fairly conservative about my FPC and Lazarus versions- I've got enough problems as it is :-)

Mark Morgan Lloyd wrote

I noticed it had been added fairly recently, but I'd not explored since it only showed up on a SPARC Solaris system which I'd had to update. In general I'm trying to be fairly conservative about my FPC and Lazarus versions- I've got enough problems as it is :-)

Ah, well, and I updated (but trunk only) the button order you mentioned.

also "fixed" the windows none functionality after a debugger reset. (Though the buttons actually should only be enabled when the debugger is paused, and currently they are enabled even if the debugger runs....)

Still testing. Had problems, and for the moment I need to update SPARC FPC with a fix Florian's just done. I'll be back presently.

Martin, is there anything in your fix which could be causing a lockup at the start of the program run? Last console output as below.

Debugger] Running GDB version: C
[TDebugger.SetFileName]
"/usr/local/src/heavywethers/trunk/astro_references/project1" [TMainIDE.DoRunProject] B TGDBMIDebugger
[TMainIDE.DoRunProject] END
TGDBMIDebugger.StartDebugging
WorkingDir="/usr/local/src/heavywethers/trunk/astro_references/" [Debugger] Log output: &"set width 50000\n"

That's on SPARC Linux, Lazarus r32249, FPC 2.7.1 r19036. Haven't checked ARM etc. yet.

No, I don't think so. The fix for the assembler window wwas only in code, that was triggered when the debugger object got destroyed. Does the problem occur on the *first* attempt to run the app? Or only after you have "reset" the debugger (via "run" menu)?

The only change, I can think off that an affect startup is rev 32200. That is, this affects code that is executed during startup => but it actually fixes an issue where hte debugger became none responsive (though the issue would usually occur later during debugging)

What is in the Menu: "View" >"debug windows" > "debug output" ?

Ideally compile the IDE with the following defines (will cause a lot of console/log output): DBG_VERBOSE DBGMI_QUEUE_DEBUG

Can only do it once- hit the run button and the IDE is locked up.

I'm having to transcribe this manually since the IDE is locked up. Last few lines are

<-data-evaluate-expression FPC_THREADVAR_RELOCATE_PROC> ^done,value="0x0"
(gdb)
<-exec-arguments >
^done

Ideally compile the IDE with the following defines (will cause a lot of console/log output): DBG_VERBOSE DBGMI_QUEUE_DEBUG

Working on it. I presume that's something like make DBG_VERBOSE=1 DBGMI_QUEUE_DEBUG=1 bigide

I've reverted from FPC 2.7.1 to 2.4.4 which was previously OK (apart from floating-point code generation issues) without significant change to the IDE behaviour.

They must be passed to fpc as -dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG

so more like make bigide OPTS="-dDBG_VERBOSE -dDBGMI_QUEUE_DEBUG"

or maybe just OPT=

I always compile via the tools menu, so I don't know for sure

That's odd.

1) there is nothing around there in the debugger that could have any effect on the IDE => though the "dbg output" window can be updated delayed, and if your ide freezes, you may miss some lines => the console output will be more precise (if compiled with the defines)

2) if anything would crash gdb itself (e.g some dwarf encoding) then the IDE should still react (though the debugger would be stuck / looping with processmessages)
So the freeze of the IDe is unexplained...

Please disable all hints: "Options" / "Editor" / "completion and hints". Not only the debug hints, but all.

Depending on packages installed (or not installed) Laz trunk may have some issues (though I wouldn't expect it at the same location each time), hint errors go at random locations (whenever the mouse is left unattended over a word)

I've reverted from FPC 2.7.1 to 2.4.4 which was previously OK (apart from floating-point code generation issues) without significant change to the IDE behaviour.

And did that help?

I am using 2.7.1 ( updated in the last 2 days), but on win 32

There is debugger/test/GDBMI/TestGDBMI.lpi
A testcase, using the debugger class, but without the full IDE. Works only in Laz trunk though.
But it might help to see, if the issue is in the debugger part of Lazarus, or in the IDE elsewhere.

Until Ludo fixed the alignment issues I couldn't use the IDE on SPARC or ARM, so to get a working lazbuild on those platforms I had to get used to doing it with make. The upshot is that I've now got a useful set of scripts for the job (but who hasn't :-)

Martin wrote

Please disable all hints: "Options" / "Editor" / "completion and hints". Not only the debug hints, but all.

Noted. I'll report back when the build's completed which isn't very fast.

Not at all I'm afraid, i.e. the problem appears to stay with Lazarus rather than with the compiler.

If you start Lazarus inside gdb? and then interrupt it, and try to get a bt?

With debugging symbols, with hints disabled, with gdb. Console output follows, not sure you're going to like it.

> TCmdLineDebugger.SendCmdLn "set width 50000"

<< TCmdLineDebugger.ReadLn "&"set width 50000\n""
[Debugger] Log output: &"set width 50000\n"
<< TCmdLineDebugger.ReadLn "^done"
<< TCmdLineDebugger.ReadLn "(gdb) "

> TCmdLineDebugger.SendCmdLn "set inferior-tty /dev/pts/2"

^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0xf7f6daa0 (LWP 13397)]
0xf7f0f25c in __read_nocancel () from /lib/libpthread.so.0 (gdb) bt
#0 0xf7f0f25c in __read_nocancel () from /lib/libpthread.so.0 #1 0x00ae7450 in TPSEUDOTERMINAL__READ (this=0xf61fe580, result=0x0) at /usr/local/share/lazarus-trunk/debugger/gdbmimiscclasses.pp:539 #2 0x00ae7570 in TPSEUDOTERMINAL__CHECKCANREAD (this=0xf61fe580) at /usr/local/share/lazarus-trunk/debugger/gdbmimiscclasses.pp:546 #3 0x00aae40c in TGDBMIDEBUGGER__PROCESSWHILEWAITFORHANDLES (this=0xf61cad20)
at /usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:6878 #4 0x00a72cd4 in TCMDLINEDEBUGGER__WAITFORHANDLES (AHANDLES=<incomplete type>, ATIMEOUT=-1, highAHANDLES=0,
this=0xf61cad20) at
/usr/local/share/lazarus-trunk/debugger/cmdlinedebugger.pp:166 #5 0x00a738e8 in TCMDLINEDEBUGGER__READLINE (APEEK=false, ATIMEOUT=-1, this=0xf61cad20, result=0x0)
at /usr/local/share/lazarus-trunk/debugger/cmdlinedebugger.pp:423 #6 0x00a735bc in TCMDLINEDEBUGGER__READLINE (ATIMEOUT=-1, this=0xf61cad20, result=0x0)
at /usr/local/share/lazarus-trunk/debugger/cmdlinedebugger.pp:352 #7 0x00aba070 in TGDBMIDEBUGGERCOMMAND__PROCESSRESULT (ARESULT={STATE = DSNONE, VALUES = 0x0, FLAGS = []},
ATIMEOUT=-1, this=0xf5b7b980) at
/usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:9301 #8 0x00ab95bc in TGDBMIDEBUGGERCOMMAND__EXECUTECOMMAND (ACOMMAND=0xf5b94cd8 'set inferior-tty /dev/pts/2', ARESULT={STATE = DSNONE, VALUES = 0x0, FLAGS = []}, AFLAGS=[], ATIMEOUT=-1, this=0xf5b7b980)
at /usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:9123 #9 0x00ab9f88 in TGDBMIDEBUGGERCOMMAND__EXECUTECOMMAND (ACOMMAND=0x10d0e78 'set inferior-tty %s',
AVALUES=<incomplete type>, ARESULT={STATE = DSNONE, VALUES = 0x0, FLAGS = []}, AFLAGS=[], ATIMEOUT=-1,
highAVALUES=0, this=0xf5b7b980) at
/usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:9162 #10 0x00a9d074 in TGDBMIDEBUGGERCOMMANDSTARTDEBUGGING__DOEXECUTE (this=0xf5b7b980)
at /usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:3813 #11 0x00abe1e4 in TGDBMIDEBUGGERCOMMAND__EXECUTE (this=0xf5b7b980) at /usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:9904 #12 0x00aaa150 in TGDBMIDEBUGGER__RUNQUEUE (this=0xf61cad20) at /usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:5863 #13 0x00aaaa98 in TGDBMIDEBUGGER__QUEUECOMMAND (ACOMMAND=0xf5b7b980, FORCEQUEUE=false, this=0xf61cad20)
at /usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:5984 #14 0x00aae394 in TGDBMIDEBUGGER__STARTDEBUGGING
(ACONTINUECOMMAND=0xf5ccfaa0, this=0xf61cad20)
at /usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:6867 #15 0x00aae29c in TGDBMIDEBUGGER__STARTDEBUGGING
(ACONTINUECOMMAND=ECTCONTINUE, this=0xf61cad20)
at /usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:6851 #16 0x00aabd7c in TGDBMIDEBUGGER__GDBRUN (this=0xf61cad20) at /usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:6228 #17 0x00aad050 in TGDBMIDEBUGGER__REQUESTCOMMAND (ACOMMAND=DCRUN, APARAMS=<incomplete type>, highAPARAMS=-1,
this=0xf61cad20) at
/usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:6641 #18 0x005cdf14 in TDEBUGGER__REQCMD (ACOMMAND=DCRUN, APARAMS=<incomplete type>, highAPARAMS=-1,
this=0xf61cad20) at
/usr/local/share/lazarus-trunk/debugger/debugger.pp:5454 #19 0x005ce030 in TDEBUGGER__RUN (this=0xf61cad20) at /usr/local/share/lazarus-trunk/debugger/debugger.pp:5468 #20 0x005bf1e4 in TDEBUGMANAGER__RUNDEBUGGER (this=0xf6b842f0) at debugmanager.pas:2220
#21 0x005b6dcc in TDEBUGMANAGER__ONRUNTIMER (SENDER=0xf6226c80, this=0xf6b842f0) at debugmanager.pas:661
#22 0x003512b4 in TCUSTOMTIMER__DOONTIMER (this=0xf6226c80) at customtimer.pas:181
#23 0x003511d8 in TCUSTOMTIMER__TIMER (this=0xf6226c80) at customtimer.pas:156
#24 0x00322b98 in GTKTIMERCB (DATA=0xf61f0fd0) at gtk2callback.inc:2430 #25 0xf7840b40 in ?? () from /usr/lib/libglib-2.0.so.0 #26 0xf7840b40 in ?? () from /usr/lib/libglib-2.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?)

0 1>markMLl at pye-dev-04:/usr/local/share/lazarus$ gdb --version GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details.
This GDB was configured as "sparc-linux-gnu".

Ok, so we may have 2 debugger never returns on
set inferior-tty /dev/pts/2
which should have been created by the IDE.

or the IDE never gets the result, because something went wrong with creating it => but then it should not have gotten as far as sending the above...

So still the below stacktrace,. shows the IDE waiting for gdb to return output. yet it should do processMessages, so the ide should be responsive. Strange

anyway:
in options, on the debugger tab (where you select /usr/bin/gdb), is a list of setting (in an object inspector like grid) One of the settings is
ConsoleTty
it is empty by default.
Put /dev/null in there and see if it helps.

Or if you need to see the debugged apps terminal output, then open a terminal (xterm, or any other) yourself, type "pty", and it will give you something like /dev/pts/<n> which you can put into that setting (so long as you leave that terminal open.

I wonder why that hangs. Nothing there should have changed... unless some file/handle stuff in fpc changed? getpt() fcntl() tcsetattr() __write() ....

Argh, no => I overlooked the top 2 frames...

I do NOT like them (I do not know yet why not ..)

try the /dev/null
It should work around

At this point there should not be any data to be read. So the question is why on your system is read triggered.

I had a look at that code.

It looks like the error handling was all, but not appropriate. It is possible that pseudo terminal creation failed, or that your system has an issue with none blocking handles, then anything may have happened.

I added some checks, since it doesn't fail here, I am limited in what I can test.

Still locks up I'm afraid.

[Debugger] Log output: &"set width 50000\n"
<< TCmdLineDebugger.ReadLn "^done"
<< TCmdLineDebugger.ReadLn "(gdb) "

> TCmdLineDebugger.SendCmdLn "set inferior-tty /dev/null"

^C
Program received signal SIGINT, Interrupt.
[Switching to Thread 0xf7f51aa0 (LWP 2480)]
0xf7ef325c in __read_nocancel () from /lib/libpthread.so.0 (gdb) bt
#0 0xf7ef325c in __read_nocancel () from /lib/libpthread.so.0 #1 0x00ae7450 in TPSEUDOTERMINAL__READ (this=0xf5b0b460, result=0x0) at /usr/local/share/lazarus-trunk/debugger/gdbmimiscclasses.pp:539 #2 0x00ae7570 in TPSEUDOTERMINAL__CHECKCANREAD (this=0xf5b0b460) at /usr/local/share/lazarus-trunk/debugger/gdbmimiscclasses.pp:546 #3 0x00aae40c in TGDBMIDEBUGGER__PROCESSWHILEWAITFORHANDLES (this=0xf61aed20)
at /usr/local/share/lazarus-trunk/debugger/gdbmidebugger.pp:6878

Grabbing trunk and rebuilding. I'll also try some different architectures if possible.

You are right, sorry, there is a bunch of nested {$IFDEF}... (I must have had a bad day when I put that in)

the pseudo console is still accessed, even if you specify another one => I am fixing that now.... (next hour)

Still interested to know if the current trunk (error checking) helps.

Ok, in revision 32285, using /dev/null explicitly should skip the code that reads from the pseudo terminal. So in case the other fixes haven't done the job...

I still have no idea, why it fails on your system.

May have to add some debugln, but would first like to know, if trunk works (with and/or *without* the /dev/null)

- If it doesn't work without the dev/null then it may be that your system doesn't do none blocking read => but then it should return an erro when trying to set that property on the handle.

- If it does work without the dev/null then it would be intersting (debugln) to find out what error occurs, and to see if it could be made working somehow (without threads)

I was on r32275. OK on x86 and PPC (Linux), bad on SPARC. Currently compiling for ARM to see if it has the same effect, if so it implicates alignment.

Starting to look at that now, but will probably not have results for about an hour and a half (due to time building on a not-very-fast SPARC, and other commitments).

Below from r32287.

- If it doesn't work without the dev/null then it may be that your system doesn't do none blocking read => but then it should return an erro when trying to set that property on the handle.

Without an explicit /dev/null it locks up as before.

- If it does work without the dev/null then it would be intersting (debugln) to find out what error occurs, and to see if it could be made working somehow (without threads)

With an explicit /dev/null it appears to work fine.

Lazarus is still building for ARM, I'll report back when I know how that looks. I'll also check the exact kernel versions that the test systems have running, in case there's some problem.

Ok at least a workaround....

I'll see if I find the time => it should be simple to copy the code from unit GDBMIClasses) TPseoudoTerminal.Open /Read and make a small test app, that will open a pseudo terminal, set the handle to none-blocking read, and call read on it => and test if read will block or not.

Both SPARC and ARM now expand \t in the assembler window. I've still got a problem on ARM (i.e. Lazarus running on ARM, not a cross-compiler) where trying to display the assembler window when at a breakpoint causes the program to run, things are fine if the window is open before the program is started.

Ok, the below code, imualtes the pseudoterminal handling => the read is supposed to bne none blocking.

maybe some of the constants are indeed wrong for your system (endianess)?

program Project1;
{$mode objfpc}{$H+}
{$packrecords c}
// from unit IDEMiniLibC
uses
   ctypes
   //,libc
   ;
const
   clib = 'c';
   InvalHandle = -1;
   ICANON    = $0000002;
   ECHO      = $0000008;
   VMIN = 6;
   VTIME = 5;
   TCSANOW = 0;
   F_DUPFD   = 0;
   F_GETFD   = 1;
   F_SETFD   = 2;
   F_GETFL   = 3;
   F_SETFL   = 4;
   O_NONBLOCK = &04000;
   EINTR = 4;
   NCCS = 32;
type
   error_t = cint;
   tcflag_t = cuint;
   cc_t = cchar;
   speed_t = cuint;
   size_t = cuint;
   ssize_t = cint;
   Ptermios = ^termios;
   termios = record
     c_iflag : tcflag_t;
     c_oflag : tcflag_t;
     c_cflag : tcflag_t;
     c_lflag : tcflag_t;
     c_line : cc_t;
     c_cc : array[0..(NCCS)-1] of cc_t;
     c_ispeed : speed_t;
     c_ospeed : speed_t;
   end;
function __errno_location: pcint; cdecl;external clib name
'__errno_location';
function tcgetattr(__fd:cint; __termios_p: Ptermios):cint;cdecl;external
clib name 'tcgetattr';
function tcsetattr(__fd:cint; __optional_actions:cint; __termios_p:
Ptermios):cint;cdecl;external clib name 'tcsetattr';
function __read(Handle: cint; var Buffer; Count: size_t): ssize_t;
cdecl;external clib name 'read';
function __write(Handle: cint; const Buffer; Count: size_t): ssize_t;
cdecl;external clib name 'write';
function __close(Handle: cint): cint; cdecl;external clib name 'close';
function getpt:cint;cdecl;external clib name 'getpt';
function grantpt(__fd:cint):cint;cdecl;external clib name 'grantpt';
function unlockpt(__fd:cint):cint;cdecl;external clib name 'unlockpt';
function ptsname_r(__fd:cint; __buf:Pchar;
__buflen:size_t):cint;cdecl;external clib name 'ptsname_r';
function fcntl(Handle: cint; Command: cint; Arg: clong): cint;
cdecl;external clib name 'fcntl';
function errno : error_t;
begin
   Result:=__errno_location()^;
end;
// From TPseudoTerminal / unit GDBMIClasses
const
   BufLen = 100;
var
   ios: termios;
   i,int1: integer;
     FDeviceName: string;
     FPTy: Integer;
     FReadBuf: String;
begin
   FPTy := getpt;
   if FPTy < 0 then begin
     writeln('error getpt');
     exit;
   end;
   if (grantpt(FPTy) < 0) or (unlockpt(FPTy) < 0) then begin
     writeln('error grantpt / unlock');
     exit;
   end;
   setlength(FDeviceName, BufLen);
   if ptsname_r(FPTy, @FDeviceName[1], BufLen) < 0 then begin
     writeln('error ptsname');
     exit;
   end;
   setlength(FDeviceName,length(pchar(FDeviceName)));
   if tcgetattr(FPTy, @ios)  0 then begin
     writeln('error tcgetattr');
     exit;
   end;
   ios.c_lflag:= ios.c_lflag and not (icanon); // or echo);
   ios.c_cc[vmin]:= 1;
   ios.c_cc[vtime]:= 0;
   if tcsetattr(FPTy, tcsanow, @ios)  0 then begin
     writeln('error tcsetattr');
     exit;
   end;
   int1 := fcntl(FPTy, f_getfl, 0);
   if int1 = InvalHandle then begin
     writeln('error fcntlgetpt');
     exit;
   end;
   if fcntl(FPTy, f_setfl, int1 or o_nonblock) = InvalHandle then
   begin
     writeln('error fcntl');
     exit;
   end;
   writeln('now read');
   SetLength(FReadBuf, BufLen + 1);
   i := __read(FPTy, FReadBuf[1], BufLen);
   writeln(i);
end.

odd, there isn't any platform specific code there => the asm comes from gdb.

How exactly does the problem manifest itself?

anyway, can you get the console output? I may have to give you more defines, depending on what it says

Thanks, I'll work on that as soon as I have time. If it were a simple endianness issue I'd expect PPC (PowerPC, in an old Mac) to fail.

Funnily enough, I was wondering a few days ago whether anybody was using ptys with FPC or Lazarus. Is your debugger access the only place?

This system is not OK:

SPARC: Linux pye-dev-04 2.6.26-2-sparc64 #1 Mon Jun 13 17:02:25 UTC 2011 sparc64 GNU/Linux
GNU gdb 6.8-debian

These systems are OK:

ARM: Linux pye-dev-07a 2.6.32-5-versatile #1 Tue Mar 8 19:11:56 UTC 2011 armv5tejl GNU/Linux
GNU gdb (GDB) 7.0.1-debian

x86: Linux pye-dev-02 2.6.32 #1 SMP Thu Dec 10 15:56:27 GMT 2009 i686 GNU/Linux
GNU gdb 6.8-debian

PPC: Linux pye-dev-05 2.6.26-2-powerpc #1 Wed May 12 23:44:56 UTC 2010 ppc GNU/Linux
GNU gdb 6.8-debian

SPARC: SunOS pye-dev-08 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Fire-280R Solaris
GNU gdb 6.8

All above trunk (r32275 approx) with 2.4.4. Given that the problem is seen on SPARC Linux:

* the fact that PPC is OK suggests that it's not an endianness issue.

* the fact that SPARC on Solaris and ARM on Linux are OK suggests that it's not an alignment issue.

* we also know that it's not directly associated with a kernel or gdb version.

I think that leaves the prime suspect being some constant that varies on a platform by platform basis. s/constant/value/ :-)

Don't know, but I guess. Initially there were issues, because I used the fpc libc unit, then someone from the team helped out, and created the IDEMiniLibc. => so that did not exist before.

The code itself is actually from MSEIde (thanks to Martin S.).

For some reason that reminded me of a discussion of serial access on OSX in the fpc-pascal ML a few days ago. Nobody actually said in that thread that that varied by architecture, but a bit of Googling got me http://comments.gmane.org/gmane.linux.kernel/1093174 hence on one of my systems

$ find . -name fcntl.h -exec grep O_NONBLOCK \{\} \; -print

#define O_NONBLOCK 0x4000
./include/asm-sparc64/fcntl.h

etc. Also fpc/.../linux/ostypes.inc specifically has a different value for SPARC... GOK who's originally responsible for that inconsistency.

I added a ifdef, as found in the fpc source.

Most curious that it depends on CPUsparc , instead of OSsomething.

Since I have no means of testing, could I asked you, please?

More details as below. Starting with the assembler window not displayed, and running to a breakpoint in the source window:

<< TCmdLineDebugger.ReadLn "(gdb) "

> TCmdLineDebugger.SendCmdLn "-stack-list-frames 0 2"

<< TCmdLineDebugger.ReadLn
"^done,stack=[frame={level="0",addr="0x00083be0",func="MOONPHASE_init",file="moonphase.pas",fullname="/usr/local/src/heavywethers/trunk/moonphase.pas",line="1002"},frame={level="1",addr="0x00037d90",fu" .(269)..
"n",file="HeavyWethers.lpr",fullname="/usr/local/src/heavywethers/trunk/HeavyWethers.lpr",line="40"}]" << TCmdLineDebugger.ReadLn "(gdb) "
Exec done
Leaving Queue with count: 0 Recurse-Count=0 State=Pause Executing (Recurse-Count=0) queued= 0 CmdPrior=1 CmdMinRunLvl=-1 : "TGDBMIDebuggerCommandLocals:" State=Pause PauseWaitState=0

> TCmdLineDebugger.SendCmdLn "-stack-list-arguments 1 0 0"

<< TCmdLineDebugger.ReadLn "^done,stack-args=[frame={level="0",args=[]}]" << TCmdLineDebugger.ReadLn "(gdb) "

> TCmdLineDebugger.SendCmdLn "-stack-list-locals 1"

<< TCmdLineDebugger.ReadLn "^done,locals=[]"
<< TCmdLineDebugger.ReadLn "(gdb) "
Exec done
Leaving Queue with count: 0 Recurse-Count=0 State=Pause

########### Now sitting on breakpoint in source window. ########### View -> Debug windows -> Assembler
########### Program runs without stopping.
########### At program's login dialogue tell it to abort.

INFO: TDBGDisassembler.FindRange: Address not found 539616 wanted-before=5 wanted-after=22 in map with count=0 Executing (Recurse-Count=0) queued= 0 CmdPrior=30 CmdMinRunLvl=-1 : "TGDBMIDebuggerCommandDisassembe: FromAddr=539616 ToAddr=539616 LinesBefore=5 LinesAfter=22" State=Pause PauseWaitState=0

> TCmdLineDebugger.SendCmdLn "-data-disassemble -s 539575 -e 539576

-- 0"
<< TCmdLineDebugger.ReadLn ""
[WARNING] TGDBMIDebugger: ExecuteCommand "-data-disassemble -s 539575 -e 539576 -- 0" failed.
INFO: TDBGDisassembler.Clear: map had count=0
Canceling: "TGDBMIDebuggerCommandDisassembe: FromAddr=539616 ToAddr=539616 LinesBefore=5 LinesAfter=22"

(lazarus:1183): Gtk-CRITICAL **: gtk_text_view_scroll_to_iter: assertion `yalign >= 0.0 && yalign <= 1.0' failed

########### Now have IDE "Debugger error ...
########### The GDB process is no longer running" box. ###########
########### The GDB command:
########### "-data-disassemble -s 539575 -e 539576 -- 0" ########### did not return any result.

r32281 2.4.4 gdb 7.0.1-debian

Restarting IDE, displaying assembler window and running to breakpoint (marked below with > at start of line):

   moonphase.pas:1001                Assert(test_jDayToSecs);
   00083BB4 84fcffeb                 bl              0x82dcc

<TEST_JDAYTOSECS>
00083BB8 000050e3 cmp r0, #0 00083BBC 0700001a bne 0x83be0 <MOONPHASE_init+332>
00083BC0 0b30a0e1 mov r3, r11 00083BC4 032ca0e3 mov r2, #768 ; 0x300 00083BC8 e92082e3 orr r2, r2, #233 ; 0xe9

   00083BCC f8009fe5                 ldr             r0, [pc, #248]  ;

0x83ccc <MOONPHASE_init+568>
00083BD0 0010a0e1 mov r1, r0

   00083BD4 f4409fe5                 ldr             r4, [pc, #244]  ;

0x83cd0 <MOONPHASE_init+572>
00083BD8 0400a0e1 mov r0, r4 00083BDC acd2feeb bl 0x38694 <fpc_assert>

   moonphase.pas:1002                Assert(test_jYear);

00083BE0 b1fcffeb bl 0x82eac <TEST_JYEAR>

00083BE4 000050e3 cmp r0, #0 00083BE8 0700001a bne 0x83c0c <MOONPHASE_init+376>
00083BEC 0b30a0e1 mov r3, r11 00083BF0 032ca0e3 mov r2, #768 ; 0x300 00083BF4 ea2082e3 orr r2, r2, #234 ; 0xea

   00083BF8 cc009fe5                 ldr             r0, [pc, #204]  ;

0x83ccc <MOONPHASE_init+568>
00083BFC 0010a0e1 mov r1, r0

   00083C00 c8409fe5                 ldr             r4, [pc, #200]  ;

0x83cd0 <MOONPHASE_init+572>
00083C04 0400a0e1 mov r0, r4 00083C08 a1d2feeb bl 0x38694 <fpc_assert>

   moonphase.pas:1008                Assert(test_Phase);

I've saved that file in case you want a copy by e.g. direct mail.

But Solaris and some other OSes have their own implementations of ostypes.inc, with constants eventually expressed by FPC's BaseUnix unit.

Is there any particular reason that you're redefining O_NONBLOCK, rather than using the one from BaseUnix?

Since I have no means of testing, could I asked you, please?

For the record, I have a Linux SPARC system set aside for developers here, and could send you an ARM image for Qemu if necessary.

Debugger now working on SPARC. I appear to have other problems during startup but I don't think they're yours. Many thanks for your help :-)

I didn't.

I am mainly windows. I have linux in a VM for testing. I did use libs, I was told I can't. Mattias provided the IdeMiniLibc. Where he took the values from I do not know.

If baseunix can be used then that is probably fine too.

glad there is process...

The C header files I found on Linux.

If baseunix can be used then that is probably fine too.

At the time of writing the value did not exist in the BaseUnix. The IDEMiniLibc has a comment about only putting things there that do not exist in the RTL.
If the value now exists, then it should be removed from IDEMiniLibc.

Mattias

It's certainly in 2.2.0 if not earlier, and as I've observed Lazarus now requires >2.4.4 to build.