Are these the same? Is TRAP 15 on the EASy68K the same as TRAP 14 on the 68000 board. Ive tried looking for this answer and am under the notion that it is right but i would like to make sure.
Could somone please confirm this?
What do you mean by "the same"?
The instruction is TRAP, it takes a 4-bit immediate vector index that controls which handler is invoked.
So of course the two instructions TRAP #14 and TRAP #15 are not the same.
The handlers can of course be the same, causing the two instructions to have the same result, but that's impossible to answer since you don't specify all your software.
Related
I'm running a Fortran 77 program written by someone else. I'm using the gfortran compiler (v5.4.0) on Linux (Ubuntu v.16.04). I'm not an experienced user of Fortran, gcc or bash scripting, so I'm struggling here.
When my program finishes running, I get the following message:
Note: The following floating-point exceptions are signalling: IEEE_DENORMAL
I had to look this up - I understand that some of my floating-point numbers need to be stored "denormal", a low-precision form for very small numbers (rather than flushing them to zero). These come from the unstable aerodynamic calculations in the program - I've seen this when doing the calculations longhand. It's unlikely that these denormal quantities are significantly affecting my results, but to try and find out where/why this was happening, I tried compiling with the following error options:
gfortran –g –fbacktrace –ffpe-trap=invalid,zero,overflow,underflow,denormal –O3 –mcmodel=medium –o ../program.exe
The program compiled, but at runtime it crashed and returned:
Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation.
Backtrace for this error:
#0 0x7F442F143E08
#1 0x7F442F142F90
#2 0x7F442EA8A4AF
#3 0x4428CF in subroutine2_ at code.f:3601 (discriminator 3)
#4 0x442C3F in subroutine1_ at code.f:3569
#5 0x4489DA in code_ at code.f:428
#6 0x42BdD1 in MAIN__ at main.f:235
Floating point exception (core dumped)
I can interpret these as a hierarchy of calls, working backwards from 6 to 3:
*6. At line 235 of "main.f", there was a problem. [this is a call to "code.f"]
*5. At line 428 of "code.f", there was a problem. [this is a call to "subroutine1" in "code.f"]
*4. At line 3569 of "code.f", in "subroutine1", there was a problem. [this is a call to "subroutine2" in "code.f"]
*3. At line 3601 of "code.f", in "subroutine2", there was a problem. [this is a conditional statement]
if (windspd_2m.ge.5.0) then...
So the DENORMAL error must be occurring in the "then" operations (I haven't included that code because (a) it involves a long, complicated series of dependencies, and (b) I can unravel the math errors, it's the debug errors I'm struggling with).
But for the above errors 2,1,0... I don't know how to interpret these strings of numbers/letters. I also don't know what "discriminator 3" means. I've googled these, but the only resources I've found explain them assuming a higher level of knowledge than I have. Can anyone help me to interpret these error codes, assuming very little pre-existing knowledge of Fortran, gcc, or bash scripting?
The first three stack frames are due to the implementation of backtracing in the GFortran runtime library (libgfortran). The backtrace can't resolve addresses in dynamic libraries symbolically, hence you get just the addresses. If you want to see symbolic output, you can add "-static" to your compile options.
Thus my first guess would be that the error is at code.f:3601, and since 5.0 is a constant it follows that windspd_2m ought to be denormal.
I am building a Commodore PET on an FPGA. I've implemented my own 6502 core in Kansas Lava (code is available at https://github.com/gergoerdi/mos6502-kansas-lava), and by putting enough IO around it (https://github.com/gergoerdi/eightbit-kansas-lava) I was able to boot the original Commodore PET ROM on it, get a blinking cursor and start typing.
However, after typing in the classic BASIC program
10 PRINT "HELLO WORLD"
20 GOTO 10
it crashes after a while (after several seconds) with
?ILLEGAL QUANTITY ERROR IN 10
Because my code has fairly reasonable per-opcode test coverage, and it passes AllSuiteA, I thought I would look into tests for more complicated behaviour, which is how I arrived at Klaus Dormann's interrupt testsuite. Running it in the Kansas Lava simulator has pointed out a ton of bugs in my original interrupt implementation:
The I flag was not set when entering the interrupt handler
The B flag was all over the place
IRQ interrupts were completely ignored unless I was unset when they arrived (the correct behaviour seems to be to queue interrupts when I is set and when it gets unset, they should still be handled)
After fixing these, I can now successfully run the Klaus Dormann test, so I was hoping by loading my machine back onto the real FPGA, with some luck the BASIC crash could be going away.
However, the new version, with all these interrupt bugs fixed, and passing the interrupt test in a simulator, now fails to respond to keyboard input or even just blink the cursor on the real FPGA. Note that both keyboard input and cursor blinking is done in response to an external IRQ (connected from the screen VBlank signal), so this means the fixed version somehow broke all interrupt handling...
I am looking for any kind of vague suggestions what could be going wrong or how I could begin to debug this.
The full code is available at https://github.com/gergoerdi/mos6502-kansas-lava/tree/interrupt-rewrite, the offending commit (the one that fixes the test and breaks the PET) is 7a09b794af. I realize this is the exact opposite of a minimal viable reproduction, but the change itself is tiny and because I have no idea where it goes wrong, and because reproducing the problem requires a machine featureful enough to boot the stock Commodore PET ROM, I don't know how I could shrink it...
Added:
I managed to reproduce the same issue on the same hardware with a very simple (dare I say minimal) ROM instead of the stock PET ROM:
.org $C000
reset:
;; Initialize PIA
LDY #$07
STY $E813
LDA #30
STA $42
STA $8000
CLI
JMP *
irq:
CMP $E812 ; ACK irq
DEC $42
BNE endirq
LDX $8000
INX
STX $8000
LDA #30
STA $42
endirq: RTI
.res $FFFC-*
.org $FFFC
resetv: .addr reset
irqv: .addr irq
Interrupts aren't queued; the interrupt line is sampled on the penultimate cycle of each instruction and if it is active then, and I unset, then a jump to interrupt occurs next instead of a fetch/decode. Could the confusion be that IRQ is level triggered, not edge triggered, and is usually held high for a period, not a single cycle? So clearing I will cause an interrupt to occur immediately if it was already ongoing. It looks like on the PET interrupt is held active until the CPU acknowledges it?
Also notice the semantics: SEI and CLI adjust the flag in the final cycle. A decision on whether to jump to interrupt was made the cycle before. So a SEI as the final thing when an interrupt comes in, you'll enter the interrupt routine with I set. If an interrupt is active when you hit a CLI then the processor will perform the operation after the CLI before branching.
I'm on a phone so it's difficult to assess more thoroughly than to offer those platitudes; I'll try to review properly later. Is any of that helpful?
I'm trying to run bzip and have it return control to the calling function from inside a nasm-coded assembly program (under linux). I apparently need to use a combination of the sys_fork and sys_execve system calls to achive this. After much searching, I found an example of how to use sys_execve, however I can't find an example of how to use sys_fork. Any help with my request will be appreciated.
My experience is limited, but as I recall sys_fork is easy. "Just do it" - no parameters. At this point, you're "in two places at once". If eax is zero, you're the child - do sys_execve on bzip. If eax is non-zero (and non-negative!), you're the parent and eax is your PID. Do a sys_waitpid on that PID. As I recall, this returns the exit status of bzip shifted left 8 bytes - sys_execve itself never returns.
I have a crude example that runs an editor, nasm, and ld (all on a hard-coded "hello.asm"). Longish to post, but I can make it available some way if you need it. I found getting the correct parameters to sys_execve the hardest part, as I recall.
Linux Assembly Tutorial states:
there is one very important thing to remember: If you are planning to return from a procedure (with the RET instruction), don't jump to it! As in "never!" Doing that will cause a segmentation fault on Linux (which is OK – all your program does is terminate), but in DOS it may blow up in your face with various degrees of terribleness.
But I cannot understand why does it causes a segmentation fault. it sounds just like returning from a function.
I have a situation where I need to implement the logic "If X happens, call procedure A. Otherwise, call procedure B." Is there any other way than jumping around like a kangaroo weaving spaghetti code?
Because CALL pushes the current instruction address onto the stack, and RET pulls it off in order to get back to the call-site. JMP (and related instructions) don't push anything onto the stack.
I think that this advice may have to do with the pipeline, but I'm not sure.
I believe that the question you are asking is:
... subroutine entrypoint ...
... various instructions in a routine ...
jmp label
... move instructions in a routine...
label:
ret
What's the problem, if any, with this? First, I'm not sure that this is a problem at all. But if it is, it's the pipeline. On some processors, one or more instructions after the jmp will be executed before control moves to the label.
Mostly, I fear that you've misunderstood what you've read, or I've misunderstood what you've written. jmp-ing from one point in your subroutine to the ret instruction should be fine. jmp-ing instead of executing ret is, as other people pointed out, is a dumb idea.
Back story: While running a program under strace I notice that '/dev/urandom' is being open'ed. I would like to know where this call is coming from (it is not part of the program itself, it is part of the system).
So, using gdb, I am trying to break (using catch syscall open) program execution when the open call is issued, so I can see a backtrace. The problem is that open is being called alot, like several hundred times so I can't narrow down the specific call that is opening /dev/urandom. How should I go about narrowing down the specific call? Is there a way to filter by arguments, and if so how do I do it for a syscall?
Any advice would be helpful -- maybe I am going about this all wrong.
GDB is a pretty powerful tool, but has a bit of a learning curve.
Basically, you want to set up a conditional breakpoint.
First use the -i flag to strace or objdump -d to find the address of the open function or more realistically something in the chain of getting there, such as in the plt.
set a breakpoint at that address (if you have debug symbols, you can use those instead, omitting the *, but I'm assuming you don't - though you may well have them for library functions if nothing else.
break * 0x080482c8
Next you need to make it conditional
(Ideally you could compare a string argument to a desired string. I wasn't getting this to work within the first few minutes of trying)
Let's hope we can assume the string is a constant somewhere in the program or one of the libraries it loads. You could look in /proc/pid/maps to get an idea of what is loaded and where, then use grep to verify the string is actually in a file, objdump -s to find it's address, and gdb to verify that you've actually found it in memory by combining the high part of the address from maps with the low part from the file. (EDIT: it's probably easier to use ldd on the executable than look in /proc/pid/maps)
Next you will need to know something about the abi of the platform you are working on, specifically how arguments are passed. I've been working on arm's lately, and that's very nice as the first few arguments just go in registers r0, r1, r2... etc. x86 is a bit less convenient - it seems they go on the stack, ie, *($esp+4), *($esp+8), *($esp+12).
So let's assume we are on an x86, and we want to check that the first argument in esp+4 equals the address we found for the constant we are trying to catch it passing. Only, esp+4 is a pointer to a char pointer. So we need to dereference it for comparison.
cond 1 *(char **)($esp+4)==0x8048514
Then you can type run and hope for the best
If you catch your breakpoint condition, and looking around with info registers and the x command to examine memory seems right, then you can use the return command to percolate back up the call stack until you find something you recognize.
(Adapted from a question edit)
Following Chris's answer, here is the process that eventually got me what I was looking for:
(I am trying to find what functions are calling the open syscall on "/dev/urandom")
use ldd on executable to find loaded libraries
grep through each lib (shell command) looking for 'urandom'
open library file in hex editor and find address of string
find out how parameters are passed in syscalls (for open, file is first parameter. on x86_64 it is passed in rdi -- your mileage may vary
now we can set the conditional breakpoint: break open if $rdi == _addr_
run program and wait for break to hit
run bt to see backtrace
After all this I find that glib's g_random_int() and g_rand_new() use urandom. Gtk+ and ORBit were calling these functions -- if anybody was curious.
Like Andre Puel said:
break open if strcmp($rdi,"/dev/urandom") == 0
Might do the job.