[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-mes] M2-Planet test23
From: |
Jeremiah |
Subject: |
Re: [bug-mes] M2-Planet test23 |
Date: |
Mon, 01 Apr 2019 00:24:19 +0000 |
> I took a look now in test/common_armv7l's M1 files. They seem to be quite
> nice!
Thank you, I spent a good deal of time with them.
> Should I look into other places as well?
cc_core.c is the only other place where there would be ARM assembly;
You will probably wish to compare against the knight-posix assembly as
it is easier to follow.
> (The ARM register corresponding to BP is officially named "FP", but
> it's fine either way)
I just named it BP as I was using it as a base pointer so that looking
at the assembly it would be obvious; support for the name FP would just
be a single DEFINE should you feel it is needed.
>> Also I could use your help on test23
> Sure. On the master branch or where?
Master branch; latest commit
All previous tests (test00-test22) run without issue on my test system
and you can verify that by running them directly
(./test/testnn/hello-armv7l.sh) with nn being the test number
> What's up with it?
It is displaying a highly unexpected error, specifically attempting to
branch to memory address 10 when returning from a called function; the
pop restoring the Link Register is what is setting the value and I have
yet to figure out why as the organization of the push and pops are a
match for the x86 (minus the extra steps required to simulate the x86
call by pushing and popping the Link Register onto the stack)
> Also, it seems that all ARM generated files have some problem in the
> ELF headers (maybe I'm using the wrong mescc-tools version? Or
> file(1) has a problem?):
Well the git commit of mescc-tools I am using is:
16d710fc113bca4b04de9ed957f5858d4a03d379
and I must admit; I haven't gone into depth with the ELF headers but
fortunately; it does appear the whole binary is being loaded into the
correct place in memory and :_start is being hit on the first
instruction executed. So there may be an issue in the ELF header we need
to fix but as test00-test22 all pass; it would be unlikely for that to
be the issue.
As for ./test/results/test24-armv7l-binary; I haven't tested it yet as I
am aiming for test23 to pass before I move onto the much more complex
test24.
But there is a possiblity test23 is just large enough (44KB) to reveal
an issue with the ELF header calculations being done for ARM in
mescc-tools. (Hence why I wanted to finish the M2-Planet port before the
mescc-tools release, to flush out the most important bugs)
Thank you for your time.
-Jeremiah