Post Reply 
Trying to improve x49gp
05-08-2018, 06:17 PM
Post: #25
RE: Trying to improve x49gp
(05-08-2018 03:02 PM)Claudio L. Wrote:  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.
The instructions are actually numbered up to 25. Tongue The difference between patches and instructions comes from the first two instructions (clone repositories, grab patches) which don't have associated patches. Oh, and just nitpicking: after doing the merges there are only 21 patches left, not 23 like your commit message states. Wink
What worries me most about the squashing is that it makes it harder for others to understand and follow the sequence, especially with you apparently forgetting the link back here.
(05-08-2018 03:02 PM)Claudio L. Wrote:  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.
Let's not get too off-topic here, but I'll say this: take your time. On a scale from "we need it YESTERDAY" to "who cares?", it's definitely closer to the latter, as the primary usecases would be hardware access (for whatever reason) and high-performance applications. Both of these are niche cases, especially while NewRPL itself is still somewhat experimental. It's just something that would be nice to have ... eventually.
(05-08-2018 03:02 PM)Claudio L. Wrote:  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.
I'm pretty sure it has always been there and enabled.
(05-08-2018 03:02 PM)Claudio L. Wrote:  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.
Ah-ha, system headers with function declarations explicitly tagged to warn about unused results (using attributes). My system headers apparently don't do that sort of thing. I'll look into how I get them to behave that way.
For ftruncate in particular, there is a QEMU commit less than two weeks after the version we have in x49gp fixing it (it explicitly says so). Maybe we could do a slight QEMU upgrade until we run into a roadblock. We probably wouldn't get very far (as I mentioned, I've been banging my head against current QEMU for a while), but a few fixes like that one wouldn't hurt.
(05-08-2018 03:02 PM)Claudio L. Wrote:  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.
Hmm, you might be on to something there. I thought the commands would simply be queued (e.g. in the TCP socket), but that is a lead at least. On the other hand, how does it miss the breakpoint command without missing the continue command as well?
(after a cursory source check) The breakpoint command sends a response back (failure/success). GDB probably delays sending the continue command until after that's done, and then the timing may be generous enough to always let the stub catch the continue command. But the break command also prompts a response, and I couldn't find obvious holes in the buffering scheme...
(05-08-2018 03:02 PM)Claudio L. Wrote:  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.
Another thing for me to check out. I thought I'd stepped into and over functions with this fix, but maybe not. I was very annoyed at the constant need to disable the breakpoint, continue, and enable the breakpoint again, and a paragraph here is not enough to tell you how happy finding that cause made me. The fix looks so simple, but it was the single biggest issue I had with the GDB interface, and finding the fix took some effort and a awkward feeling from running two different debuggers (arm-none-eabi and regular x86) at the same time for a single task. Now I can simply tap Enter to go through one iteration of a loop (with the breakpoint somewhere in the loop and a continue as the last GDB command) where I had to type six commands before: disable the breakpoint, continue, then enable it again, and that times two because I need at least one enabled breakpoint in the loop whenever it's running - to keep it from running for more than one iteration. And don't get me started on single-stepping, it always stepped into a timer interrupt for obvious reasons.

Okay, looks like I have some investigating and coding to do. Results will be posted here, of course.
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
Trying to improve x49gp - 3298 - 10-28-2014, 10:08 PM
RE: Trying to improve x49gp - Han - 10-28-2014, 10:53 PM
RE: Trying to improve x49gp - Egan Ford - 10-29-2014, 02:54 AM
RE: Trying to improve x49gp - Egan Ford - 10-29-2014, 02:57 AM
RE: Trying to improve x49gp - Egan Ford - 10-29-2014, 03:10 AM
RE: Trying to improve x49gp - 3298 - 10-29-2014, 08:43 AM
RE: Trying to improve x49gp - Egan Ford - 10-31-2014, 12:36 AM
RE: Trying to improve x49gp - debrouxl - 10-29-2014, 09:18 AM
RE: Trying to improve x49gp - Claudio L. - 10-29-2014, 11:58 AM
RE: Trying to improve x49gp - Claudio L. - 10-29-2014, 12:04 PM
RE: Trying to improve x49gp - 3298 - 11-04-2014, 09:50 PM
RE: Trying to improve x49gp - Egan Ford - 11-08-2014, 09:50 PM
RE: Trying to improve x49gp - 3298 - 05-05-2018, 10:43 PM
RE: Trying to improve x49gp - 3298 - 05-05-2018, 10:45 PM
RE: Trying to improve x49gp - Claudio L. - 05-07-2018, 06:33 PM
RE: Trying to improve x49gp - 3298 - 05-07-2018, 08:55 PM
RE: Trying to improve x49gp - Claudio L. - 05-07-2018, 11:09 PM
RE: Trying to improve x49gp - dmmaster - 05-07-2018, 07:17 PM
RE: Trying to improve x49gp - 3298 - 05-07-2018, 08:12 PM
RE: Trying to improve x49gp - dmmaster - 05-07-2018, 08:36 PM
RE: Trying to improve x49gp - Claudio L. - 05-08-2018, 02:57 AM
RE: Trying to improve x49gp - 3298 - 05-08-2018, 11:19 AM
RE: Trying to improve x49gp - Claudio L. - 05-08-2018, 03:02 PM
RE: Trying to improve x49gp - 3298 - 05-08-2018 06:17 PM
RE: Trying to improve x49gp - 3298 - 05-13-2018, 10:27 PM
RE: Trying to improve x49gp - Claudio L. - 05-14-2018, 01:24 AM
RE: Trying to improve x49gp - 3298 - 05-15-2018, 10:22 AM
RE: Trying to improve x49gp - 3298 - 08-23-2018, 05:44 PM
RE: Trying to improve x49gp - ijabbott - 08-23-2018, 07:15 PM
RE: Trying to improve x49gp - Claudio L. - 08-24-2018, 02:36 AM
RE: Trying to improve x49gp - 3298 - 08-26-2018, 02:22 PM
RE: Trying to improve x49gp - pier4r - 08-26-2018, 06:31 PM
RE: Trying to improve x49gp - Claudio L. - 08-27-2018, 01:39 PM
RE: Trying to improve x49gp - 3298 - 08-27-2018, 08:20 PM
RE: Trying to improve x49gp - Claudio L. - 08-27-2018, 09:07 PM
RE: Trying to improve x49gp - 3298 - 08-27-2018, 10:39 PM
RE: Trying to improve x49gp - Claudio L. - 08-28-2018, 02:51 AM
RE: Trying to improve x49gp - 3298 - 08-28-2018, 08:04 AM
RE: Trying to improve x49gp - Claudio L. - 08-29-2018, 02:17 AM
RE: Trying to improve x49gp - 3298 - 08-29-2018, 11:12 AM
RE: Trying to improve x49gp - Claudio L. - 08-29-2018, 10:02 PM
RE: Trying to improve x49gp - 3298 - 08-29-2018, 10:21 PM
RE: Trying to improve x49gp - brickviking - 08-29-2018, 10:46 PM
RE: Trying to improve x49gp - 3298 - 08-29-2018, 11:53 PM
RE: Trying to improve x49gp - Claudio L. - 08-30-2018, 09:35 PM
RE: Trying to improve x49gp - Claudio L. - 08-29-2018, 10:09 PM
RE: Trying to improve x49gp - brickviking - 08-31-2018, 12:10 AM
RE: Trying to improve x49gp - Claudio L. - 08-31-2018, 12:47 AM
RE: Trying to improve x49gp - 3298 - 08-31-2018, 08:15 AM
RE: Trying to improve x49gp - Claudio L. - 08-31-2018, 06:11 PM
RE: Trying to improve x49gp - pier4r - 08-31-2018, 07:43 PM
RE: Trying to improve x49gp - brickviking - 08-31-2018, 10:52 PM
RE: Trying to improve x49gp - Sylvain Cote - 08-31-2018, 11:12 PM
RE: Trying to improve x49gp - Claudio L. - 08-31-2018, 11:45 PM
RE: Trying to improve x49gp - Claudio L. - 10-04-2018, 09:21 PM
RE: Trying to improve x49gp - brickviking - 10-05-2018, 08:55 AM
RE: Trying to improve x49gp - 3298 - 10-05-2018, 11:26 AM
RE: Trying to improve x49gp - 3298 - 10-09-2018, 03:13 PM
RE: Trying to improve x49gp - Claudio L. - 10-10-2018, 02:25 PM
RE: Trying to improve x49gp - 3298 - 10-10-2018, 09:50 PM
RE: Trying to improve x49gp - Claudio L. - 10-11-2018, 02:43 AM
RE: Trying to improve x49gp - Claudio L. - 10-05-2018, 06:33 PM
RE: Trying to improve x49gp - brickviking - 10-05-2018, 09:43 PM
RE: Trying to improve x49gp - brickviking - 10-10-2018, 09:21 PM



User(s) browsing this thread: 1 Guest(s)