bug-mes
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-mes] mescc arm progress


From: Jan Nieuwenhuizen
Subject: Re: [bug-mes] mescc arm progress
Date: Mon, 08 Apr 2019 20:19:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)

Danny Milosavljevic writes:

Hi Danny,

>>I found that something
>> weird happens an EOF on arm, not exactly sure what's going on there but
>> I found a workaround for now.
>
> Hmm, EOF is famously (int) -1 and char is unsigned on ARM (if not
> changed by compiler flag).  Might have something to do with it.

Ah...I'll have a look with that in mind.

> Also not sure whether we are officially allowed to unread
> EOF--although the ungetter is our implementation, right?  That one
> seems to allow it.

Yes, I think you're right on both points.  Also `it works' on x86 and
x86_64, so...

> Nice short failure list!  (some of them ridiculous ones that I
> apparently broke again--oops).

Hehe...there are more failures, I just listed the most interesting bit.
Although, fixing these will probably fix many others too.

> I've taken a look at your commits and saw:
>
>>+#if 0 ///Error: thumb conditional instruction should be in IT block -- 
>>`moveq r1,#1'
>
> Hmm, that means that thumb mode is enabled which means it will use a
> different frame pointer (r7).  That's very bad because that frame
> pointer is not set up by our runtime.  (it might be also why you had
> to comment out r7 from the syscall clobber list.  Though I think the
> clobber list is much too paranoid anyway--but better than debugging
> forever :) )

Ah, thumb mode...forgot about that.

> Do you pass "-marm" to eventual gcc invocations (if any) and to the
> assembler?  That should disable Thumb mode.

Yeah, that's probably what was going on.  I verified that I'm using
-marm now, and reverted the r7 removals and put movq back.  Hard reset
the wip+wip-arm branch.  Thanks!

> As for syscalls, for some reason, the following construct doesn't do what I 
> think it should do in gcc:
>
> unsigned int foo(a,b,c)
>   unsigned int a asm("r7");
>   unsigned int b asm("r0");
>   unsigned int c asm("r1");
> {
>         asm("swi $0");
> }
>
> int main() {
>         foo(1,2,3);
> }
>
> That's too bad.

Hmm, yes that's a problem.

janneke

-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | AvatarĀ® http://AvatarAcademy.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]