UAE debugger updates (executable debugging, segment tracking, symbols and more)

[sigma63]

Hello Toni,
now i'm playing with the 64bit Version under Win10.

If i load my program which has two hunks (code & data/bss) with uaedbg, it prints about a third hunk with size 4096 wich i think is for the stack, right? Could this size be configured?

Now if i start with "g" i get an illegal-memory-access-error: obviously access to uninitialized stack area.
I think this is due to my use of the SAS/C-Compiler and the linkage with the normal startup-module c.o. This code tries to get the stack-base wich is a (possible undocumented?) parameter on the stack.

*
* C initial startup procedure under AmigaDOS
* 
* Use the following command line to make c.o
* asm -u -iINCLUDE: c.a

;;;
;;;   Stack map.
;;;
      OFFSET  0
           ds.b    4
savereg    ds.b    13*4
stackbtm   ds.b    4

	
*=======================================================================
*====== CLI Startup Code ===============================================
*=======================================================================
*
* Entry: D2 = command length
*	A2 = Command pointer
fromCLI:
        move.l  a7,D0           * get top of stack
        sub.l   stackbtm(a7),D0 * compute bottom
        add.l   #128,D0         * allow for parms overflow
        move.l  D0,_base(A4)    * save for stack checking

These are only a few lines to show the problematic instruction.

Later i get some Exceptions 8, 26 and 27. I think they are Priviledge-Violation, Int-2 and Int-3. Should i inspect my code for errors or is this normal behavior? I think this happens by printf (DOS-calls, eg. Write).

Thank you for your time...

[Toni Wilen]

Originally Posted by sigma63

Hello Toni,
now i'm playing with the 64bit Version under Win10.

If i load my program which has two hunks (code & data/bss) with uaedbg, it prints about a third hunk with size 4096 wich i think is for the stack, right? Could this size be configured?

It is stack and size is taken from program's original stack size. (If you run it from shell, use stack command. I really recommend using larger stack than 4k)

Now if i start with "g" i get an illegal-memory-access-error: obviously access to uninitialized stack area.
I think this is due to my use of the SAS/C-Compiler and the linkage with the normal startup-module c.o. This code tries to get the stack-base wich is a (possible undocumented?) parameter on the stack.

Attach small example executable, thanks.

Later i get some Exceptions 8, 26 and 27. I think they are Priviledge-Violation, Int-2 and Int-3. Should i inspect my code for errors or is this normal behavior? I think this happens by printf (DOS-calls, eg. Write).

This is just debugger reporting all exceptions/interrupts. (8 = rom uses this to enter supervisor mode). They can be ignored.

[sigma63]

Originally Posted by Toni Wilen

Attach small example executable, thanks.

OK, here we go.
In this archive is the classical "Hello World!" as EXE hello plus source in c and the SAS/C startup-Module c.o and source c.a for your reference.


Hope it helps

Edit: The Attachment has gone, don't know why. Maybe because of inclusion of the SAS/C Startup-Module so i made a new archive without them.

[Toni Wilen]

Which SAS-C version? Latest c.a is slightly different.

[sigma63]

Originally Posted by Toni Wilen

Which SAS-C version? Latest c.a is slightly different.

The compiler (lc1 + lc2) is v5.10b and the linker (slink) is v6.1.


I tried different versions of c.[a|o], one from v5.10 and a newer one, version unknown. Both result in the invalid-memory-access-error.

[Toni Wilen]

Fixed (uaedbg link in first post updated). I forgot that dos pushes size of stack (in bytes) to stack before jumping to executable's code.

[sigma63]

Originally Posted by Toni Wilen

Fixed (uaedbg link in first post updated).

Confirmed. Thank you very much.

[alpine9000]

I tried the latest version from page 1, and now this doesn't seem to work for me.

Running my app through it (after adding some padding at the end of the copper list), I now get a break reading from 0 from a location that doesn't seem to be in my app. If I "g" I get a few more reads/writes in the 0-100 range then the emulated system reboots.

The app works fine obviously without the debugger, and enforcer doesn't pick anything up.

Not sure if I am doing something wrong ? Latest winuae and uaedbg and running an A1200 config with 32bit addressing.

[Toni Wilen]

Only difference is extra long word in stack, it shouldn't have any effect unless you previously used every byte of the stack which is very unlikely

After initial break, add dummy breakpoint (f 0 for example), then g. When first invalid access comes, use H command to see history of executed commands. (up to last 500 instructions). It should help to find out what happened.

EDIT: stack frame commands may also help.

[alpine9000]

Originally Posted by Toni Wilen

Only difference is extra long word in stack, it shouldn't have any effect unless you previously used every byte of the stack which is very unlikely

After initial break, add dummy breakpoint (f 0 for example), then g. When first invalid access comes, use H command to see history of executed commands. (up to last 500 instructions). It should help to find out what happened.

EDIT: stack frame commands may also help.

There must be something wrong with my setup or something. I just seem to get invalid accesses in random locations and H doesn't really show anything useful, and a d at the break location shows garbage instructions (Doesn't seem to match up with my code at all).

In fact depending on the config I use (A3000/A4000/Ram config etc) the invalid access hits are totally different.

[Toni Wilen]

Originally Posted by alpine9000

There must be something wrong with my setup or something. I just seem to get invalid accesses in random locations and H doesn't really show anything useful, and a d at the break location shows garbage instructions (Doesn't seem to match up with my code at all).

In fact depending on the config I use (A3000/A4000/Ram config etc) the invalid access hits are totally different.

Try H 500, it should list some code. Check also execbase, really unexpected things happen if it gets modified accidentally. (But it should not be possible without debugger complaining

[alpine9000]

Originally Posted by Toni Wilen

Try H 500, it should list some code. Check also execbase, really unexpected things happen if it gets modified accidentally. (But it should not be possible without debugger complaining

FINAL EDIT: - figured out what was going on, see post below -

Without the debugger the app runs ok - constantly loading stuff from disk using the OS, uses the OS for interrupts and keyboard handling. Surely none of that would work if execbase was corrupt?

Edit: H 500 only shows two lines, even though there was quite a lot of code executed.

The current trigger is: "Instruction fetch from memory that was modified", but depending on the config I chose this can be something different.

Even if I do "u", it then seems to break on every instruction when I do "g"

EditEdit: So it seems when running in the debugger something goes through and trashes a bunch of code. It doesn't do this running out of the debugger.

[alpine9000]

OK - I figured out what was going on :-)

Basically my program uses PROGDIR: to locate it's assets on KS2.0 and greater, and this must not be set up when running via uaedbg, so due to my lack of error handling on loading data, I was passing garbage data to things like the music player, hence all the stuff reported above.

When I took out the PROGDIR: stuff, it then ran perfectly in the debugger.

Any chance uaedbg could set PROGDIR: somehow ?

[selco]

Hi,
I am experimenting with new debugger.

I have a programm cross-compiled with gcc under Linux, so all sources are in my linux-home. I used -g to have debug information.

The linux home is exported via samba and mounted as drive M: on the WinUAE-PC.


When I start uaedbg progname WinUAE tries to find the sources but failes with messages like this:


Couldn't open source file 'dictionary.cpp'
Couldn't open source file '/home/osboxes/program-sourc/src/dictionary.cpp'
Failed to load 'dictionary.cpp'


What is the preferred way to solve that problem? Can I somehow tell the debugger to add an "M:" to the front of the source-pathts? So that it can find not only my sources but also for instance the sources for libnix and other used libraries etc?




Another question:
when I enter TL I get


>TL
0 libraries matched with library symbols.
>


What am I missing here?


best regards

[Toni Wilen]

Originally Posted by selco

Couldn't open source file 'dictionary.cpp'
Couldn't open source file '/home/osboxes/program-sourc/src/dictionary.cpp'
Failed to load 'dictionary.cpp'

What is the preferred way to solve that problem? Can I somehow tell the debugger to add an "M:" to the front of the source-pathts? So that it can find not only my sources but also for instance the sources for libnix and other used libraries etc?

This is not yet supported (cygwin and WSL paths are automatically converted because they don't require extra information) but I guess simple config entry that adds path prefix should work.

>TL
0 libraries matched with library symbols.
>

What am I missing here?

amiga.lib. See first post for details.

[selco]

amiga.lib from 3.1-NDK is in plugins/debugger/ and seems to be loaded:


Automatically allocated debugmem location: 70000000 - 7fffffff 10000000
Unknown hunk 000003f0
Loaded 'AmigaGuideBase', 31 LVOs
Loaded 'AslBase', 6 LVOs
Loaded 'BattClockBase', 5 LVOs
Loaded 'BattMemBase', 4 LVOs
Loaded 'BulletBase', 6 LVOs
Loaded 'CardResource', 17 LVOs
Loaded 'ColorWheelBase', 2 LVOs
Loaded 'CxBase', 35 LVOs
Loaded 'ConsoleDevice', 6 LVOs
Loaded 'DataTypesBase', 19 LVOs
Loaded 'DiskfontBase', 5 LVOs
Loaded 'DiskBase', 6 LVOs
Loaded 'DOSBase', 159 LVOs
Loaded 'DTClassBase', 1 LVOs
Loaded 'SysBase', 133 LVOs
Loaded 'ExpansionBase', 23 LVOs
Loaded 'GadToolsBase', 25 LVOs
Loaded 'GfxBase', 172 LVOs
Loaded 'IconBase', 19 LVOs
Loaded 'IFFParseBase', 40 LVOs
Loaded 'InputBase', 1 LVOs
Loaded 'IntuitionBase', 128 LVOs
Loaded 'KeymapBase', 4 LVOs
Loaded 'LayersBase', 32 LVOs
Loaded 'LocaleBase', 32 LVOs
Loaded 'LowLevelBase', 23 LVOs
Loaded 'MathBase', 12 LVOs
Loaded 'MathIeeeDoubBasBase', 12 LVOs
Loaded 'MathIeeeDoubTransBase', 17 LVOs
Loaded 'MathIeeeSingBasBase', 12 LVOs
Loaded 'MathIeeeSingTransBase', 17 LVOs
Loaded 'MathTransBase', 17 LVOs
Loaded 'MiscBase', 2 LVOs
Loaded 'NVBase', 7 LVOs
Loaded 'PotgoBase', 3 LVOs
Loaded 'RamdriveDevice', 2 LVOs
Loaded 'RealTimeBase', 10 LVOs
Loaded 'RexxSysBase', 10 LVOs
Loaded 'TimerBase', 5 LVOs
Loaded 'TranslatorBase', 1 LVOs
Loaded 'UtilityBase', 38 LVOs
Loaded 'WorkbenchBase', 11 LVOs
Loading executable, exe=40207678
Hunk 0: 443 symbols loaded.
Hunk 1: 60 symbols loaded.
Hunk 2: 145 symbols loaded.
69342 stabs loaded.
26 stabs loaded.


Then the majority of the sources is searched and eventually loaded and it stops at the beginning but TL shows



Segment 1: 000003e9 70008000 - 700435f7 (243192)
Segment 2: 000003ea 7004b600 - 7004f683 (16516)
Segment 3: 000003eb 70057700 - 7007f763 (163940)
Segment 4: 0000ffff 70087800 - 700887ff (4096)
Executable load complete.
0 libraries matched with library symbols.
D0 00000015 D1 1006D0DB D2 00001000 D3 401F0B9C
D4 0000001C D5 1006CFBF D6 1007C44D D7 401B436C
A0 401F0BA3 A1 401BDCF8 A2 40012D84 A3 401B436C
A4 401BECF0 A5 00F9F5BE A6 00F9F5B2 A7 700887F8
USP 700887F8 ISP 400022A8 SFC 00000000 DFC 00000000
CACR 00000001 VBR 00000000 CAAR 00000000 MSP 00000000
T=00 S=0 M=0 X=1 N=0 Z=0 V=0 C=0 IMASK=0 STP=0
0: 7FFF-FFFFFFFF-FFFFFFFF +nan 7FFF-FFFFFFFF-FFFFFFFF +nan
2: 7FFF-FFFFFFFF-FFFFFFFF +nan 7FFF-FFFFFFFF-FFFFFFFF +nan
4: 7FFF-FFFFFFFF-FFFFFFFF +nan 7FFF-FFFFFFFF-FFFFFFFF +nan
6: 7FFF-FFFFFFFF-FFFFFFFF +nan 7FFF-FFFFFFFF-FFFFFFFF +nan
FPSR: 00000000 FPCR: 00000000 FPIAR: 00000000 N=0 Z=0 I=0 NAN=0
Segment 1: 000003e9 70008000-700435f7
__stext:
70008008 [000000] 23c8 7007 f70c MOVE.L A0,$7007f70c [00000000] ___commandline
Next PC: 7000800e
>TL
0 libraries matched with library symbols.
>



With tl I can step linewise. Thats fine. But I wonder why TL shows nothing.

[Toni Wilen]

Originally Posted by alpine9000

Basically my program uses PROGDIR: to locate it's assets on KS2.0 and greater, and this must not be set up when running via uaedbg, so due to my lack of error handling on loading data, I was passing garbage data to things like the music player, hence all the stuff reported above.

When I took out the PROGDIR: stuff, it then ran perfectly in the debugger.

Any chance uaedbg could set PROGDIR: somehow ?

It isn't working if uaedbg is in same directory as debugged program?

Originally Posted by selco

amiga.lib from 3.1-NDK is in plugins/debugger/ and seems to be loaded

It looks like you also copied all .fd files? Only include .fd files if they are not already included with amiga.lib. (3rd party libraries etc..)

winuae.7z updated.

debugging_options=pathprefix=X: (for example). Weird syntax used because it allows multiple options in same config entry in the future.

EDIT: 3.1 amiga.lib load error fixed. (I only tested it with 3.9 which does not have useless symbol hunks)

[selco]

>EDIT: 3.1 amiga.lib load error fixed. (I only tested it with 3.9 which does not have useless symbol hunks)



Confirmed, works now for me




>debugging_options=pathprefix=X: (for example). Weird syntax used because it allows multiple options in same config entry in the future.


Yes, works for my files. Thanks!
But...




Automatically allocated debugmem location: 70000000 - 7fffffff 10000000
Loaded 'amiga.lib', 42 libraries, 1113 LVOs.
Loading executable, exe=402079f8
Hunk 0: 443 symbols loaded.
Hunk 1: 60 symbols loaded.
Hunk 2: 145 symbols loaded.
69342 stabs loaded.
26 stabs loaded.

Couldn't open source file 'speak.cpp'
Couldn't open source file '/home/developer/espeak_src/espeak-source/src/speak.cpp'
Loaded source file 'M:/home/developer/espeak_src/espeak-source/src/speak.cpp', 28337 bytes, 1144 lines





The 3rd attempt loads all my source files by using the new prefix.



But that fails for lib-functions. I compiled them all with -g, of course.


Couldn't open source file '/home/developer/amiga-gcc_24Mai18/projects/libnix/sources/math/../nix/stdio/fprintf.c' # correct linux path
Couldn't open source file '/home/developer/espeak_src/espeak-source/src//home/developer/amiga-gcc_24Mai18/projects/libnix/sources/math/../nix/stdio/fprintf.c' # compile dir + correct source path
Couldn't open source file 'M:/home/developer/espeak_src/espeak-source/src//home/developer/amiga-gcc_24Mai18/projects/libnix/sources/math/../nix/stdio/fprintf.c' # M: + compile dir + correct source path

Failed to load '/home/developer/amiga-gcc_24Mai18/projects/libnix/sources/math/../nix/stdio/fprintf.c'




Here the 3rd. attempt adds M: to the path where my project was compiled compiled and then adds the original source path.
I could solve that with a link on the linux side but wouldn't it be cleaner to try the prefix MS wird all both previous variants instead of only the last one?


best regards

[Toni Wilen]

Originally Posted by alpine9000

But that fails for lib-functions. I compiled them all with -g, of course.

Strange to have path in file part (when there is separately stored path part) but I guess it is normal, stab format is already quite weird..

winuae.7z updated, added one more path variant test..

[alpine9000]

Originally Posted by Toni Wilen

It isn't working if uaedbg is in same directory as debugged program?

Yes, that does work! Not sure why I didn't think of trying that.

So the only "false" hit I still get is if I don't pad the end of my copper list after the final wait, other than that I can now run my game in full "release" config.