Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 13:20

    tgiphil on v1.9.7.181-dev

    (compare)

  • 13:15

    tgiphil on master

    Change IntPtr to Mosa.Runtime.P… (compare)

  • 13:15
    tgiphil closed #705
  • 13:09
    tgiphil synchronize #705
  • 13:09

    tgiphil on 082-Ptr

    - Bug fix (compare)

  • Sep 22 14:56
    tgiphil synchronize #705
  • Sep 22 14:56

    tgiphil on 082-Ptr

    - Bug fix (compare)

  • Sep 22 14:48
    tgiphil synchronize #705
  • Sep 22 14:48

    tgiphil on 082-Ptr

    - Bug fix (compare)

  • Sep 21 15:47
    tgiphil synchronize #705
  • Sep 21 15:47

    tgiphil on 082-Ptr

    - WIP (compare)

  • Sep 21 06:00
    tgiphil synchronize #705
  • Sep 21 06:00

    tgiphil on 082-Ptr

    - WIP - WIP (compare)

  • Sep 19 18:33
    tgiphil closed #699
  • Sep 19 15:32

    tgiphil on v1.9.7.175-dev

    (compare)

  • Sep 19 15:28

    arakis on master

    fixed DWARF line numbers Merge pull request #706 from ar… (compare)

  • Sep 19 15:28
    arakis closed #706
  • Sep 19 15:27
    arakis opened #706
  • Sep 19 05:01
    tgiphil commented #705
  • Sep 19 04:59
    tgiphil synchronize #705
Phil Garcia
@tgiphil
I'm not seeing that.
btw. The opcode emitter for ADC with a constant is wrong. Just found it.
Sebastian Loncar
@arakis
BItConverter will "call" .As<TTo, TFrom>()", and that method is calling an exception
and its not plugged
Phil Garcia
@tgiphil
oh.
Sebastian Loncar
@arakis
you should add an unit test for that BitConverter.GetBytes method
Sebastian Loncar
@arakis
@tgiphil Just a note from my expirience: Never try to transfer a fiel over serial port - its endless slow on that large mosa bin files :-) With maximim baud rate of 115200 it takes 7 minutes, to transfer a 6 MB file from host to kernel.
I try to workarround now via direct access to raw disk file, a first test while the kernels is running and hacking contents via hex editor was successfull (the kernel was able to read the modified content).
maybe i should implement an NE2000 or rtl8139 driver. But not yet.
Phil Garcia
@tgiphil
Yep! I used a compressed to speed it up - but it still too slow.
The GDB protocol is faster - but haven’t attempt to use it for the unit tests yet.
Sebastian Loncar
@arakis
this is an interesting fact. But i'm using -s -gdb stio qemu default gdb stub, not an custom kernel stub. I'm wondering if this could work, too (and how)
Sebastian Loncar
@arakis
@tgiphil when i'm reading from disk, i get all the time an interrupt 46. I could ignore them (its just hint from my interrupt ISR, when there's an unhandled interrupt), but what is causing interrupt 46 and what should it handle? (46 = 0x2E)
Phil Garcia
@tgiphil
I don’t know.
Phil Garcia
@tgiphil
Btw. It’s possible to inject GDB commands using a proxy.
Sebastian Loncar
@arakis
how this is possible?
Phil Garcia
@tgiphil
Basically man-in-the-middle
FYI - big update coming tonight. You can pull from my repo to test.
Sebastian Loncar
@arakis
I'm loading the app into memory. On first instruction, it will ran into PageFault. But this makes no sense. There's Memory access, Pages are mapped. GDB can read the adress. Values of ESP/EBP make sense. And Segments are correct.
image.png
check_exception old: 0xffffffff new 0xe
  7483: v=0e e=0004 i=0 cpl=3 IP=001b:a010005d pc=a010005d SP=0023:41c24ff0 CR2=00000000
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=41c24ff0 ESP=41c24ff0
EIP=a010005d EFL=00003202 [-------] CPL=3 II=0 A20=1 SMM=0 HLT=0
ES =0023 00000000 ffffffff 00cff300 DPL=3 DS   [-WA]
CS =001b 00000000 ffffffff 00cffa00 DPL=3 CS32 [-R-]
E=0004 indicates, its a non mapped read access on CPL3. Yeah, the CR2 is zero. But what wants to access 0x0? Its a simple push ebp
Phil Garcia
@tgiphil
CR2 zero?
Sebastian Loncar
@arakis
= accessing 0x0
but why? the registers shows now attempt to access 0x0
push ebp = writing to stack
but ESP and EBP are valid values
(non zero)
mapped and readable (otherwise GDB would also throw a error)
Phil Garcia
@tgiphil
I do t think GDB would error.
But I don’t see a problem
Sebastian Loncar
@arakis
@tgiphil before you merge, you should fix failing appveyor unix test
Sebastian Loncar
@arakis
@tgiphil what is the preferred way to convert a byte* buffer into a System.String? Does new String(char*) work?
Phil Garcia
@tgiphil
One bug fixed in the optimizer. One more to go.
Yep. I believe so.
Btw. The appveyor error is related to drawf.
Can that be fixed?
Sebastian Loncar
@arakis
i know. But on windows, i do not see any overflow
It's becasue i enabled artimetic overflow checkbox
why does not error is thrown on windows, but on ubuntu?
Hm....maybe there have another magic line number like 0xFeeFee?
Phil Garcia
@tgiphil
The problem with overflow checking is sometimes it’s by design (including within the C# compiler)
Sebastian Loncar
@arakis
maybe the method should simply marked with the unchecked keyword
Phil Garcia
@tgiphil
I’d leave out the overflow check - we do a lot of bit fiddling where it’s expected. Our own handling of 64bit in 32bit platforms in the generated code expects proper overflow to work correctly.
Sebastian Loncar
@arakis
ok
Phil Garcia
@tgiphil
Big update pushed to main repo.
Not sure what’s going on with the Linux build.
Sebastian Loncar
@arakis
"System.OverflowException: Arithmetic operation resulted in an overflow."
I thought you unchecked the value in the csproj again?
Never never merge if appveyor is failing(!) Thats why we have integration tests
Sebastian Loncar
@arakis
@tgiphil importent qustion for my driver API: Are there any hardware devices, that place important information on stack/registers when their IRQ is fired? (like page fault: a lot of registers are required, but page fault is not a hardware device, of course ;-) )