Trying to improve x49gp

[3298]

(08-29-2018 02:17 AM)Claudio L. Wrote:  I was getting and error with the FORTIFY_SOURCE being redefined, so I removed from the Makefile, I don't know if it can affect other platforms (I only tested on Linux).

Well, that's a bummer. I added that because it somehow suppressed the stringop-truncation warning on my system (Manjaro 64-bit, fully updated). Maybe that definition caused my GCC to switch to another version of strncpy which isn't marked for that warning, but if adding it explicitly breaks on your setup, I need to find a better fix.
A closer look at the only instance of strncpy in the entire codebase reveals that the limit it's given is always shorter than the source string, so the destination string will never get a terminating null character. In other words, it's used as a memcpy and can be switched to actually use memcpy instead without side effects other than a bogus warning going away. Let's do it.

(08-29-2018 02:17 AM)Claudio L. Wrote:  I also tested it as a debugger, and it worked much better than previously. Now it's fast and responsive, I can inspect any kind of variables, etc.
The only issue is that stepping over one line sometimes jumps many lines, as in goes overboard. For example I single-stepped one line within a loop, and by the time it stopped it had finished the loop and advanced 5 or 6 lines past the end of the loop. But at least now there's no errors when setting and removing breakpoints, and it actually stops at breakpoints (seems trivial but not always worked before).

Ouch, that's not supposed to happen. I somehow doubt it's the interrupt fix skipping too far, because the fix works by preventing interrupts from starting in the first place (instead of letting them run and stopping afterwards), but the only other place for an actual bug I can think of is the gdb client, which is obviously not part of x49gp.
The knowledge about where code lines start and end is only on the client side, which automatically translates a line step into a stream of alternating instruction-step commands and register queries (to check the instruction pointer). If there are too many of these, x49gp's gdbstub cannot even tell there's something wrong
There is another possibility, which is the compiler's optimization making a mess of your to-be-debugged code. That's happened to me more than a few times, but I know of only two ways to deal with it: turn it off by compiling your program / firmware with -O0, or accept it and try to make sense of the machine code it spat out.

Anyway, I got your requested features (automatic firmware installation via GUI, forced automatic firmware installation via command-line option, forced reboot) done. It's split into three patches (firmware installation code with GUI-based selection; all command-line additions; manual update). The fourth one is the strncpy->memcpy workaround above.

My commit messages:

Code:

Improve initial flash creation
Instead of just loading the bootcode and letting it handle the rest (relying on the user to provide a firmware through the emulated SD card),
ask the user for the firmware and load that into the flash directly.
Also, the stock firmware needs some markers to be able to use the user flash banks.
It seems to be unable to add these if they are missing, so if a firmware that does not include blank user banks is selected,
the user banks would have been unusable.
Adding the marks in x49gp is therefore desirable, and custom firmware needs to be robust enough
to handle these anyway if it wants to survive in the wild.
If the flash file was present but too short, there is most likely nothing worth preserving in it,
so stop trying and fill the entire flash with 0xff instead of just the section after the present file's contents.
Lastly, fix a double free on a rare (fatal) error and a use-after-free on another which appear to have snuck into the flash creation code in an earlier commit.

Code:

Add command-line options to rebuild the flash or reboot
The firmware can be specified on the command line.
This might be useful for debugging custom firmware by making the debugging process more automatable.

Code:

Update the manual to reflect recent changes

Code:

Fix a warning about strncpy that caused compilation failures via -Werror
The previous workaround through -D_FORTIFY_SOURCE=1 caused redefinition errors on a user's system,
and it working at all was probably an oversight in the development system's compiler or standard library headers.
The code that actually caused it can be safely switched to memcpy in place of strncpy, which looks like a better fix.