Threaded Mode | Linear Mode

Claudio L. · 05-08-2018, 03:02 PM

(05-08-2018 11:19 AM)3298 Wrote: You squashed the patches into a single commit... that wasn't quite what I had in mind, but oh well. To be fair, my instructions weren't precise on that topic.

Well, it was my intent at first, but then I noticed the changes were numbered 1 to 24 and the patches 1 to 23. Then I wasn't sure which patch went with which description (offset-by-1) and decided to go for the single commit. In my defense... I did copy/paste your entire changelog descriptions on the commit, and gave you full credit for the changes.

(05-08-2018 11:19 AM)3298 Wrote: The "quasi-official" term was not meant to describe Egan's repository, but the one you subsequently turned yours into. I agree that drowning the official repository is less than ideal, but we don't have the power to tweak GitHub's user interface, so we can only hope that soon it floats to the top again by merging yours and putting some additional commit in.

Oh, I get it now. Mine is not official, the only reason I had to create it is to be able to do a pull request to Egan a few years ago. I don't like the fact that I have no way to tell people "stay away from my forks, it's not official, doesn't really track the latest changes, and most likely won't even compile".

(05-08-2018 11:19 AM)3298 Wrote: I haven't actually tried running NewRPL yet. Your simulator more or less fills the role of providing a platform for fresh NewRPL users to try it out, so getting x49gp to run it is not urgent.

True, not a major priority.

(05-08-2018 11:19 AM)3298 Wrote: On the other hand, I think x49gp could still be a decent development platform in the future (I'm hoping there will be some way to run native applications in NewRPL, roughly similar to HPGCC3?) thanks being an actual emulator, so improved compatibility would be awesome.

That idea is still in flux, I have yet to come up with a decent ABI so an independent program can call newRPL API. The exported jump table used in hpgcc3 is one way to do it, but a pain to maintain so I'm still looking for a better way.

(05-08-2018 11:19 AM)3298 Wrote: That's weird. It simply worked for me with no warnings. Are they new or did they occur in older versions too (i.e. before the -Werror from the official fork turned them into errors)?

I never paid much attention to warnings, but I think perhaps the vvfat feature wasn't enabled before?
I just rebuilt my old directory, and I see lots of warnings but that file isn't even mentioned, so it's not being built.

(05-08-2018 11:19 AM)3298 Wrote: If they are new, I'd guess they start to appear with the patch suppressing the debug log. And since I don't see them, which functions are they from? I will happily make fixes, but it's kind of hard to fix something one can't reproduce.

Should be easy to reproduce. The first one was line 2360, there's a call to ftruncate() which returns an integer number that's never used and that's generating an "unused result" warning:

Code:

block-vvfat.c: In function ‘commit_one_file’:

block-vvfat.c:2360:5: error: ignoring return value of ‘ftruncate’, declared with attribute warn_unused_result [-Werror=unused-result]

     ftruncate(fd, size);

In my view, there's nothing wrong with ignoring the result, so silencing the warning is fine.

(05-08-2018 11:19 AM)3298 Wrote: With GDB in a terminal, I've only been able to type commands when the debugged process is halted.

I think whenever you set the breakpoint and the code is running, it sends the 'pause' command over the line, sets the breakpoint, then resume execution.
When you manually press the 'pause' button it works well, you set the breakpoint, then resume manually. When the IDE does it, it fails somehow about 3 out of 4 times, a few times the breakpoint is set correctly. These issues happen with both Eclipse and Qt Creator, both using remote gdb backend. I think it's a timing issue, the IDE doesn't wait enough for the 'pause' to work before the next command is sent or something.

(05-08-2018 11:19 AM)3298 Wrote: I thought I fixed the step / continue from breakpoint issue. That added "continue;" line in timer.c in the "misc fixes" patch makes it skip the code responsible for raising timer interrupts between the call to the GDB stub and the call to QEMU; these timer interrupts were what prevented me from continuing from breakpoints (by stepping / continuing into a timer interrupt, going through that until it returns to user code at the location of the breakpoint, and then immediately raising a trap exception). If the timers are skipped, the single step / continue can move away from the breakpoint position before the check for trap exceptions kicks in.
With that fix in place, I was able to single-step and continue from active breakpoints in my HPGCC3 program just fine, so I'm curious why it's still broken for you.

Now that you mention, I tried it again and it works better than before, you can step as long as the line doesn't have a function call (which by chance is what I tried yesterday). Trying to step over a line with a function call stops at the IRQ handler with a timer interrupt.
That's a big improvement, still not quite there but a big usability improvement.