On 2024/07/12 2:05, Daniel P. Berrangé wrote:
On Mon, Jul 08, 2024 at 07:25:20PM +0800, junjiehua wrote:
when building elf2dump with x86_64-w64-mingw32-gcc, fwrite is imported from
msvcrt.dll. However, the implementation of msvcrt.dll!fwrite is buggy:
it enters an infinite loop when the size of
On Mon, Jul 08, 2024 at 07:25:20PM +0800, junjiehua wrote:
> when building elf2dump with x86_64-w64-mingw32-gcc, fwrite is imported from
> msvcrt.dll. However, the implementation of msvcrt.dll!fwrite is buggy:
> it enters an infinite loop when the size of a single write exceeds 4GB.
> This patch ad
On Fri, Jul 12, 2024 at 12:31 AM Daniel P. Berrangé
> wrote:
On Thu, Jul 11, 2024 at 04:53:50PM +0900, Akihiko Odaki wrote:
> > On 2024/07/10 17:02, hellord wrote:
> > >
> > > note:
> > > 1. The path of buggy msvcrt.dll is c:\windows\system32\msvcrt.dll(
> > > mingw64 links to it );
> > > 2. fwri
On Thu, Jul 11, 2024 at 04:53:50PM +0900, Akihiko Odaki wrote:
> On 2024/07/10 17:02, hellord wrote:
> >
> > note:
> > 1. The path of buggy msvcrt.dll is c:\windows\system32\msvcrt.dll(
> > mingw64 links to it );
> > 2. fwrite implementation in another msvc library which is called
> > ucrtbase.dll
On Thu, Jul 11, 2024 at 12:25 AM Peter Maydell
> wrote:
On Wed, 10 Jul 2024 at 09:02, hellord wrote:
> >
> >
> >>
> >>
> >> On Tue, Jul 9, 2024 at 10:39 PM Peter Maydell
> wrote:
> >> Is there a particular reason to use 128MB here? If the
> >> runtime only fails on 4GB or more, maybe we should
>
>
> On Thu, Jul 11, 2024 at 3:53 PM Akihiko Odaki
> wrote:
On 2024/07/10 17:02, hellord wrote:
> >
> > note:
> > 1. The path of buggy msvcrt.dll is c:\windows\system32\msvcrt.dll(
> > mingw64 links to it );
> > 2. fwrite implementation in another msvc library which is called
> > ucrtbase.dl
On 2024/07/10 17:02, hellord wrote:
On Tue, Jul 9, 2024 at 10:39 PM Peter Maydell
mailto:peter.mayd...@linaro.org>> wrote:
> +#define MAX_CHUNK_SIZE (128 * 1024 * 1024)
I think we could add a comment here, something like:
/*
* Maximum size to fwrite() to the output
On Wed, 10 Jul 2024 at 09:02, hellord wrote:
>
>
>>
>>
>> On Tue, Jul 9, 2024 at 10:39 PM Peter Maydell
>> wrote:
>> Is there a particular reason to use 128MB here? If the
>> runtime only fails on 4GB or more, maybe we should use
>> a larger MAX_CHUNK_SIZE, like 2GB ?
>
>
> According to current
>
On Tue, Jul 9, 2024 at 10:39 PM Peter Maydell
> wrote:
> > +#define MAX_CHUNK_SIZE (128 * 1024 * 1024)
>
> I think we could add a comment here, something like:
>
> /*
> * Maximum size to fwrite() to the output file at once;
> * the MSVCRT runtime will not correctly handle fwrite()
> * of m
On Mon, 8 Jul 2024 at 14:24, junjiehua wrote:
>
> when building elf2dump with x86_64-w64-mingw32-gcc, fwrite is imported from
> msvcrt.dll. However, the implementation of msvcrt.dll!fwrite is buggy:
> it enters an infinite loop when the size of a single write exceeds 4GB.
> This patch addresses th
when building elf2dump with x86_64-w64-mingw32-gcc, fwrite is imported from
msvcrt.dll. However, the implementation of msvcrt.dll!fwrite is buggy:
it enters an infinite loop when the size of a single write exceeds 4GB.
This patch addresses the issue by splitting large physical memory
blocks into sm
11 matches
Mail list logo
