[continued from previous message]   
      
   >that was NOT the case, and it is easy enough to research, since   
   >old kernel versions are online.  Looking at e.g. 0.99.15, one   
   >can see that they set the carry bit in the flags register to   
   >indicate an error, along with returning a negative errno value:   
   >https://kernel.googlesource.com/pub/scm/linux/kernel/git/nico/a   
   chive/+/refs/tags/v0.99.15/kernel/sys_call.S   
   >   
   >By 2.0, they'd stopped setting the carry bit, though they   
   >continued to clear it on entry.   
   >   
   >But remember, `mmap` returns a pointer, not an integer, relying   
   >on libc to do the necessary translation between whatever the   
   >kernel returns and what the program expects.  So if the behavior   
   >you describe where anywhere, it would be in libc.  Given that   
   >they have, and had, a mechanism for signaling an error   
   >independent of C already, and necessarily the fixup of the   
   >return value must happen in the syscall stub in whatever library   
   >the system used, relying soley on negative values to detect   
   >errors seems like a poor design decision ifor a C library.   
   >   
   >So if what you're saying were true, such a check wuld have to   
   >be in the userspace library that provides the syscall stubs; the   
   >kernel really doesn't care.  I don't know what version libc   
   >Torvalds started with, or if he did his own bespoke thing   
   >initially or something, but looking at some commonly used C   
   >libraries of a certain age, such as glibc 2.0 from 1997-ish, one   
   >can see that they're explicitly testing the error status against   
   >-4095 (as an unsigned value) in the stub. (e.g., in   
   >sysdeps/unix/sysv/linux/i386/syscall.S).   
   >   
   >But glibc-1.06.1 is a different story, and _does_ appear to   
   >simply test whether the return value is negative and then jump   
   >to an error handler if so.  So mmap may have worked incidentally   
   >due to the restriction on where in the address space it would   
   >place a mapping in very early kernel versions, as you described,   
   >but that's a library issue, not a kernel issue: again, the   
   >kernel doesn't care.   
   >   
   >The old version of libc5 available on kernel.org similarly; it   
   >looks like HJ Lu changed the error handling path to explicitly   
   >compare against -4095 in October of 1996.   
   >   
   >So, fixed in the most common libc's used with Linux on i386 for   
   >nearly 30 years, well before the existence of x86_64.   
   >   
   >>>>I wonder how the kernel is informed that it can now return more   
   >>>>addresses from mmap().   
   >>>   
   >>>Assuming you mean the Linux kernel, when it loads an ELF   
   >>>executable, the binary image itself is "branded" with an ABI   
   >>>type that it can use to make that determination.   
   >>   
   >>I have checked that with binaries compiled in 2003 and 2000:   
   >>   
   >>-rwxr-xr-x 1 root root 44660 Sep 26  2000 /usr/local/bin/gforth-0.5.0*   
   >>-rwxr-xr-x 1 root root 92352 Sep  7  2003 /usr/local/bin/gforth-0.6.2*   
   >>   
   >>[~:160080] file /usr/local/bin/gforth-0.5.0   
   >>/usr/local/bin/gforth-0.5.0: ELF 32-bit LSB executable, Intel 80386, version   
   1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, stripped   
   >>[~:160081] file /usr/local/bin/gforth-0.6.2   
   >>/usr/local/bin/gforth-0.6.2: ELF 32-bit LSB executable, Intel 80386, version   
   1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for   
   >>GNU/Linux 2.0.0, stripped   
   >>   
   >>So there is actually a difference between these two.  However, if I   
   >>just strace them as they are now, they both happily produce very high   
   >>addresses with mmap, e.g.,   
   >>   
   >>mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =   
   0xf7f64000   
   >   
   >I don't see any reason why it wouldn't.   
   >   
   >>I don't know what the difference is between "for GNU/Linux 2.0.0" and   
   >>not having that,   
   >   
   >`file` is pulling that from a `PT_NOTE` segment defined in the   
   >program header for that second file.  A better tool for picking   
   >apart the details of those binaries is probably `objdump`.   
   >   
   >I'm mildly curious what version of libc those are linked against   
   >(e.g., as reported by `ldd`).   
   >   
   >>but the addresses produced by mmap() seem unaffected.   
   >   
   >I don't see why it would be.  Any common libc post 1997-ish   
   >handles errors in a way that permits this to work correctly.  If   
   >you tried glibc 1.0, it might be a different story, but the   
   >Linux folks forked that in 1994 and modified it as "Linux libc"   
   >and the   
      
   ...and the Linux folks changed this to the present mechanism in   
   1996.   
      
   (Sorry 'bout that.)   
      
   >>However, by calling the binaries with setarch -L, mmap() returns only   
   >>addresses < 2GB in all calls I have looked at.  I guess if I had   
   >>statically linked binaries, i.e., with old system call wrappers, I   
   >>would have to use   
   >>   
   >>setarch -L    
   >>   
   >>to make it work properly with mmap().  Or maybe Linux is smart enough   
   >>to do it by itself when it encounters a statically-linked old binary.   
   >   
   >Unclear without looking at the kernel source code, but possibly.   
   >`setarch -L` turns on the "legacy" virtual address space layout,   
   >but I suspect that the number of binaries that _actually care_   
   >is pretty small, indeed.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)