Hi. I am interested in participating in Google Summer of Code - 2014 with
Linaro and working on two of the ideas from Ideas page [1]:
AArch64 porting of Free Software Packages - I am amazed going through the
details mentioned at [2] about the use of assembly in packages. I would
like to discover m
Michael Matz writes:
> Hi,
>
> On Tue, 25 Feb 2014, Peter Maydell wrote:
>
>> On 25 February 2014 13:33, Michael Matz wrote
>> > The biggest road-block is that signal vs syscall handling is
>> > fundamentally broken in linux-user and it's unfixable without
>> > assembler implementations of the
> Am 28.02.2014 um 22:21 schrieb Peter Maydell :
>
>> On 28 February 2014 14:12, Alex Bennée wrote:
>> Is this "simply" a case of having a precise state in/around syscalls?
>
> No.
>
>> AIUI we already have such a mechanism for dealing with faults in
>> translated code so this is all aimed at
On 28 February 2014 14:12, Alex Bennée wrote:
> Is this "simply" a case of having a precise state in/around syscalls?
No.
> AIUI we already have such a mechanism for dealing with faults in
> translated code so this is all aimed at when an asynchronous signal
> arrives somewhere in QEMU's own cod
On 28 February 2014 14:27, Alexander Graf wrote:
> Could we check the instruction at the sognaling pc and check
> if it's a known syscall instruction? No need to replace glibc
> wrappers then.
No, because the behaviour we want for "started handling
syscall in qemu" through to "PC anything up to b
Peter Maydell writes:
> On 28 February 2014 14:27, Alexander Graf wrote:
>> Could we check the instruction at the sognaling pc and check
>> if it's a known syscall instruction? No need to replace glibc
>> wrappers then.
>
> No, because the behaviour we want for "started handling
> syscall in qe
On 28 February 2014 17:08, Alex Bennée wrote:
>
> Peter Maydell writes:
>
>> On 28 February 2014 14:27, Alexander Graf wrote:
>>> Could we check the instruction at the sognaling pc and check
>>> if it's a known syscall instruction? No need to replace glibc
>>> wrappers then.
>>
>> No, because th
