English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 05 May 2018, 16:23   #61
sigma63
Registered User

 
Join Date: Oct 2014
Location: Berlin
Posts: 128
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.

Code:
*
* 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...
sigma63 is offline  
Old 05 May 2018, 16:43   #62
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
Quote:
Originally Posted by sigma63 View Post
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)

Quote:
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.


Quote:
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.
Toni Wilen is online now  
Old 06 May 2018, 20:18   #63
sigma63
Registered User

 
Join Date: Oct 2014
Location: Berlin
Posts: 128
Quote:
Originally Posted by Toni Wilen View Post
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.
Attached Files
File Type: zip helloworld.zip (4.0 KB, 69 views)

Last edited by sigma63; 08 May 2018 at 21:18.
sigma63 is offline  
Old 10 May 2018, 10:09   #64
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
Which SAS-C version? Latest c.a is slightly different.
Toni Wilen is online now  
Old 10 May 2018, 13:06   #65
sigma63
Registered User

 
Join Date: Oct 2014
Location: Berlin
Posts: 128
Quote:
Originally Posted by Toni Wilen View Post
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.
sigma63 is offline  
Old 10 May 2018, 18:34   #66
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
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.
Toni Wilen is online now  
Old 10 May 2018, 19:45   #67
sigma63
Registered User

 
Join Date: Oct 2014
Location: Berlin
Posts: 128
Quote:
Originally Posted by Toni Wilen View Post
Fixed (uaedbg link in first post updated).
Confirmed. Thank you very much.
sigma63 is offline  
Old 13 May 2018, 08:18   #68
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 612
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.
alpine9000 is offline  
Old 13 May 2018, 09:38   #69
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
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.

Last edited by Toni Wilen; 13 May 2018 at 09:44.
Toni Wilen is online now  
Old 13 May 2018, 15:10   #70
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 612
Quote:
Originally Posted by Toni Wilen View Post
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.
alpine9000 is offline  
Old 13 May 2018, 15:43   #71
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
Quote:
Originally Posted by alpine9000 View Post
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
Toni Wilen is online now  
Old 13 May 2018, 22:12   #72
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 612
Quote:
Originally Posted by Toni Wilen View Post
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.

Last edited by alpine9000; 14 May 2018 at 02:27.
alpine9000 is offline  
Old 14 May 2018, 02:26   #73
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 612
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 ?
alpine9000 is offline  
Old 27 May 2018, 18:15   #74
selco
Registered User
 
Join Date: Aug 2013
Location: Germany
Posts: 56
Source-path of a cross-compiled program?

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
selco is offline  
Old 27 May 2018, 20:23   #75
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
Quote:
Originally Posted by selco View Post
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.

Quote:
>TL
0 libraries matched with library symbols.
>

What am I missing here?
amiga.lib. See first post for details.
Toni Wilen is online now  
Old 28 May 2018, 11:44   #76
selco
Registered User
 
Join Date: Aug 2013
Location: Germany
Posts: 56
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.
selco is offline  
Old 28 May 2018, 19:32   #77
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
Quote:
Originally Posted by alpine9000 View Post
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?

Quote:
Originally Posted by selco View Post
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)

Last edited by Toni Wilen; 28 May 2018 at 21:02.
Toni Wilen is online now  
Old 29 May 2018, 15:29   #78
selco
Registered User
 
Join Date: Aug 2013
Location: Germany
Posts: 56
>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
selco is offline  
Old 29 May 2018, 16:45   #79
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,022
Quote:
Originally Posted by alpine9000 View Post
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..
Toni Wilen is online now  
Old 30 May 2018, 01:30   #80
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 612
Quote:
Originally Posted by Toni Wilen View Post
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.
alpine9000 is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Debugger updates (was: WinUAE Debugger HH PC history) selco support.WinUAE 8 14 March 2018 23:27
Hacking the fs-uae console debugger alpine9000 Coders. Asm / Hardware 1 28 March 2016 17:45
Added SegTracker to FS-UAE's Debugger lallafa support.FS-UAE 7 16 January 2016 12:03
Amiga Segment!!! :) :) blade002 Amiga scene 8 08 October 2015 16:00
SAS/C: Undefined symbols Yesideez Coders. C/C++ 14 13 February 2014 17:36

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 14:31.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.09418 seconds with 14 queries