Patches fail to init due to malplaced data at start of patch binary

#1

This thread: https://sebiik.github.io/community.axoloti.com.backup/t/maximum-patch-size/1483/12 started out as a question about the maximum size of a patch, but in the end I determined that there is bug in ramlink.ld, which puts a couple of arrays before the patch init function. The net result is that when the firmware calls PATCHMAINLOC to initialize the patch, the data in the arrays (pointers) are interpreted as code, which is then run before the actual init function, which can potentially wreck havoc with patch initialization.

Problems I've seen include:

  • Axoloti Core crashes and/or restarts
  • Patch performs init properly but refuses to run

The fix is simple, simply put the arrays in question after the text segment in the patch binary, so that PATCHMAINLOC is actually the start of the patch init function.

I've got a patch ready in my github repository (https://github.com/polluxsynth/axoloti/tree/fix-patch-init) which I've tested with complete success in my own setup. @johannes, let me know if you want me to rework it, or raise an issue in the Axoloti github repository, etc.

Maximum patch size?
#2

you can issue a pull request, which @johannes can then accept

as per other thread, it might be worth (as well as moving ctor/dtor, who's position is arbitrary) , adding a 

    PROVIDE(__code_start = .);

and then the patch start can be derived from that... rather than hardcode the start address.
(I think this will work, however, Ive not tried it)

#3

Yeah, I thought of just doing that, but then I read the patch submission guidelines and it mentioned bringing up the corresponding issue here and subsequently as an issue in the github patch tracking system, so I thought I'd go that way unless @johannes is fine with skipping some parts of the process in this case.

I've commented on the other stuff in the original thread.

#4

I wrote that :wink:
I suspect @johannes has already read this, so is aware of the issue,so a bit redundant.

but if you want to be fully correct, raise an issue on the github issue, and you can then just link to the post here. then raise a pull request, and cross reference the issues (you can check in with a fix/closes #issue number)

reality is, on one here raises github issues, so its never a complete list... and I don't have time, to raise an issue for every bug mentioned on here, then fix, then close it. so the github issues tends to be used for things we know about, but are not fixing now.

alternatively, I can always add the change to the PR, I already have open....

(I think @johannes is probably away/busy, as unusually, he has not merged my latest PR yet)

#5

Ah. :smile:

Ok, I submitted a pull request, which was apparently merged within five minutes, so either @johannes is back, or there is some form of automatic merge functionality (but then why would your PR not have been merged).

#6

Thanks for the detailed diagnosis and the pull request with a fix!
I was away, merging pull requests is done manually.

#7

Ok. Thanks @johannes!