Jlalond wrote: @DavidSpickett I think I figured out the weirdness on this issue. The page within the VMA is marked as `DONTNEED` and is appropriately zapped. Then when we come around to do `vm_process_readv` we get back `EFAULT` for that page, despite arguably being the same as a virtual page of all zeros.
It looks like even in this case [gdb fails and zerofills the rest of the PT_LOAD](https://github.com/redox-os/binutils-gdb/blob/master/gdb/gcore.c#L539C1-L545C3). So I think there are two distinct situations here - In the case where the unavailable memory is the end of the region, do we truncate or not? (I say yes) - If there is a page hole, do we backfill with zeros? (I would also say yes) However, I think this is appropriate for the GDB server to handle, and if possible, add some commentary on as it might be very confusing to a user why a page they want to access is unreadable, but then at another time becomes readable after a page-fault. > So filling with zeros at least has precedent, but - >> especially as this is the behavior I'm explicitly trying to remove in the >> Linux kernel 😆! > Maybe this is the behaviour you are trying to remove? I've been on a side-quest to reduce ELF core sizes see [this patch](https://lore.kernel.org/all/[email protected]/), and it's also why I'm pro truncation of unreadable/unfaulted pages, however because the Minidump spec doesn't support a filesz vs memsz concept we might have to zero fill or truncate the memory descriptor https://github.com/llvm/llvm-project/pull/212641 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
