On 20.12.2011, at 17:33, Peter Maydell wrote:
> On 20 December 2011 16:29, Alexander Graf wrote:
>> On 20.12.2011, at 17:17, Peter Maydell wrote:
>>> On 14 December 2011 01:43, Alexander Graf wrote:
+unsigned long reserved_va = 0xf700;
>>>
>>> So why 0xf700 rather than the whole o
On 20 December 2011 16:29, Alexander Graf wrote:
> On 20.12.2011, at 17:17, Peter Maydell wrote:
>> On 14 December 2011 01:43, Alexander Graf wrote:
>>> +unsigned long reserved_va = 0xf700;
>>
>> So why 0xf700 rather than the whole of the 32 bit space?
>>
>> (In particular for ARM targets
On 20.12.2011, at 17:17, Peter Maydell wrote:
> On 14 December 2011 01:43, Alexander Graf wrote:
>> +unsigned long reserved_va = 0xf700;
>
> So why 0xf700 rather than the whole of the 32 bit space?
>
> (In particular for ARM targets we want to be able to mmap
> at 0x...)
Becau
On 14 December 2011 01:43, Alexander Graf wrote:
> +unsigned long reserved_va = 0xf700;
So why 0xf700 rather than the whole of the 32 bit space?
(In particular for ARM targets we want to be able to mmap
at 0x...)
-- PMM
> >> The proper solution would be to rewrite mmap.c to be smarter (perhaps
> >> by looking at /proc/self/maps and reserving a lot of space with
> >> PROT_NONE mappings at startup and then managing it itself), but so far
> >> nobody's done that
> >
> > Yes they have. That's what -R does.
>
> -R do
On 14 December 2011 12:04, Paul Brook wrote:
>> The proper solution would be to rewrite mmap.c to be smarter (perhaps
>> by looking at /proc/self/maps and reserving a lot of space with PROT_NONE
>> mappings at startup and then managing it itself), but so far nobody's
>> done that
>
> Yes they have
> The proper solution would be to rewrite mmap.c to be smarter (perhaps
> by looking at /proc/self/maps and reserving a lot of space with PROT_NONE
> mappings at startup and then managing it itself), but so far nobody's
> done that
Yes they have. That's what -R does.
We used to try and parse /pro
On 14 December 2011 00:30, Paul Brook wrote:
>> IIRC mmap'ing files would break with 32-on-64, but I'd have to check up on
>> the details. I ended up passing MAP_32BIT to all linux-user mmap calla for
>> 32-on-x86_64, but that doesn't work with -R.
>
> Hmm, I thought we'd fixed that. It's the rea
> >> IIRC mmap'ing files would break with 32-on-64, but I'd have to check up
> >> on the details. I ended up passing MAP_32BIT to all linux-user mmap
> >> calla for 32-on-x86_64, but that doesn't work with -R.
> >
> > Hmm, I thought we'd fixed that. It's the reason h2g_valid exists.
> >
> > Eith
On 14.12.2011, at 01:30, Paul Brook wrote:
>>> When compiling qemu statically with multilib on PPC, we hit the
>>> same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
>>> is fixing. Do the same here.
>>
>> How many of these ld files can we get rid of if we use -Tt
> > When compiling qemu statically with multilib on PPC, we hit the
> > same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
> > is fixing. Do the same here.
>
> How many of these ld files can we get rid of if we use -Ttext-segment
> instead? Generally all we'
On 13.12.2011, at 17:31, Paul Brook wrote:
>> On 13.12.2011, at 07:19, Paul Brook wrote:
> When compiling qemu statically with multilib on PPC, we hit the
> same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
> is fixing. Do the same here.
How many of these
> On 13.12.2011, at 07:19, Paul Brook wrote:
> >>> When compiling qemu statically with multilib on PPC, we hit the
> >>> same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
> >>> is fixing. Do the same here.
> >>
> >> How many of these ld files can we get rid of if we use -Ttext-segme
On 13 December 2011 06:19, Paul Brook wrote:
>> > When compiling qemu statically with multilib on PPC, we hit the
>> > same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
>> > is fixing. Do the same here.
>>
>> How many of these ld files can we get rid of if we use -Ttext-segment
>> in
On 13.12.2011, at 07:19, Paul Brook wrote:
>>> When compiling qemu statically with multilib on PPC, we hit the
>>> same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
>>> is fixing. Do the same here.
>>
>> How many of these ld files can we get rid of if we use -Ttext-segment
>> inst
> > When compiling qemu statically with multilib on PPC, we hit the
> > same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
> > is fixing. Do the same here.
>
> How many of these ld files can we get rid of if we use -Ttext-segment
> instead? Generally all we're really caring about is m
On 13.12.2011, at 01:55, Richard Henderson wrote:
> On 12/12/2011 01:36 PM, Alexander Graf wrote:
>> When compiling qemu statically with multilib on PPC, we hit the
>> same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
>> is fixing. Do the same here.
>
> How many of these ld files c
On 12/12/2011 01:36 PM, Alexander Graf wrote:
> When compiling qemu statically with multilib on PPC, we hit the
> same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
> is fixing. Do the same here.
How many of these ld files can we get rid of if we use -Ttext-segment instead?
Generally
When compiling qemu statically with multilib on PPC, we hit the
same issue that commit 845f2c2812d9ed24b36c02a3d06ee83aeafe8b49
is fixing. Do the same here.
Signed-off-by: Alexander Graf
---
ppc.ld | 16 ++--
ppc64.ld | 16 ++--
2 files changed, 28 insertions(+), 4
19 matches
Mail list logo
