is pipe2 implemented in terms of a syscall?

paulf: it is in fact its own system call

And then pipe() is a wrapper around it that passes 0 to pipe2() for flags

The in-kernel system call entry point is just called pipe(), though, which is at least a little confusing

OK thanks

I'm working on the prep for Valgrind 3.21 release, and there's a new configure time failure

This check "dis -F scf_handle_bind $libscf  | grep -q 0x526570" is failing

Now I see     scf_handle_bind+0xdf:  48 b8 15 70 65 52  movq   $0x4d0152657015,%rax

Can someone point me to the change? The fix is fairly straightforward

see the comment on top

OK, so this was a consequence of switching to gcc10?

I'll push that change

yes, and we hit it on omnios before since we switched to gcc10 a while ago

Done

dangergrrl: not sure, but i dont think so

sjorge, I'm working on process migration for linux but the code would be GPL2 swo I couldn't use it here at all, curse Sun for hating on Linux :P but I implemented the same feature at Tandem on SVR4 so I'm sure I could do it for Illumos and it's a handy thing... at Tandem we had ServerNet hardware though and it does remote DMA so I could recover running programs from a crashed machine (and hope they don't crash this machine also)

ServerNet hardware still kinda exists but it's now called infiniband

the nice thing about it is that you can access another machines RAM even if the kernel has paniced

jclulow: are you here?

jclulow: oh, I think xref is just a pain in the ass about where it finds all its bits. Which I'm not planning to fix. ignore me and enjoy your weekend.

paulf: Wow, why... Is it checking that

what the absolute heck

it seems they perhaps know about it for truss-y reasons?

it's used by something called 'tracegen', and the bits look like it's decoding different versions

I'm not sure in what world "the header that tells us this is private, let's disassemble the library" makes sense.

but it's true we don't ship the header for them to do (much) better.

I need to look, not familiar with it

all part of door the syscall wrapper

for clean separation between host and guest, the host does not link to any external libraries

partly for the same reason and partly for historical reasons including external headers is also kept to a minimum

ok, but why does it need to know the repcache protocol over the door?

as compared to any other door we use

at least at a quick glance, it didn't know about any others.

(I'm leaving aside that "a clean separation" and "not using the library" both seem to fall apart when you disassemble it and look inside)

you're just using the library _really weirdly_

if the host links to external libraries we wouldn't be able to check for any errors when they get loaded

I don't know the code well enough to comment on why the repcache protocol is needed

Yeah that's fair. Sorry, definitely did not mean to shoot at the messenger haha

yeah, we're just all very confused and surprised :)

and it's not the only hack by a long way, which is why thinks are forever breaking

things

I use cachegrind more than valgrind, but they're both handy, and I'm super happy someone keeps them working.

it also found the super annoying sprintf bug I'm not sure how to fix, where it fakes a FILE and then valgrind et all point out we're reading a totally junk _magic to decide if it's extended_file.

dhat is also very cool

looks like casper fixed that in our libc while he was fixing "sscanf() should not create a dummy FILE * with a valid descriptor"

my notes say "maybe memstreams?"