This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - antoniovazquezblanco
16
« on: June 26, 2014, 01:19:50 pm »
An important question is where to start. First GUI, then "kernel"?
I'd go for the first, as that could be tested with wine accurately.
Greetings help a lot  Well, have some:
Hi! Hi! Hi! Hi! Hello! Hello! Hello! Hello! Hello! Hello! Hey! Hey! Hey! 'sup? 'sup? 'sup? 'sup? 
How the hell could I have...  Greetings instead of congratulations...? As for what first I think I have seen some code in your repo wich involved using Qt. I have very little idea about that so if you were able to start thinking about how things could be implemented it could help me a lot. On the other hand there are some ugly things around there and I feel like the code should be a bit more organized so I think I will be spending some time with that. apb.c code for example, I don't know if it is usefull for anyone, data types are a mess, I would like to parse arguments from command line with optarg for simplicity (maybe a gui if no argument is provided...), etc. I've been filling some of this things in my repo issues list in order not to forguet them. https://github.com/antoniovazquezblanco/nspire_emu/issues?state=openPick one if you feel in the mood . Some "core" code has ben initially ported to linux (see os/os-linux.c) but a lot is missing.
17
« on: June 26, 2014, 01:00:59 pm »
It's pretty awesome to see someone porting Nspire-emu to Linux by the way. You're doing a great job.
Lets say "trying to" port... There's a long way ahead and any help would be apreciated. Really anything from suggestions, to actual code. Greetings help a lot
18
« on: June 26, 2014, 10:56:08 am »
For those who know the code of the project better than me, is apb.c code any useful? Can it be deleted? Old makefile didnt compile it and all the functions defined in there are duplicated. It is something someone is actually working on or it is something outdated?
I would also like to specify some kind of coding guidelines as sometimes things are very messy because of a non unified style. What do you think?
Thanks!
19
« on: June 25, 2014, 04:00:28 pm »
20
« on: June 25, 2014, 02:42:43 pm »
Compiled with __builtin_... + no -fno-omit-frame-pointer and it worked both in wine and windows 8.1  I will commit the mising line now. We should report the issue... Thanks!
21
« on: June 25, 2014, 02:17:42 pm »
Wow... debuging... kills me... Starting program: c:\Users\............................\nspire_emu\src/nspire_emu.exe -1=boot1cx.img -f=flash.bin
[New Thread 1600.0x710]
[New Thread 1600.0x884]
[New Thread 1600.0xa1c]
Hardware watchpoint 1: restart_after_exception[1]
Old value = 0
New value = 16
0x75e9e27e in setjmp3 () from C:\Windows\SysWOW64\msvcrt.dll
(gdb)
(gdb) c
Continuing.
...................................................................... (Tons of output...)
Program received signal SIGSEGV, Segmentation fault.
0x004018e5 in write_word ()
(gdb)
Continuing.
Program received signal SIGSEGV, Segmentation fault.
main (argc=0, argv=0x0) at emu.c:551
551 sched_process_pending_events();
(gdb)
Ummm.... 0x75e9e27e in setjmp3 () from C:\Windows\SysWOW64\msvcrt.dll? ? $ gdb nspire_emu.exe
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from c:\Users\....................\nspire_emu\src\nspire_emu.exe...done.
(gdb) b main:546
Breakpoint 1 at 0x41396c: file emu.c, line 260.
(gdb) b emu.c:546
Breakpoint 2 at 0x414140: file emu.c, line 546.
(gdb) watch restart_after_exception[1]
Hardware watchpoint 3: restart_after_exception[1]
(gdb) run -1=boot1cx.img -f=flash.bin
Starting program: c:\Users\..................\nspire_emu\src/ns
pire_emu.exe -1=boot1cx.img -f=flash.bin
[New Thread 2604.0x804]
Breakpoint 1, main (argc=3, argv=0xc429e0) at emu.c:260
warning: Source file is more recent than executable.
260 char *preload_filename[4] = { NULL };
(gdb) c
Continuing.
[New Thread 2604.0x3ac]
[New Thread 2604.0x94c]
Breakpoint 2, main (argc=3, argv=0xc429e0) at emu.c:546
546 sched_update_next_event(0);
(gdb) n
543 sched_items[SCHED_THROTTLE].clock = CLOCK_27M;
(gdb)
544 sched_items[SCHED_THROTTLE].proc = throttle_interval_event;
(gdb)
546 sched_update_next_event(0);
(gdb)
548 setjmp(restart_after_exception);
(gdb) si
0x00414168 548 setjmp(restart_after_exception);
(gdb)
0x0041416f 548 setjmp(restart_after_exception);
(gdb)
0x004138a8 in _setjmp3 ()
(gdb)
0x75e9e275 in setjmp3 () from C:\Windows\SysWOW64\msvcrt.dll
(gdb)
0x75e9e279 in setjmp3 () from C:\Windows\SysWOW64\msvcrt.dll
(gdb)
0x75e9e27b in setjmp3 () from C:\Windows\SysWOW64\msvcrt.dll
(gdb)
Hardware watchpoint 3: restart_after_exception[1]
Old value = 0
New value = 16
0x75e9e27e in setjmp3 () from C:\Windows\SysWOW64\msvcrt.dll
(gdb) disassemble setjmp3
Dump of assembler code for function setjmp3:
0x75e9e275 <+0>: mov 0x4(%esp),%edx
0x75e9e279 <+4>: mov %ebp,(%edx)
0x75e9e27b <+6>: mov %ebx,0x4(%edx)
=> 0x75e9e27e <+9>: mov %edi,0x8(%edx)
0x75e9e281 <+12>: mov %esi,0xc(%edx)
0x75e9e284 <+15>: mov %esp,0x10(%edx)
0x75e9e287 <+18>: mov (%esp),%eax
0x75e9e28a <+21>: mov %eax,0x14(%edx)
0x75e9e28d <+24>: movl $0x56433230,0x20(%edx)
0x75e9e294 <+31>: movl $0x0,0x24(%edx)
0x75e9e29b <+38>: mov %fs:0x0,%eax
0x75e9e2a1 <+44>: mov %eax,0x18(%edx)
0x75e9e2a4 <+47>: cmp $0xffffffff,%eax
0x75e9e2a7 <+50>: je 0x75ed992d <setjmp+56>
0x75e9e2ad <+56>: mov 0x8(%esp),%ecx
0x75e9e2b1 <+60>: or %ecx,%ecx
0x75e9e2b3 <+62>: jne 0x75ed9939 <setjmp+68>
0x75e9e2b9 <+68>: mov 0xc(%eax),%eax
0x75e9e2bc <+71>: mov %eax,0x1c(%edx)
0x75e9e2bf <+74>: sub %eax,%eax
0x75e9e2c1 <+76>: ret
0x75e9e2c2 <+77>: nop
0x75e9e2c3 <+78>: nop
0x75e9e2c4 <+79>: nop
0x75e9e2c5 <+80>: nop
0x75e9e2c6 <+81>: nop
End of assembler dump.
(gdb)
By the way, I've already merged your changes. Sorry about the scroll. I'm going to edit my post now... xD
22
« on: June 25, 2014, 05:30:35 am »
By the way. Given that we have two repos with similar content now, I think we should merge them into one and start working in one organization repo with some conventions like for example git-flow.
What do you think?
23
« on: June 24, 2014, 06:10:44 pm »
Some debug as requested Program received signal SIGSEGV, Segmentation fault.
0x004018e5 in write_word ()
(gdb) b data_abort
Breakpoint 1 at 0x40aa00: file emu.c, line 112.
(gdb) c
Continuing.
21:57:04.050,14-06-24,0000001605,refreshApList
←[0m21:57:04.160,14-06-24,0000001616,Doc open complete in 0.85000002 seconds for
: ndless/ndless_installer.tns
←[0m21:57:04.160,14-06-24,0000001616,Memory avail before open: 35822688. Memory
avail after open: 34665812. Memory used: 1156876
←[0mIME: non-ALPHA key pressed
Program received signal SIGSEGV, Segmentation fault.
0x004018e5 in write_word ()
(gdb) c
Continuing.
Breakpoint 1, data_abort (mva=16843021, status=1 '\001') at emu.c:112
warning: Source file is more recent than executable.
112 void data_abort(u32 mva, u8 status) {
(gdb) n
113 logprintf(LOG_CPU, "Data abort: address=%08x status=%02x\n", mva
, status);
(gdb) n
114 fix_pc_for_fault();
(gdb) n
118 cpu_exception(EX_DATA_ABORT);
(gdb) print restart_after_exception
$1 = {2686664, 16, 10767564, 13045723, 2686540, 4276596, 2686616, 0,
1447244336, 0, 0, 0, 0, 0, 0, 0}
(gdb) info registers
eax 0x4 4
ecx 0xc784e1e 209210910
edx 0x48dd8e4 76404964
ebx 0x1 1
esp 0x28fdec 0x28fdec
ebp 0x28fe04 0x28fe04
esi 0x101010d 16843021
edi 0xa44ccc 10767564
eip 0x40aa32 0x40aa32 <data_abort+50>
eflags 0x216 [ PF AF IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb) n
115 arm.reg[15] += 8;
(gdb) n
116 arm.fault_address = mva;
(gdb) n
117 arm.data_fault_status = status;
(gdb) n
118 cpu_exception(EX_DATA_ABORT);
(gdb) n
119 longjmp(restart_after_exception, 0);
(gdb) print restart_after_exception
$2 = {2686664, 16, 10767564, 13045723, 2686540, 4276596, 2686616, 0,
1447244336, 0, 0, 0, 0, 0, 0, 0}
(gdb) info registers
eax 0x102fd904 271571204
ecx 0x0 0
edx 0x20000013 536870931
ebx 0x1 1
esp 0x28fdec 0x28fdec
ebp 0x28fe04 0x28fe04
esi 0x101010d 16843021
edi 0xa44ccc 10767564
eip 0x40aa51 0x40aa51 <data_abort+81>
eflags 0x202 [ IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb) n
0x00401982 in longjmp ()
(gdb) print restart_after_exception
$3 = {2686664, 16, 10767564, 13045723, 2686540, 4276596, 2686616, 0,
1447244336, 0, 0, 0, 0, 0, 0, 0}
(gdb) info registers
eax 0x102fd904 271571204
ecx 0x40aa65 4237925
edx 0x20000013 536870931
ebx 0x1 1
esp 0x28fdec 0x28fdec
ebp 0x28fe04 0x28fe04
esi 0x101010d 16843021
edi 0xa44ccc 10767564
eip 0x401982 0x401982 <longjmp+1>
eflags 0x202 [ IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb) n
Single stepping until exit from function longjmp,
which has no line number information.
main (argc=0, argv=0x0) at emu.c:550
550 while (!exiting) {
(gdb) print restart_after_exception
$4 = {2686664, 16, 10767564, 13045723, 2686540, 4276596, 2686616, 0,
1447244336, 0, 0, 0, 0, 0, 0, 0}
(gdb) info registers
eax 0x0 0
ecx 0xa44040 10764352
edx 0x20000013 536870931
ebx 0x28fec8 2686664
esp 0x10 0x10
ebp 0xa44ccc 0xa44ccc <arm+204>
esi 0xc70fdb 13045723
edi 0x28fe4c 2686540
eip 0x414174 0x414174 <main+2068>
eflags 0x202 [ IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb) n
551 sched_process_pending_events();
(gdb) print restart_after_exception
$5 = {2686664, 16, 10767564, 13045723, 2686540, 4276596, 2686616, 0,
1447244336, 0, 0, 0, 0, 0, 0, 0}
(gdb) info registers
eax 0x0 0
ecx 0xa44040 10764352
edx 0x20000013 536870931
ebx 0x28fec8 2686664
esp 0x10 0x10
ebp 0xa44ccc 0xa44ccc <arm+204>
esi 0xc70fdb 13045723
edi 0x28fe4c 2686540
eip 0x414181 0x414181 <main+2081>
eflags 0x246 [ PF ZF IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
main (argc=0, argv=0x0) at emu.c:551
551 sched_process_pending_events();
(gdb)
It took me a while see it... I'm a noob with this code... Now what? Have you reported to mingw? Any hotfix? My version is the following in case it is useful: Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/4.9.0/lto-wrapper
Target: i686-w64-mingw32
Configured with: /build/mingw-w64-gcc/src/gcc-4.9.0/configure --prefix=/usr --libexecdir=/usr/lib --target=i686-w64-mingw32 --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada
--enable-shared --enable-static --enable-threads=posix --enable-fully-dynamic-string --enable-libstdcxx-time=yes --with-system-zlib --enable-cloog-backend=isl
--disable-cloog-version-check --disable-isl-version-check --enable-lto --disable-dw2-exceptions --enable-libgomp --disable-multilib --enable-checking=release
Thread model: posix
gcc version 4.9.0 (GCC)
24
« on: June 24, 2014, 12:15:06 pm »
On linux: - Your tns generates the same sigfault than the precompiled version. On windows: - Neither the original tns or your tns show that line of debug. - Both install correctly. And I don't really know how to use GDB, but if I read it correctly the call to sched_process_pending_events() segfaults once before crashing the second time?
It seems that it is true but the position of argv?? Argv is null?? I have to take a deeper look it must be in another point.
25
« on: June 24, 2014, 10:36:37 am »
Some things that I found:
- This does not only happen in v0.7+Ndless patches, this also happens in previous versions (v0.61).
- It only happens if it was compiled with mingw under linux.
- I get no line with data abort information.
26
« on: June 24, 2014, 09:36:10 am »
Here's what gdb says:
Program received signal SIGSEGV, Segmentation fault.
0x004018e5 in write_word ()
(gdb)
Continuing.
Program received signal SIGSEGV, Segmentation fault.
main (argc=0, argv=0x0) at emu.c:551
551 sched_process_pending_events();
(gdb) bt
#0 main (argc=0, argv=0x0) at emu.c:551
(gdb) s
Program received signal SIGSEGV, Segmentation fault.
main (argc=0, argv=0x0) at emu.c:551
551 sched_process_pending_events();
(gdb) bt
#0 main (argc=0, argv=0x0) at emu.c:551
(gdb) s
[Inferior 1 (process 1516) exited with code 030000000005]
27
« on: June 24, 2014, 09:09:26 am »
I've merged master changes so I'm now on version v0.7+Ndless patches and I could succesfully install ndless v3.6 in the emulator under windows.
I will have a look on the linux compiled version to help you with your bug.
Thanks
28
« on: June 24, 2014, 05:52:27 am »
Vogtinator, can you test the windows build trick?
cd src
OPTS=mingw make
I know this is not clean but I think it is better than the "prefix" solution there's in your makefile because prefix is tipically used for other things in a makefile.
Update: As I'm not able to get a clean diff (git and diff commands just diff the full code instead of the changed bits) of the changes between v0.61 and current version of the emulator, could anyone help me achieving this?
Update: It seems it is a file codification problem. Already working on it.
Thanks
29
« on: June 24, 2014, 04:23:30 am »
As it seems there's more people interested in a Qt gui I will think about it but a lot of work must be done before that.
When you talk about windows build in linux do you mean using mingw compiler in linux?
Thanks.
30
« on: June 23, 2014, 11:39:46 am »
Yes it is v0.61 because I mirrored the old repo. As for the new repo I don't really know how to get a diff or a patch between 0.61 and 0.7 because I have changed a lot of files (although very little changes) and if I diff with the mirror version I don't know why it diffs the whole file. I have to look at it again (probably today).
I wanted to start with GTK because I use cinnamon and qt apps don't look that well... I also thought of leaving the windows gui as is for the windows platform...
About the windows build in linux I don't know how to do it... You will have to point me again in the right direction.
Thank you very much.
|
Show Posts