[continued from previous message]   
      
   https://kernel.googlesource.com/pub/scm/linux/kernel/git/nico/ar   
   hive/+/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   
      
   >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)