memory/virtual.c: ROUND_SIZE() bugfix + .SYS loading

Alexandre Julliard julliard at winehq.com
Mon Sep 16 14:47:23 CDT 2002


Jan Kratochvil <short at ucw.cz> writes:

> I had incorrect warnings "Section %.8s too large (%lx+%lx/%lx)" during loading
> of some low-level system libraries. It got fixed by the attached
> "wine-memory-virtual.c-too_large_section.diff" which changes (I think fixes)
> ROUND_SIZE() behaviour. It also comments ROUND_ADDR() and ROUND_SIZE(), I hope
> I guessed its intended description from the style of its usage around the code.

No, ROUND_SIZE is supposed to return an aligned size, which you use
together with an aligned address. The normal pattern is to use
ROUND_SIZE and ROUND_ADDR together. We don't bother to round addresses
in image mapping because all the code assumes the image has correct
section alignment already.

> Attached "wine-memory-virtual.c-mmap_cache-preliminary.diff" is just a RFC as
> I found out that I was unable to load some .SYS files as they were being
> attempted to be loaded with page-overlapping sections, unaligned offsets and
> incompatible protections. Therefore I had to implement my own mapping cache and
> handle the overlapping/merging myself. It would be more simple/clean to use
> Linux /proc/$$/maps mmap map but it would be probably no-no as it is
> Linux-dependent.

I think this is complete overkill. Mapping unaligned binaries is a
very unusual case and should be treated as such. There's no need to
maintain such a complex structure, or add support for non page aligned
mmaps, for such an exotic feature. Probably what you want is to create
a separate map_image_unaligned function to map images that don't have
a proper section alignment, using read() and not worrying about
protections at all.

-- 
Alexandre Julliard
julliard at winehq.com



More information about the wine-devel mailing list