Hi Jeroen, On Sat, Nov 23, 2013 at 12:20:54PM +0100, Jeroen Hofstee wrote: > >Commit fe1378a - "ARM: use r9 for gd" - broke the ABI for users of the > >U-Boot API on ARM. Users I am aware of are GRUB and the FreeBSD loader. > >Since I only spotted this on Saturday, this code is well and truly in > >the wild, so any users of the API will need to preserve both r8 and r9 > >on syscalls for the foreseeable future (which is not the end of the > >world). > > After looking into it a bit better it seems the standalone applications > don't use the api, but poke into u-boot directly to look for a > separate jump-table in gd. I am still a bit surprised it works like that, > but at least the api doesn't. (I sent a patch to fix them) > > The api issue is therefore only related to requirement that r9 needs > to be preserved. The README states since the beginning of the git > repro (2002-11-03) [1] that r8 _and_ r9 have special meaning in U-boot.
[1] missing. Upon inspection: the top-level README also states that R10 can be used as the stack limit, which is not descibed by the AAPCS. Nor is the use of R11 as a frame pointer. > Albert removed the need for the GOT pointer (r9) over time by limiting > the supported relocation types, so the move from r8 to r9 was not > expected to cause an ABI problem, since both were special register > already. Anyway, I will have a look if it did break the ubldr. http://svnweb.freebsd.org/base?view=revision&revision=258527 > >Sometime last year I proposed a change to make the API syscall entry > >and exit points responsible for maintaining full procedure-call standard > >compliance, although the patch I provided was on the hackier side of > >good (and probably wrong). > > After the switch to r9 the call on ARM is eabi compliant, with r9 being a > platform register as allowed by the specs. EABI compliant for a specific platform that defines its use as such, yes. It's not a free-for-all: unless explicitly defined by the platform, r9 is 'variable register 6', a callee-saved register. (And here is where it all gets messy because U-Boot calls into the application, and then further down that call stack the application calls into U-Boot.) > Whether u-boot or the payload > is responsible for preserving r9 / in general should preserve and restore > its special registers in API calls is better answered by the maintainers. There is only one agent involved in this equation which can always know how U-Boot deviates from the base AAPCS, and that is U-Boot. The most helpful thing it can do is to hide these deviations, which may deviate in different ways from that of the default behaviour of the toolchain used to build it based on which operating system that is running under. / Leif _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
