GNU Tools @ LPC Wednesday 26 Aug 2020: chat record ================================================== All times are BST (UTC + 1) Pre-start --------- [14:16] YouTube Live : This meeting is streaming live on YouTube [14:48] Elena Zannoni : good morning [14:49] Elena Zannoni : notes and chat from yesterday are attached to the track in the main website [14:49] Jose E. Marchesi : super, thank you [14:50] Jeremy Bennett : Good morning/afternoon/evening all [14:51] Catherine Moore : hi everyone [14:52] David Edelsohn : good morning [14:53] Jeremy Bennett : Just testing the polling functionality [14:53] Jeremy Bennett : Now how do you get rid of a published poll? [14:53] Jeremy Bennett : You are muted Jose [14:58] Nick Alcock : btw, the cause ofmy choppy audio yesterday was CPU saturation caused by *RocketChat* in a background window [14:58] Nick Alcock : It likes to peg a couple of cores... [14:58] Nick Alcock : So if you notice audio/video desync, etc, make sure you're not looking at that anywhere [14:58] Simon Marchi : Hello [14:59] Iain Sandoe : hi all [14:59] Tobias Burnus : As last year the CC0 removal was mentioned: I was asked by Adrian (who was active in setting up bounties for the CC0 to mode_CC convertion) to mention that VAX and AVR conversion is being done :-) GCC Steering Committee Q&A -------------------------- [15:03] Pedro Alves : git conversion! [15:04] Tulio Magno Quites Machado Filho : youtube transmission has no audio [15:04] Roland Hieber : can confirm that youtube has no audio [15:04] Joseph Myers : As of last week, the upstream AdaCore git hooks have implemented all the feature requests filed, so I hope to work on moving GCC to the latest upstream hooks version. [15:04] Frank Ch. Eigler : face-to-face cauldron please if able [15:04] Andrea Corallo : +1 [15:05] Ben Woodard : I understand the time zone issues but I feel like the format kind of leaves no time to talk. Thanks to the LPC for providing the infrastructure. [15:05] Joseph Myers : New hooks should mean many fewer local hook changes needed, and also fix the commit emails for merges/rebases. [15:06] Jonathan Corbet : Looking into the youtube audio issue [15:06] Iain Sandoe : it's useful to have the tools cauldron separate (IMO) and face-to-face please. [15:07] Simon Marchi : Colocated but not concurrent would help for organizing as well [15:07] Laura Abbott : some people in the kernel community complain about conference fatigue so trying to get to two conferenes is hard [15:07] Nick Alcock : Elena: volume++? [15:07] Nick Clifton : one-after-the-other sounds good to me! [15:07] YouTube Live : This meeting is streaming live on YouTube [15:08] Tulio Magno Quites Machado Filho : Youtube audio is working now. @Jonathan: thanks! [15:08] Jonathan Corbet : Thank Guy, I only passed the word on :) [15:09] Mark Wielaard : Yes! My employer has been really supportive, but having this during the weekend is nice [15:11] Brendan Gregg : I'm always fighting with the -fomit-frame-pointer default on x86 (e.g., it breaks BPF profiling via distro-default glibcs, so companies build their own glibc). Any interest in revisiting this default? [15:12] Nick Alcock : What's the slowdown these days? It was prohibitive in the days of x86-32 with limited/no register renaming: is it much lower these days? I'm sure it's at least *somewhat* lower. [15:12] Frank Ch. Eigler : Brendan, what would be the performance cost of catering to more backtracing-capability-limited tooling? [15:13] Brendan Gregg : At Netflix it's so low it's impossible to measure (with one workload exception, but that system lacks PEBS/etc for me to see what's really going on). Twitter also publicly said it was basically zero cost nowadays. [15:13] Laura Abbott : LPC tries to alternate between US and Europe (for those who can't hear Elena) [15:13] Carlos O'Donell : We were going to be in CANADA this year :-) [15:14] Jose E. Marchesi : Canada yeah [15:14] Jose E. Marchesi : The event at Montreal was superfun [15:14] Mark Wielaard : Brendan I think the issue is simply that there are constructs where frame pointers break backtraces anyway [15:14] Ben Woodard : "Canada doeesn't count as foreign -- it's like attached." - some comic [15:14] Ben Woodard : ;-) [15:15] Mark Wielaard : https://my.fsf.org/civicrm/contribute/transact?reset=1&id=57 [15:16] Mark Wielaard : https://www.fsf.org/working-together/fund [15:17] Andrew MacLeod : I think Canada counts as foreign now... I certainly feel that way :-) [15:17] Carlos O'Donell : :-) [15:17] Ben Woodard : @andrew MacLeod - I"ll agree with that [15:18] Ben Woodard : I live in California [15:18] Ben Woodard : My big concern with GNU Toolchain is succession. [15:19] Keith Seitz : Sadly, many of us in the USA also feel like we are living in a foreign country. [15:20] DJ Delorie : ah, the cygnus days... [15:20] Frank Ch. Eigler : all hail DEVO [15:20] DJ Delorie : and there was ONE libiberty [15:21] nathan sidwell : I'm glad pedro clarified how counting works! [15:21] DJ Delorie : having glibc be in sync with fedora but one number off is confusing... [15:21] Catherine Moore : /me misses cygnus [15:21] Nick Alcock : at least a nicer way to propagate libiberty/intl/etc changes between cygnus-tree projects would be nice! [15:22] Nick Alcock : doing it by hand feels so *wrong* [15:22] David Edelsohn : The succession plan for all Free and Open Source projects is a question. [15:22] Michael Meissner : Catherine Moore: Same here [15:22] David Malcolm : How about calendar year-based numbering? (not sure if serious) [15:22] Patrick McGehearty : As relatively new to Linux toolchain (3 years), when I started, I often would get confused about which versions of the different pieces of the toolchain were current or in release or whatever. [15:22] Elena Zannoni : catherine & micheal ditto [15:23] Frank Ch. Eigler : @Patrick, the toolchain do work with different versions of each other okay [15:23] Joseph Myers : It would be possible to have a git repository for libiberty / include / shared toplevel files, and merge from that to the individual repositories (if you make an exception to the rule against merge commits on master, anyway). [15:23] Nick Alcock : This feels like a use-case for git subtree... [15:23] Patrick McGehearty : It was most commonly an issue when trying to reproduce a bug report. [15:24] Segher Boessenkool : release names based on calendar date seems confusing with three releases trees [15:24] Mark Wielaard : yes, what Joseph said (plus bfd) [15:24] Michael Meissner : That being said, I recall the Cygnus releases taking a huge amount of time. I imagine that is true for CS currently. [15:25] Joseph Myers : subtree looks something like the git magic Thomas came up with for integrating the glibc ports tree into the main repository. [15:25] Josh Stone : @mjw are you still going to stay on elfutils 0.BIG_NUMBER? ;) [15:25] Pedro Alves : I've vote for a single repo. Put everything together. [15:25] Jeremy Bennett : Thank you David [15:25] Elena Zannoni : thank you!! [15:25] Mark Wielaard : Josh I hoped nobody would bring that up [15:25] Ben Woodard : It isn't ready yet. ;-) [15:25] Carlos O'Donell : Thank you everyone for supporting the GNU Toolchain! [15:25] Carlos O'Donell : *clap* *clap* [15:26] Mark Wielaard : Josh really the only issue is that there are some version check macros that would get very confused if the first digit isn't 0. [15:26] Simon Marchi : A single repo would indeed be nice [15:27] Simon Marchi : Especially if we can keep the history of the binutils-gdb and gcc repos in the new merged repo [15:27] Nick Alcock : I'm just hoping for a nicer way to sync changes :) [15:27] Josh Stone : @mark, that's a one-time pain, just like leaving kernel 2.6.x behind [15:27] Frank Ch. Eigler : single repo -- maybe just emulate with git modules [15:27] Jeremy Bennett : Volunteer wanted to take notes during the LLVM/GCC BoF [15:27] Nick Alcock : throwing away the history would clearly be a non-starter. retaining the history is easy now, since we're all on git :) [15:28] Frank Ch. Eigler : I volunteer as note tribute. [15:28] Jeremy Bennett : Much appreciated Frank [15:28] Simon Marchi : I imagine doing one big merge commit to unify the two master branches into one, then a linear history after that [15:28] Pedro Alves : submodules are a pain when you need to do cross modules commits, merges, etc. it's good for 3rd party dependencies, but for parts of you're project, meh... [15:28] Simon Marchi : So if you need to dig past the merge point, you still can [15:28] Joseph Myers : I think combining two histories like that would result in a rather confusing history. [15:29] Nick Alcock : Pedro: yeah, git subtree avoids most of that pain (and it's integrated into git proper nowadays) [15:29] Pedro Alves : putting everything together would be great for fostering sharing of code between the projects. [15:29] Nick Alcock : Joseph Myers: git log --graph and/or gitk are your saviours here [15:29] Pedro Alves : how many dwarf readers do we need, anyway? [15:29] Simon Marchi : Nick: people probably don't know about git subtree (me included) you should do a quick presentation about it! LLVM/GCC BoF ------------ [15:30] Nick Alcock : Argh I'm on the spot now :) anyway must dash, got a binutils push to prep for :) [15:30] Simon Marchi : @Joseph: when looking at non-shared files, it wouldn't change anything from today, when doing a git blame at least [15:30] Pedro Alves : it's one of the strengths of llvm -- they push for moving things to shared utilities and libraries. while we in gnu land duplicate everythin g (in different languages!) because of the repo barrier. [15:30] Joseph Myers : When doing "git log" you'd get a random mixture of commits to the two projects, because that's the default order git log uses. [15:31] Mark Wielaard : valgrind also contains parts of libiberty, for which we have a script to import them, which is currently broken because it still pulls from svn... sigh [15:31] Simon Marchi : Yeah... but there are tools to better visualize this if needed. And like I said, when looking at non-shared files (which we do 99% of the time), it won't change anything [15:31] Simon Marchi : When doing "git log " [15:32] Mark Wielaard : we can get bonus points? [15:32] Jonathan Corbet : Nice, nobody ever includes documentation :) [15:33] Mark Wielaard : heay, no elfutils! :) [15:33] Joseph Myers : We certainly could do with automation of propagating changes to shared files between the repositories. [15:33] Nick Desaulniers : F [15:33] Joseph Sible : It only let us pick one answer [15:33] Mark Wielaard : O, I can only pick gdb [15:33] Nick Clifton : @Jeremy I use more than one of those.... [15:33] Serge Sans Paille : yeah, that's a way to favor gdb in the poll :-) [15:34] Jose E. Marchesi : everyone picked gdb because it was first in the list :D [15:34] David Malcolm : Seems to have been mutex choices, rather tha multiple booleans [15:34] Simon Marchi : Mark: that's the right answer anyway [15:34] Pedro Alves : lol [15:34] Michael Meissner : Hmmm, you can only do one answer. It may have been better to select debug and binutils separately [15:34] Jose E. Marchesi : @Mark poke is neither there :( [15:34] Elena Zannoni : you are missing the F from the poll jeremy [15:34] Mark Wielaard : This election is rigged! [15:35] Pedro Alves : needs a blockchain. [15:35] Jose E. Marchesi : /me goes to reach the pitchfork and torch [15:36] Nick Desaulniers : F [15:36] Kees Cook : heh F :) [15:36] Nick Clifton : Jeremy: C and E are basically the same.... [15:36] Mark Wielaard : It is interesting GNU ld/gold is separate fro GNU binutils [15:36] Mark Wielaard : I would call them one and the same [15:36] Nick Desaulniers : yes [15:37] Mark Wielaard : and of course if you hack of bdf you get GDB and binutils for free :) [15:37] Elena Zannoni : ok only 5 options for polls, confirmed sorry [15:38] Mark Wielaard : Where would something like DWARF go? [15:39] Alex Coplan : All of the above! [15:39] Ben Woodard : I haven't tried this but can you use lld with when linking with GCC using LTO [15:40] Ben Woodard : Test that toools like libabigail give valid results [15:40] Mark Wielaard : So at the moment vaporware, but there is https://sourceware.org/gnu-gabi/ [15:40] Serge Sans Paille : Ben : I'd say no (lld doesn't know gimple, right) [15:41] Ben Woodard : Same names for -march= [15:41] Jakub Jelínek : binutils doesn't either, but it has a plugin support and the plugin can handle that [15:41] Michael Meissner : Machine specific machine constraints for GCC/LLVM is probably an issue [15:41] Joseph Sible : I've definitely noticed that with GCC vs. Clang inline assembly. Some uses of it will do different things with the same code and neither compiler will warn you [15:42] Peter Zijlstra : I was quite annoyed that clang ias didn't do JMP.d32 [15:45] Nick Desaulniers : I'm working on the __builtin_*s [15:46] Michael Meissner : Yeah, nested functions is one of the things I wish had never been invented. [15:46] Mark Wielaard : yeah, elfutils has the same issue, we even have a configure test now to check for various GNU C language extensions not supported by clang [15:47] Nick Desaulniers : Peter, please file bug reports, or email someone who works on LLVM when you find something missing. [15:47] Jakub Jelínek : They are there for Fortran and standard there... [15:47] Serge Sans Paille : @Ben Woodar: https://github.com/llvm-mirror/lld/blob/master/ELF/Options.td#L547 [15:47] Ben Woodard : it isn't just ABI compatibility it is also verifiable ABI [15:48] Michael Meissner : As an amusing side thing, I worked temporarily for a non-open source compiler that implemented GCC inline asm (Metrowerks). They broke the asm lines into separate internal statements, and then optimized those. The PS/2 game developers were not amused that their hand optimized asm broke. [15:49] Peter Zijlstra : @Nick you were on the thread :-) [15:49] Hongjiu Lu : https://bugs.llvm.org/show_bug.cgi?id=39501 [15:49] Nick Desaulniers : Cause I proactively saw you trying to use something I didn't recognize, and went out of my way to test/verify it. [15:52] Geoffrey Thomas : LLVM/GCC ABI compatibility is probably going to be important for Rust in the kernel - unless everyone switches to compiling kernels with LLVM or someone writes a GCC Rust frontend (neither of which seem likely to happen soon :) ), we'll be combining LLVM- and GCC-built code [15:54] Mark Wielaard : The linux-api one is very noisy [15:54] Jakub Jelínek : https://bugs.llvm.org/show_bug.cgi?id=44228 [15:54] Mark Wielaard : https://lore.kernel.org/linux-api/ [15:54] Jakub Jelínek : https://bugs.llvm.org/show_bug.cgi?id=42439 [15:54] Frank Ch. Eigler : https://sourceware.org/mailman/listinfo/gnu-gabi << there's also this [15:54] Florian Weimer : Discord? I think they prohibit all commercial use. [15:55] Josh Stone : Rust uses both Discord and Zulip, but moving more to the latter [15:55] Gaius Mulley : discord is good - have used this in anger during classes [15:55] Joseph Myers : Discourse not Discord? [15:55] Mark Wielaard : What are "these things"? [15:56] Geoffrey Thomas : Rust uses both Discord (chat system) and Discourse (forum system) :) [15:56] Josh Stone : Discourse is more forum than chat [15:56] Florian Weimer : Ah, Discourse is different, no firm opinion on that ony mpart. [15:56] Joseph Myers : Discourse is free software. Discord is some kind of hosted SaaSS, I think. [15:56] Mark Wielaard : Anyway, if people are interested then I personally would certainly help with https://sourceware.org/gnu-gabi/ [15:57] David Edelsohn : Thanks, Jeremy! [15:57] David Edelsohn : Geoffrey, we are starting a bounty to encourage someone in the Rust community to connect to GCC. [15:57] Nick Desaulniers : I'm going to jump into hack room 5 [15:57] Daniel Axtens : It's fine, don't stress. [15:58] Nick Desaulniers : if anyone wants to chat more [15:58] Mark Wielaard : David is that for writing a new frontend, or adapting an existing rust frontend to gcc? [15:58] Jeremy Bennett : Thanks for talking notes Frank [15:58] Tobias Burnus : https://meet.2020.linuxplumbersconf.org/hackrooms -> Room 5 (if someone is looking for that link) [15:58] Josh Stone : I think it would be more fruitful to keep the Rust front end, and only adapt the back [15:59] David Edelsohn : Mark, earlier discussions seemed to prefer connecting the existing Rust front-end [15:59] David Edelsohn : similar to GCC Go [15:59] David Edelsohn : ideally a separate implementation of the Rust front-end would help to "keep everyone honest", like the multiple C++ front-ends. Lightning talk: Accellerating machine learning using GCC built-ins ------------------------------------------------------------------ [16:00] David Edelsohn : But Rust is evolving rapidly. [16:03] Florian Weimer : GCC Go reuses the runtime library only, but I think the frontend was reused for the LLVM port. [16:04] Jakub Jelínek : GCC Go has a shared part of the FE which can and is used by other compilers and a GCC specific part [16:04] Ben Woodard : FMA for matrices [16:09] Peter Bergner : Thank you Raji! [16:10] Welcome to the Linux Plumbers Conference 2020 GNU Tools track/Virtual-Room!

Please remember that the LPC anti-harassment policy applies to interaction in this room, and that this room is being recorded.

Please keep your microphone muted and your video off except when participating in the discussion.

This server is running BigBlueButton. [16:10] Ben Woodard : But what about cDNA2? [16:11] David Edelsohn : Because of the recent transitions in the Rust community, I am hoping that there might be some developers who would be interested in the project. [16:11] Andrew Stubbs : Huh? "Could not make websocket connection [16:12] David Edelsohn : If anyone has connections to the Rust project and can help to reach out to them, that would be great, or please help to introduce me. [16:12] Frank Ch. Eigler : @David, meet @Josh, [16:12] Geoffrey Thomas : David - yeah I've seen a couple attempts at alternative Rust implementations/frontends [16:12] Geoffrey Thomas : and yeah chat with Josh :) [16:12] Josh Stone : /me waves [16:12] Geoffrey Thomas : there's a #rust in rocketchat btw [16:13] Andrew Stubbs : This was working yesterday [16:13] Geoffrey Thomas : if we want to move there instead of using this sidebar :) [16:13] David Edelsohn : I had a problem with audio earlier. [16:13] Ben Woodard : same here [16:13] David Edelsohn : it may be that the server is overloaded [16:13] Ben Woodard : I had to logout and log back in [16:13] Ben Woodard : and then I could only get listen only [16:13] David Edelsohn : yes, I had to log out and log back in [16:13] Josh Stone : sure, I just joined #rust [16:14] David Edelsohn : #rust on which chat system? [16:14] Geoffrey Thomas : https://chat.2020.linuxplumbersconf.org/channel/rust Lightning talk: AMD GCN update ------------------------------ (this talk was delayed 6 minutes by audio issues) [16:16] Serge Sans Paille : mmmh lost audio again [16:17] Jose E. Marchesi : @Andrew can you please unmute? [16:18] Jeremy Nickurak : I wonder if Andrew can't hear you, Jose. [16:18] Sarah Cook : Andrew can you hear Jose? [16:18] Andrew Stubbs : I can hear [16:18] Nick Alcock : Just run with your webcam off, it worked for me :) [16:18] DJ Delorie : it wouldn't be a conference call without audio problems ;-) [16:19] Nick Alcock : Yes! [16:19] Miguel Saldivar : yes [16:19] Sarah Cook : I can hear you Jose [16:19] Joseph Sible : We can hear you Jose [16:19] Gaius Mulley : yes ! [16:19] Lucas Alexandre Mello Magalhães : yes [16:19] David Malcolm : I can hear you Jose [16:19] Jeremy Nickurak : i can hear you jose. Can't hear andrew. [16:19] Jeremy Nickurak : BBB says Andrew is unmuted, but we can't hear him. Maybe an OS/device mute button? [16:20] Gabriel Padilla : he might be behind a vpn [16:20] David Malcolm : yes! [16:20] Gaius Mulley : yes [16:20] Jeremy Nickurak : hooray :) [16:21] Ben Woodard : Super important for us. [16:21] Ben Woodard : is it GCN or is it cDNA2 [16:22] Elena Zannoni : echo test not working, could be vpn related [16:25] Nick Alcock : I bought a distinctly low-end AMD box earlier this year and it came with a Vega10 APU :) [16:28] Tobias Burnus : @elena: VPN causes problems here (same VPN as Andrew's). But yesterday, it failed for a couple of times without when asking for micro support - it did work in listening-only mode. I had the feeling that something was overloaded. (The echo test itself was fine, it failed afterward.) [16:28] Ben Woodard : What about DWARF? [16:29] Nick Alcock : both chrome and ff let you find tabs eating CPU time. this can often be useful to fix juddering audio/video [16:29] Elena Zannoni : @tobias yesterday we had some issues with the servers i believe, everything was restarted during the night, hopefully those other problems will not occur again Security related flags ---------------------- (this talk started 3 minutes late, due to earlier technical issues) [16:30] Elena Zannoni : and saw a few people saying they restarted the browser and that fixed it [16:31] Ben Woodard : When can we start DWARF6? [16:33] Elena Zannoni : the servers are way oversized and still 90% idle even with everything going on [16:33] Tobias Burnus : @Ben: I think currently, AMD's DWARF extension clash with other extensions - as it can happen with extensions. opefully, AMD will upstream their extensions soon + release their GDB - and avoid extension clashes. [16:34] Jason Merrill : there has been talk on the dwarf list of starting up the dwarf6 process, particularly for this stuff, but it hasn't happened yet [16:34] Jakub Jelínek : but even when it starts, it can take a year or two to get in and can change substantially from the proposal [16:34] Andrew Stubbs : tried both desktop firefox and android firefox, and both had issues conencting audio. :-( [16:35] Ben Woodard : @jason merrill and we also want stuff in DWARF that allows us to do data flow analysis in perf tools. [16:35] Andrew Stubbs : video worked fine [16:35] Kees Cook : +1, compilers are Sith. ;) [16:35] Nick Desaulniers : and haunted [16:37] Kees Cook : (Ubuntu patches the compiler for default hardening, Debian doesn't.) [16:39] Ben Woodard : @jakub jelinek @jason merrill The fact that it can take a couple of years is why we need to ramp up the push for DWARF6 now. [16:39] Ben Woodard : gathering the proposals, setting the agendas beating on them until they are good enough... [16:40] Kees Cook : =pattern is handy,, =zero is critical [16:41] Joseph Sible : I learned the hard way that -Wl,-z,now breaks ltrace. So it's not just a performance impact that these flags can have [16:41] DJ Delorie : =pattern helps you find uses of uninitialized variables more than =zero though, esp for pointers [16:42] Ben Woodard : GOT/PLT Overwrite is something that we use for tooling - particular symbol wrapping. [16:42] Geoffrey Thomas : have you tried latrace btw? it seems to be much less well known than ltrace [16:42] Kees Cook : the latter (=zero) is (effectively) being used by default for Windows kernel, iOS, Android, Chrome OS, ... [16:42] qing zhao : =pattern is used in development phase, but =zero can be used in product [16:42] Geoffrey Thomas : latrace uses LD_AUDIT, so I think it will still work with -z now? [16:42] Nick Alcock : maybe LD_BIND_NOW in the environment should be preferred instead, because if needed you can turn that off occasionally without recompiling. [16:42] Chris Down : has -ftrivial-var-auto-init overhead gotten better now? i thought it's something crazy like 5% in some typical workloads [16:42] Nick Desaulniers : XOM RIP [16:43] Nick Desaulniers : on aarch64 [16:43] Joseph Sible : Geoffery Thomas - yes but it doesn't seem to work right form either. I think I run into https://bugzilla.redhat.com/show_bug.cgi?id=1628206 and/or https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/1243473 [16:43] Joseph Sible : s/form/for me/ [16:43] Geoffrey Thomas : haha wow did I report that [16:44] Geoffrey Thomas : I got halfway through reading that bug report until I recognized my hostname [16:45] DJ Delorie : Geoffrey: both ltrace and latrace are "dead" upstream. We're thinking of adding an LD_AUDIT backend to ltrace to account for the latest PLT optimizations, but it might need ld.so support [16:45] Joseph Sible : Indeed. It's been a while since I last tried latrace, and I just looked at it again now after I sent that, and it's not even in RHEL anymore [16:45] Nick Alcock : it does still work. :) [16:46] Geoffrey Thomas : yeah, I admit I haven't used it for many years [16:46] DJ Delorie : both ltrace and LD_AUDIT need PLT indirection, but LD_AUDIT is probably the more important driver for us [16:47] Nick Alcock : /me hopes glibc is built with stack protection these days. people do seem to notice when it breaks, which is probably a good sign. OpenBSD has a per-segment per-thread canary which is something I've been meaning to look at in my copious spare time... [16:49] DJ Delorie : glibc supports -fstack-protector but it's not the "./configure" default. Distros can override if desired. [16:49] Nick Alcock : DJ: yeah I know, I did it :) [16:50] Florian Weimer : Nick, and thank you again for that. 8-) [16:50] Nick Alcock : (It was only not the default because I was being conservative. Should I submit a patch flipping that default?) [16:50] DJ Delorie : well then, your hopes have been achieved :-) [16:50] DJ Delorie : if we still support building with an old enough gcc that doesn't support it, I don't know if the default should be changed [16:51] DJ Delorie : Fedora enables it BTW [16:51] Nick Alcock : We check for GCC flag support and flip stack protection off if not supported. That won't change. [16:52] Nick Alcock : (And I'm not aware of supported GCC's in which the flag is present but broken, thank goodness.) [16:52] DJ Delorie : /me was thinking that too [16:53] Segher Boessenkool : things like =strong are relatively new [16:53] Nick Alcock : yeah, again we check for them before trying to use them [16:53] Nick Alcock : (i.e.we check for subflags, not just -fstack-protector as a whole.) [16:53] Segher Boessenkool : yup [16:54] DJ Delorie : distros know which compiler they're using, though [16:54] Segher Boessenkool : do they? [16:54] DJ Delorie : in general [16:54] Segher Boessenkool : :-) [16:54] DJ Delorie : enough to choose flags with more information than glibc's default has [16:55] Nick Alcock : Maybe the default should be =strong if available, else -fstack-protector, else none (I don't think turning =all on by default makes sense) [16:56] Segher Boessenkool : maybe it is best to by default use what the compiler uses by default? [16:56] Nick Desaulniers : Agree; not sure how many Clang tests are full integration tests to assembler; most tests compile to LLVM IR [16:56] Nick Desaulniers : (Agreeing w/ Serge's current point) [16:56] Nick Alcock : hm maybe? [16:57] Nick Alcock : I'll try to spin up a patch that does that, maybe this weekend [16:59] William Cohen : Is there some pointer to more info about the validation or checking with valgrind? [16:59] Serge Sans Paille : NickD : yeah, mosts LLVM tests are on LLVM IR [16:59] Sarah Cook : we can't hear you Ian [16:59] Ian Bearman : trying to correct audio Exploring PGO of Linux Kernel ----------------------------- This talk was postponed to 18:00 due to audio issues [17:00] Nick Desaulniers : (May need a browser restart) [17:00] Ian Bearman : i will try that [17:00] Elena Zannoni : do you have the right mic selected [17:00] Elena Zannoni : (that was my problem earlier) [17:02] Ian Bearman : get lots of server side errors. [17:02] Ian Bearman : trying to kill browswer and trying again [17:02] David Edelsohn : I received server errors earlier this morning. [17:04] Andrew Stubbs : I [17:04] Ian Bearman : i'm getting ICE connection failure 1007 [17:04] Andrew Stubbs : I tried desktop and android browsers, and both failed at the echo test stage [17:04] David Edelsohn : That's the same error that I received this morning. [17:04] Andrew Stubbs : eventually it worked [17:04] David Edelsohn : yes, eventually [17:05] Ian Bearman : i will keep try8ing [17:05] Elena Zannoni : are you on vpn? [17:05] Ian Bearman : no [17:05] Elena Zannoni : kill teh vpn [17:05] Elena Zannoni : ah ok [17:05] David Edelsohn : I wasn't using a VPN either. [17:05] Bill Schmidt : don't use the big RED button, that's for something else [17:05] Nick Desaulniers : proxies are causing people issues too [17:06] Frank Ch. Eigler : 102 users - maybe over a bbb limit ? [17:06] Frank Ch. Eigler : /me volunteers as tribute (to leave) [17:06] Elena Zannoni : not a limit no [17:06] Elena Zannoni : we had 140 yesterday w/o issues [17:06] Nick Alcock : this means that UDP connection negotiation failed, looks like. NAT may be to blame :( [17:06] Elena Zannoni : david sing? :-) [17:06] Ben Woodard : Can anyone sing [17:06] Nick Desaulniers : yea! [17:06] Bill Schmidt : @edelsohn can you whistle? [17:07] Mark Wielaard : Free Software Song anyone? :) [17:07] Peter%20Zijlstra : I can only join in audio mode; joiing with mic mode gets me that same ICE [17:07] Peter%20Zijlstra : listen mode, obv, typing hard [17:07] Jonathan Corbet : This is some sort of weird freeswitch failure mode [17:07] Ian Bearman : tyring repeatedly continuosly getting the same error [17:07] Frank Ch. Eigler : tried the hackrooms instead of this one? [17:07] Nick Alcock : yeah, this is networking I bet. Can you get UDP past your firewall at all? [17:07] Sedat Dilek : /me votes for lift music [17:07] Nick Desaulniers : (Maybe the MC leads can plan to reschedule this talk, worst case?) [17:08] Bill Schmidt : If only there were some technology for transporting sound from one place to another [17:08] Nick Alcock : YES [17:08] Gaius Mulley : loud and clear [17:09] Rustam Kovhaev : no [17:09] Ian Bearman : audio is now brokenm both ways [17:09] Francesco Gualazzi : nope [17:09] Frank Ch. Eigler : there is only zuul [17:09] Will Schmidt : cassette tape + trebuchet ? :-) [17:10] Patrick McGehearty : I see David's lips moving but no sound. [17:10] David Edelsohn : Everyone lost audio? [17:10] Elena Zannoni : i can hear fine [17:10] Sarah Cook : I can hear you David [17:10] Kevin Buettner : move ian's talk to the end [17:10] David Malcolm : I can hear David OK [17:10] Mark Wielaard : I can hear both David and Jose [17:10] Patrick McGehearty : Problem was on my end. [17:10] Nick Desaulniers : yes [17:10] Francesco Gualazzi : yes [17:10] Mark Wielaard : And Ian! [17:10] Patrick McGehearty : yes [17:10] Sedat Dilek : I hear voices [17:10] Ian Bearman : just died again [17:10] Mark Wielaard : drat [17:10] Kevin Buettner : sounds good [17:11] Nick Desaulniers : I'll bet his NAT is shutting him down. Ian, any chance to switch to 4G? [17:11] Sarah Cook : Ian, are you happy talking after Jose's talk? [17:11] Ian Bearman : I can try using 4G yes [17:11] Ian Bearman : yes i can do 9:30 [17:11] Ben Woodard : more GNU BOF [17:11] Elena Zannoni : i can offer a (sigh) zoom connection maybe for Ian [17:11] Mark Wielaard : food [17:11] Catherine Moore : yes take a break [17:11] Nick Desaulniers : 4G audio only might work [17:11] Sedat Dilek : /me break for a tea [17:11] Sarah Cook : well, you would talk at 10 Ian [17:11] DJ Delorie : break [17:12] Ian Bearman : 10 works as well [17:12] Nick Desaulniers : tea? What happened to beers? [17:12] Lucas Alexandre Mello Magalhães : break [17:12] Sarah Cook : Perfect Ian [17:12] Kevin Buettner : break [17:12] Nick Desaulniers : too early I suppose [17:12] James LaBarre : I can make my daughter's lunch then [17:12] Jason Merrill : break 👍 [17:12] Tobias Burnus : /me prefers a tea as well ;-) [17:12] Jeremy Bennett : Let's take a break for 18 minutes [17:12] Sedat Dilek : 6 p.m. here [17:13] Daniel Axtens : hah, 215am here! [17:13] Ben Woodard : Daniel where are you? [17:13] Nick Desaulniers : FWIW, I wrote an ICE implementation (in JS). NATs kind of suck [17:14] Sedat Dilek : @Daniel hehe time for a tea or coffee [17:14] Daniel Axtens : Canberra, Australia [17:15] Elena Zannoni : i will adjust the schedule so the meet page will reflect th [17:15] Sarah Cook : Thank you Elena [17:16] Elena Zannoni : ok schedule adjusted [17:17] Elena Zannoni : the meet front page refreshes every 10 minutes [17:17] Sedat Dilek : 16:55 UTC ? [17:18] Elena Zannoni : 17:00 [17:18] Elena Zannoni : of course the meet page rereshed before i added the 5 minute break in between [17:18] Elena Zannoni : because it's 2020 [17:20] Sedat Dilek : at the beginning of 2020 I had sort of euphoria - new decade [17:21] Elena Zannoni : me too! it could not possibly be worse than 2019 [17:21] Jose E. Marchesi : just wait for 2021... [17:23] Tim Ruehsen : There will be no 2021 possibly ;-) [17:24] Elena Zannoni : maybe chinese astrology can tell us what 2021 will be like? [17:24] Jose E. Marchesi : The year of the pangolin [17:25] Segher Boessenkool : the world has ended in 2012, says the long count calendar [17:25] Jose E. Marchesi : hey, we won't need time64_t after all [17:25] Jose E. Marchesi : hurrah [17:26] Sedat Dilek : /me looks into crystall ball [17:27] Sedat Dilek : @Elena I guees it is the year of the GNU? [17:27] Tim Ruehsen : Metal GNU Update on BPF support --------------------- [17:33] Tobias Burnus : /me now keeps loosing audio. [17:36] Jonathan Corbet : "Kernel contexts" means different BPF program types? [17:38] Daniel Xu : eeBPF ;) [17:48] Jim Wilson : dbxout has bitrotted and should be dropped [17:50] Nick Alcock : i.e. many debugging formats need only a subset of what DWARF generates [17:50] David Edelsohn : xcoffout still depends on dbxout. AIX finally is transitioning further away from DBX to DWARF. XL compiler using LLVM technology will not provide DBX debugging. [17:51] Mark Wielaard : line tables, type information, program ranges, ... [17:52] Nick Alcock : (I benchmarked this. Generating *and deduplicating* CTF is faster than just generating DWARF, even in the absence of disk I/O overhead. I'd like to not lose that.) [17:52] Ian Bearman : is there a concern about using DWARF as an intermediate format if it cannot represent information in an output format? [17:52] Nick Alcock : (Because it's way smaller and more limited and doesn't need to generate or represent as much.) [17:52] William Cohen : How is this gcc debuginfo tracking going to work for targets that might not be well represented in dwarf such as the GPU code? [17:53] Nick Alcock : I think the assumption is that DWARF would have to be extended first. Not sure what this means for debug format flexibility / speed of development [17:53] Mark Wielaard : Ian, right, the assumption is that DWARF covers everything you would ever want. But we probably don't know yet some things we might want :) [17:55] Mark Wielaard : grin, so now BPF is not just taking over all of the kernel, but also all of userspace :) [17:55] Josh Stone : could you just invent DWARF extensions in your intermediate representation to cover gaps? [17:55] Nick Alcock : anything that makes Infinity easier to use is great, IMHO [17:57] Mark Wielaard : This is how things started last time too... [18:00] William Cohen : Is it possible to post the slides on https://linuxplumbersconf.org/event/7/contributions/771/ as pdf? Fedora 32 libreoffice is doing a very poor job rendering the .pptx file. Exploring PGO of Linux Kernel ----------------------------- This talk was postponed from 17:00. [18:00] William Cohen : Thank. [18:01] Serhei Makarov : Wonder if the xBPF extensions are enough to overcome the irritating design problems in BPF bytecode .. [18:01] Serhei Makarov : I'll be interested to look at it in detail again [18:02] Jose E. Marchesi : @Serhei: it is very open [18:02] Jose E. Marchesi : basically whatever allows us to support more C [18:03] Jose E. Marchesi : like, removing maximum size of stack frame [18:05] Serhei Makarov : We have a (extremely) rudimentary user-space BPF interpreter as part of SystemTap's BPF backend. Not caring about performance allowed us to implement it very quickly :) [18:05] Jose E. Marchesi : is it small, portable, pure C? [18:05] Serhei Makarov : Alas no. [18:06] Serhei Makarov : If a libxbpf interpreter does get implemented I would look at whether we can use it [18:06] Jose E. Marchesi : We need something you could use in, say, GDB so it can execute BPF programs embedded in ELF notes [18:06] Jose E. Marchesi : sorta client library like libi8x [18:08] Serhei Makarov : Some questions about what the 'map' interface would look like [18:08] Serhei Makarov : For our use case, we implement the BPF map helpers by wrapping all the corresponding bpf syscalls to access/modify actual kernel maps [18:09] Serhei Makarov : Which fits because these userspace BPF programs are meant to process data collected by kernel BPF programs [18:09] Michael Meissner : One thing to note about PGO and Spec is one of the benchmarks uses a non-representative trial run, which tends to make PGO get slower than without PGO. Basically, GIGO (garbage in, garbage out). You want the training date to mirror the eventual usage. [18:10] Jose E. Marchesi : @Serhei makes sene [18:10] Jose E. Marchesi : *sense [18:11] Nick Alcock : (Or clear the profile data after doing the build, which might be easier.) [18:14] William Cohen : Is it possible to get the pgo profile data without the kernel config instrumentation settings using perf? Is there some way to combine data from separate multiple runs? [18:14] Serhei Makarov : @Jose E. Marchesi For embedding into another application like GDB, would plausibly even want to implement some completely different set of helpers... which introduces the concept of BPF helper ABIs... [18:15] qing zhao : which optimization level the PGO-5.3 used? [18:19] Jose E. Marchesi : @Serhei In my mind helpers are basically trap/syscall instructions that just happen to look like amorphous call instructions :) [18:19] Alex Coplan : Did you report the ICE that you ran into with PGO on AArch64? [18:21] Michael Meissner : In the Spec case, there is a specific training data to use, and as I said it is not representative of the real run. I have tried to get the Spec committee to fix this. [18:21] Jakub Jelínek : one issue with PGO is apps that choose different code at runtime based on hw capabilities of the machine it is run on (ifuncs, function multiversioning, ...) [18:22] Joe Mario : When a developer makes an edit to a source file in the Window's kernel, do you reject all the profile info for that file? Or do you look to see what changed in the source, adjust your profile data for it, and then still use what profile info that you can? [18:22] Jakub Jelínek : if such apps are trained on one hw and then run on another one, many hot functions might look to be totally cold [18:22] Alex Coplan : Please submit a PR if possible :) [18:23] Nick Desaulniers : s/PR/patch/ [18:23] Nick Desaulniers : or patch [18:24] Mark Wielaard : So is it pronounced POGO or 'P' 'G' 'O'? [18:25] Bill Schmidt : I worked on similar work for the IBM System i operating system back in the late 1990s. :-) https://ieeexplore.ieee.org/document/5387153 [18:26] Nick Desaulniers : "merging" profile data can help a little with Jakub's point [18:26] Bill Schmidt : yes [18:27] Bill Schmidt : we used a weighted profile of many workloads for profiling the OS [18:27] Joe Mario : Thanks Ian. Great work. [18:27] Ian Bearman : thanks everyone for attending! [18:27] Bill Schmidt : Thanks, Ian! [18:28] Sedat Dilek : thanks for your PGO talk [18:28] Jose E. Marchesi : Thanks David [18:28] Elena Zannoni : thank you all, notes will be up [18:28] Rustam Kovhaev : tyvm [18:28] Sarah Cook : Thanks everyone! [18:28] Gaius Mulley : thanks David [18:28] Jeremy Bennett : Thank you David [18:28] Ian Bearman : yes, thanks David [18:28] Jeremy Bennett : I shall save the chat for uploading