05 May 2018, 15:23 | #61 |
Registered User
Join Date: Oct 2014
Location: Berlin
Posts: 131
|
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 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... |
05 May 2018, 15:43 | #62 | |||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,611
|
Quote:
Quote:
Quote:
|
|||
06 May 2018, 19:18 | #63 |
Registered User
Join Date: Oct 2014
Location: Berlin
Posts: 131
|
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. Last edited by sigma63; 08 May 2018 at 20:18. |
10 May 2018, 09:09 | #64 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,611
|
Which SAS-C version? Latest c.a is slightly different.
|
10 May 2018, 12:06 | #65 |
Registered User
Join Date: Oct 2014
Location: Berlin
Posts: 131
|
|
10 May 2018, 17:34 | #66 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,611
|
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.
|
10 May 2018, 18:45 | #67 |
Registered User
Join Date: Oct 2014
Location: Berlin
Posts: 131
|
|
13 May 2018, 07:18 | #68 |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 936
|
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. |
13 May 2018, 08:38 | #69 |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,611
|
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 08:44. |
13 May 2018, 14:10 | #70 | |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 936
|
Quote:
In fact depending on the config I use (A3000/A4000/Ram config etc) the invalid access hits are totally different. |
|
13 May 2018, 14:43 | #71 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,611
|
Quote:
|
|
13 May 2018, 21:12 | #72 | |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 936
|
Quote:
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 01:27. |
|
14 May 2018, 01:26 | #73 |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 936
|
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 ? |
27 May 2018, 17:15 | #74 |
Registered User
Join Date: Aug 2013
Location: Germany
Posts: 82
|
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 |
27 May 2018, 19:23 | #75 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,611
|
Quote:
Quote:
|
||
28 May 2018, 10:44 | #76 |
Registered User
Join Date: Aug 2013
Location: Germany
Posts: 82
|
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. |
28 May 2018, 18:32 | #77 | ||
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,611
|
Quote:
Quote:
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 20:02. |
||
29 May 2018, 14:29 | #78 |
Registered User
Join Date: Aug 2013
Location: Germany
Posts: 82
|
>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 |
29 May 2018, 15:45 | #79 | |
WinUAE developer
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 49
Posts: 26,611
|
Quote:
winuae.7z updated, added one more path variant test.. |
|
30 May 2018, 00:30 | #80 | |
Registered User
Join Date: Mar 2016
Location: Australia
Posts: 936
|
Quote:
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. |
|
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 22:27 |
Hacking the fs-uae console debugger | alpine9000 | Coders. Asm / Hardware | 1 | 28 March 2016 16:45 |
Added SegTracker to FS-UAE's Debugger | lallafa | support.FS-UAE | 7 | 16 January 2016 11:03 |
Amiga Segment!!! :) :) | blade002 | Amiga scene | 8 | 08 October 2015 15:00 |
SAS/C: Undefined symbols | Yesideez | Coders. C/C++ | 14 | 13 February 2014 16:36 |
|
|