Re: port-sparc/60838: sparc fails to enforce RLIMIT_DATA on exec

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

Looks like the kernel might consider the executable in question to
have zero data size because all LOAD segments have the X bit set
(/bin/sh, but I also checked a couple others, /bin/ls, /bin/sync, and
/usr/bin/awk on sparc64, and they have the same pattern):

$ readelf -l ./bin/sh
...
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
...
  LOAD           0x000000 0x00010000 0x00010000 0x30760 0x30760 R E 0x10000
  LOAD           0x030760 0x00050760 0x00050760 0x00af4 0x02468 RWE 0x10000

(Here `E' means execute, which I'm also calling `X' because the
constant is named PF_X and colloquially it's known as the eXecute
bit in the context of, e.g., W^X protection.)

So the kernel will consider them both to be `text segment', and
neither to be `data segment', and eventually conclude that the
executable's `data size' is zero:

    703 	epp->ep_taddr = epp->ep_tsize = ELFDEFNNAME(NO_ADDR);
    704 	epp->ep_daddr = epp->ep_dsize = ELFDEFNNAME(NO_ADDR);
...
    776 			/*
    777 			 * Consider this as text segment, if it is executable.
    778 			 * If there is more than one text segment, pick the
    779 			 * largest.
    780 			 */
    781 			if (ph[i].p_flags & PF_X) {
    782 				if (epp->ep_taddr == ELFDEFNNAME(NO_ADDR) ||
    783 				    size > epp->ep_tsize) {
    784 					epp->ep_taddr = addr;
    785 					epp->ep_tsize = size;
    786 				}
    787 				end_text = addr + size;
    788 			} else {
    789 				epp->ep_daddr = addr;
    790 				epp->ep_dsize = size;
    791 			}
...
    828 	if (epp->ep_daddr == ELFDEFNNAME(NO_ADDR)) {
    829 		epp->ep_daddr = round_page(end_text);
    830 		epp->ep_dsize = 0;
    831 	}

https://nxr.NetBSD.org/xref/src/sys/kern/exec_elf.c?r=1.107#776

Is it expected that sparc executables have only RX and RWX segments,
no separate R or RW segments?  Does sparc have some stupid ABI design
that is incompatible with W^X?