:> +                            data_addr = seg_addr;
:>                      }
:I don't think we can do this (the last section), it is quite legal to have
:more than one non-text PT_LOAD segment.  if the last one was very small,
:we'd end up with an artificially low 'data_size' which would make for
:interesting RLIMIT_DATA enforcement.

    Well, this represents a reversion to what the data and text calculations
    were before any of my commits.  I think that the best bet is to revert
    that part of the calculation completely rather then revert it only
    half way.  From what I understand there is usually only one data
    segment in an ELF binary anyway.  I am also worried that the kernel
    may be using the vmspace data start and size in other ways and, really,
    the safest solution for now is to revert it so data_start + data_size
    yields the end of data in the last loaded data segment (which is also
    the highest addressed data segment according to the ELF spec).

    We can always put it back in later.  I will also note that 
    RLIMIT_DATA is not really all that useful a resource limit.
    It's there basically to protect against runaway malloc()s but
    it does not in any way limit the amount of memory a program
    actually uses since mmap() is not counted.  RLIMIT_VMEM is
    the ultimate memory resource limit.

                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to