10:02:57 <nikolam> should loader be re-installed on the both mirrored drives in pool, in order to boot from them, if  prtvtoc | fmthard and zpool attach , have been already done (both drives detached and resivlered) 
17:21:34 <alanc> btw, as people work on LP64'izing, it looks like illumos still needs to fix instances of the bug originally reported as https://defect.opensolaris.org/bz/show_bug.cgi?id=18153 in which calls of execl(...., 0) are made that pass a 32-bit int where the function is looking for a 64-bit NULL pointer
17:22:26 <gitomat> [illumos-gate] 14993 zfs-tests: Move platform independent tests to a shared runfile -- Ryan Moeller <ryan⊙ic>
19:40:10 <KungFuJesus> alanc: wait, Solaris wasn't LP64 from the get go?  I swear everything I've read says it was
19:55:03 <rmustacc> KungFuJesus: Nope.
20:01:28 <KungFuJesus> what was it?  ILP64?
20:06:47 <rmustacc> ILP32
20:07:42 <gwr> Well, technically both, right?  32/64.
20:08:02 <rmustacc> Well, originally it was ILP32, then LP64 execution environments were added.
20:08:33 <rmustacc> Most commands in illuos are still ILP32 while at some point in the S11 train they are all LP64.
20:10:33 <alanc> Yes, Solaris was exclusively ILP32 until Solaris 7 started adding LP64 stuff
20:11:38 <alanc> https://blogs.oracle.com/solaris/post/moving-oracle-solaris-to-lp64-bit-by-bit is the backstory
20:12:06 <alanc> https://blogs.oracle.com/solaris/post/oracle-solaris-114-beta-progress-on-lp64-conversion has the chart showing our big change in 11.4 (which was orignally going to be 12.0 when we did most of that work)
20:16:34 <alanc> There was a brief ILP64 offshoot of Solaris made by HAL for their SPARC64 processors before Sun did the LP64 in Solaris itself - https://queue.acm.org/detail.cfm?id=1165766 has more on that story
20:23:45 <richlowe> there is so much 64bit uncleanliness
20:23:56 <richlowe> so much
20:25:34 <richlowe> if someone wanted directing toward some, I happen to have a list
20:25:48 <richlowe> a lot of it is probably people passing cookies in (void *)'s and casting them straight to int.
20:25:55 <richlowe> so there's even a lot of bitesize stuff in there
20:26:40 <rmustacc> Is there a smatch/gcc warning for those by chance?
20:27:31 <richlowe> not when 32bit
20:27:41 <richlowe> when 64bit gcc of course gives pointer cast to different sized int
21:54:21 <jperkin> pmooney: having -fforce-omit-frame-pointer seems reasonable for your use-case
21:54:52 <pmooney> jperkin: cool, thanks
21:55:21 <pmooney> I do appreciate -fomit-frame-pointer being a lie for things like pkgsrc, where it would be a huge pain to teach all those packages to skip it
21:55:48 <pmooney> but for the stuff which truly needs it...
22:18:41 <richlowe> it is a painful way to discover something uses the base pointer as scratch