Apologies for the top post. Man pages indicate getauxval is a non standard glibc function. Is this an issue? Is there a more posix way I could compare against? I was previously wondering to myself if the Linux api is now more standard than the posix api?
Looking forward to all opinions and comments. Rus Sent from my BlackBerry 10 smartphone on the Virgin Mobile network. Original Message From: Konstantin Belousov Sent: Saturday, September 9, 2017 2:46 PM To: Ian Lepore Cc: freebsd-...@freebsd.org; freebsd-toolchain@FreeBSD.org; Jan Beich; Jan Beich Subject: Re: FCP-100: armv7 plan On Sat, Sep 09, 2017 at 02:34:10PM -0600, Ian Lepore wrote: > Adding the AT_HWCAP stuff would be relatively easy. I'm not as sure > what to do about getauxval(). To be maximally linux-compatible (which > would be good for ports) we'd put getauxval() in libc and make it work > just like the linux one. That's a bit at odds with the support we have > now, which is procstat_getauxv() in libprocstat. It's not very > compatible with how linux getauxval() works, so using just that might > lead to a lot of patches in ports. libprocstat is for accessing other processes information and address space. Our libc already has _elf_aux_info, but it is not exported. If you have a clear description of the desired API, I can add it (I do not want to read glibc code). _______________________________________________ freebsd-...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org" _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
