GNU Tools @ LPC Monday 24 Aug 2020: chat record =============================================== All times are US Mountain time Pre-start --------- [07:07] Jose E. Marchesi : foo :) [07:24] Simon Marchi : https://meet.2020.linuxplumbersconf.org/ [07:45] Simon Marchi : https://chat.2020.linuxplumbersconf.org/channel/gnu-tools-track [07:50] Simon Marchi : Proposed topics so far: [07:50] Simon Marchi : - the moving of gdbsupport and gdbserver to top-level - conversions from accessor macros to more C++-like APIs (e.g. struct type) - reducing reliance on global state (e.g the proposed xfer_partial change) - feedback on the new version numbering scheme - other large changes that people would like to pre-announce, new architectures? - questions from new / future contributors [07:50] Simon Marchi : Anything else I should add? [07:51] Jeremy Bennett : Variant on the first topic, FreeBSD version of the gdbserver application [07:52] Jeremy Bennett : (or any *BSD) [07:52] Guy Lunardi : Adding the live stream user now. It will not stream until the top of the hour [07:52] Jeremy Bennett : Thanks Guy [07:52] YouTube Live : This meeting is streaming live on YouTube [07:52] Simon Marchi : Jeremy: Ack [07:52] Guy Lunardi : (back in a bit) [07:53] Guy Lunardi : Thanks for using the slide template by the way ! :-) [07:53] Simon Marchi : Jeremy, just not sure how this relates to the first topic [07:53] Simon Marchi : Oh well, it's related to gdbserver at least [07:54] Jeremy Bennett : It was more to flag up that gdbserver on FreeBSD broke sometime between 2005 an now. We've started work on resurrecting it, but not yet finished that work. Interested to know if anyone else is looking at this. [07:55] Simon Marchi : I want to know more about it, I've added it to the list :) GDB BoF ------- [08:01] Tom de Vries : yep [08:01] David Malcolm : yes [08:01] Christian Biesinger : sound is great [08:01] Jeremy Bennett : Yes [08:01] Kevin Buettner : sound is good! [08:02] Pedro Alves : I hear you fine. And I see your halo! [08:03] Catherine Moore : not for me - ICE when trying to connect [08:03] Carlos O'Donell : Good morning! [08:03] Carlos O'Donell : Yay! GNU Tools! [08:03] 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. [08:06] Carlos O'Donell : Should we align glibc release numbers? binutils release numbers? --- Question for the steering committee? [08:07] Elena Zannoni : anybody taking notes? [08:09] Elena Zannoni : thanks! [08:12] Kevin Buettner : There is an old project called RDA [08:13] Frank Ch. Eigler : there is also the multi-client gdbserver extensions via scox@redhat.com [08:13] Kevin Buettner : https://sourceware.org/rda/ [08:22] Mark Wielaard : The valgrind gdbserver implementation is a hacked up copy lifted from GDB a long time ago [08:24] Mark Wielaard : We could upgrade valgrind to GPLv3 but that is work :) [08:25] Mark Wielaard : I think the real reason it isn't synced/upgraded is that it is actual work, and the current code works [08:25] Sarah Cook : Hackroom2 is open if people want to carry on this BoF [08:26] Kevin Buettner : How do we get to the hackroom? [08:26] Christian Biesinger : https://meet.2020.linuxplumbersconf.org/hackrooms [08:27] Elena Zannoni : first come first serve for the hackrooms, just grab one that is empty DWARF5/DWARF64 BoF ------------------ [08:33] Ben Woodard : Have you looked at many fortran codes? [08:35] Ben Woodard : Can location-views at least the idea be one of the topics for DWARF6? [08:37] Jeremy Bennett : I don't propose taking notes for any sessions other than BoFs. The other sessions stand on their slides and recordings. [08:37] Elena Zannoni : agreed [08:45] Jan Kratochvil : It is emitted by clang per-CU. Merging would be implemented in lld but that has not been done yet, currently LLDB reads separate .debug_names in each CU. [08:48] Mark Wielaard : Thanks jan [08:52] Joseph Myers : 64-bit DWARF was used by MIPS n64, but I stopped it doing so in 2006. [08:53] Joseph Myers : https://gcc.gnu.org/legacy-ml/gcc-patches/2006-05/msg00142.html [08:53] Pedro Alves : GDB assumes 32-bit offsets in a number of places. It'll need to be fixed too, hopefully not doubling the size of heavily allocated structures. :-) [08:54] Nick Clifton : Mark: Your BFD patch is now in. :-) [08:54] Carlos O'Donell : /me ^5's Nick [08:54] Joseph Myers : I fixed a few bugs relating to 64-bit DWARF before stopping MIPS using it. [08:54] Jan Kratochvil : That is -fdebug-types-section, not -fdebug-types. [08:55] Sarah Cook : To carry on this conversation, I would either join Hackroom 2 or Hackroom 3, if you want to keep it a seperate topic [08:57] Jose E. Marchesi : Thanks mark! [08:59] Mark Wielaard : Grin. I fogot to look what was behind me. Hope nothing embarrassing :) Lightning talk: debuginfod update --------------------------------- [09:03] Ben Woodard : Only if book's are embarrassing. You had quite a few bookshelves behind you. [09:03] Pedro Alves : You can always say it was an overlay, nowdays. ;-) [09:04] Carlos O'Donell : Q: What if you are debugging an application that is from an ISV that provides their own debuginfod server? How do you merge that with the distro debuginfod? [09:05] Jeff Bastian : Does this complement or replace ABRT Retrace Server? [09:05] Peter Jones : why make client support be a thing instead of making /usr/lib/debug and /usr/src/debug a fuse mount with a limited tmpfs cache? [09:05] Peter Jones : (wwoods and I did this in 2008 ;) [09:06] Serhei Makarov : Carlos, if I understand correctly, DEBUGINFOD_URLS environment variable is configured with a list of servers in priority order, similar to PATH [09:06] Carlos O'Donell : Thanks Serhei. [09:06] Carlos O'Donell : Peter, Couldn't the FUSE-based cache just use debuginfod API in the background? [09:07] Frank Ch. Eigler : yes [09:07] Peter Jones : Not sure - haven't seen what the API looks like [09:07] David Malcolm : yes [09:07] Simon Marchi : 3 minutes left [09:07] Carlos O'Donell : David, "Yes" to me? :-) [09:07] Masami Hiramatsu : Maybe debuginfod is also good for the embedded devices. Can the server provide different architecture debuginfo too? [09:07] Frank Ch. Eigler : hi Masami, debuginfod is arch-independent [09:08] David Malcolm : Carlos: the yes was in response to Aaron's "can you hear me", sorry [09:08] Peter Jones : What do the http requests look like? [09:08] Masami Hiramatsu : Hi Frank: thanks! I'll try to test it. :D [09:09] Frank Ch. Eigler : https://www.mankier.com/8/debuginfod <<< peter jones, simple GET [09:09] Peter Jones : I don't see an actual URL example there? [09:10] Frank Ch. Eigler : see the "Webapi" section [09:10] Frank Ch. Eigler : /buildid/HEXCODE/debuginfo e.g. [09:10] Peter Jones : the path is the important part here - "buildid" doesn't tell me enough, which object am I getting back? [09:10] Peter Jones : okay [09:10] Elena Zannoni : can you make the font bigger [09:10] Elena Zannoni : for the live stream [09:10] Elena Zannoni : it's hard to see [09:11] Elena Zannoni : yes [09:12] Carlos O'Donell : Time is up! Good demo! :-) [09:13] Aaron Merey : thanks everyone [09:13] Mark Wielaard : Petr Jones actual example: https://debuginfod.elfutils.org/buildid/103458ac4c57ac65aeb534d78bf2fe090a9f0027/debuginfo [09:13] Mark Wielaard : the last part of the "part" tell you the object type, in this case "debuginfo" [09:14] Mark Wielaard : change to "executable" to get the exectuable [09:14] Carlos O'Donell : Please wait. [09:14] Mark Wielaard : change to source./plus/path to get a particular source that belongs to the buildid given [09:14] Elena Zannoni : i am periodically saving the notes and the chat, just in case.... Lightning talk: Debugging native Java ------------------------------------- [09:19] Frank Ch. Eigler : hmmm debuginfod can probably handle src.jar files [09:21] Andrea Corallo : :D [09:23] Frank Ch. Eigler : heh, just tested, can do... so maybe that source cache is not as needed as before [09:24] Jeremy Bennett : The notes from the two BoFs are now on the GNU wiki: https://gcc.gnu.org/wiki/linuxplumbers2020 [09:25] Pedro Alves : Clap, clap! [09:25] Nick Alcock : Using unions to model interfaces is crazy brilliant [09:26] Nick Alcock : (Would only work in a closed world, of course) [09:26] Elena Zannoni : FYI 24 people watching the live stream of this session [09:26] Jeremy Bennett : Thanks @Elena [09:27] Pedro Alves : gdb commit that removed gcj support: 9c37b5aed98e5996a9777a366bfcc371c0e1a92d [09:27] Jose E. Marchesi : pedro: revert! [09:27] Pedro Alves : done! [09:27] Pedro Alves : kidding. [09:27] Jose E. Marchesi : :( [09:27] Frank Ch. Eigler : thanks Jeremy, nice job :) [09:27] Jose E. Marchesi : no sound [09:28] Nick Alcock : for a moment I read one slide as suggesting that emacs was now written in java :) [09:28] Simon Marchi : Joel, you are muted! [09:28] Simon Marchi : You were The Lightweight JIT Compiler Project ------------------------------------ [09:44] Jose E. Marchesi : oooh [09:48] Andrew Dinn : Nick Alcock, careful or you will be giving Tom Tromey ideas! [09:49] Nick Alcock : yeah, obviously writing the jvm in gccjit'ed elisp is the right idea [09:49] Andrew Dinn : ;-> [09:51] Nick Alcock : wow! talk about burying the lede [09:53] Elena Zannoni : Jamie you are generating echo please mute [09:53] Elena Zannoni : thanks [09:54] Jamie Lokier : Elena, thanks. Switching to headphones. [09:54] Jamie Lokier : I was counting on good echo cancellation but we can dream :-) [09:56] Elena Zannoni : yeah i gave up, had same problem, and using headset now [09:57] Pedro Alves : couldn't the startup slowness be mitigated with keeping a gcc loaded and reusing it? [09:57] Jason Merrill : the modules support ought to work as the basis for a new PCH implementation [09:58] Jason Merrill : I remember someone working on a gcc server long ago, maybe Per Bothner? [09:58] Jeff Law : pedro -- compile servers as an idea keep coming bak [09:58] Serhei Makarov : Pedro, I last heard of that idea in the context of JVM world [09:59] Pedro Alves : I think Tromey worked on that before switching to gdb. [09:59] Jeff Law : I did one nearly 30 years ago, but I wouldn't want to do it again [09:59] Pedro Alves : the incremental compile / server thing. [09:59] Jeff Law : yea, I think that's dead [09:59] Pedro Alves : for sure :-) Project Ranger update --------------------- [10:00] Pedro Alves : but I had the impression that libgccjit was already reusing a single gcc project for several compilatins. [10:01] Pedro Alves : err, s/project/process/ [10:02] David Malcolm : Pedro: libgccjit supports multiple in-memory compilations within a single process (with a big mutex guarding the heart of the GCC compiler code) [10:03] Pedro Alves : so that mitigates the startup slowness, right? the remaining big slowness would be the launching gas as a separate process. [10:04] David Malcolm : Pedro: sadly no, it has to do the startup each time :( [10:05] Jamie Lokier : David, I guess you could "pre-startup" though? Like a web server process preloads everything it needs before offering its services - so the startup latency is hidden. [10:05] Ian Rogers : There some interesting discussion on implementing JavaScript JITs using LLVM for WebKit and then being motivated to handle write a JIT: https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ [10:08] David Malcolm : Jamie: interesting idea, but I fear it could significantly complicated things (long time no see, BTW). Might be better to simply make the startup be faster [10:09] Jamie Lokier : W.r.t. gas, I always felt a project to parse & analyse the text fragments in GCC machine descriptions, in conjunction with GAS's parser, to make a direct binary emitter, would be a fun challenge, tricky but feasible. I doubt it would make enough difference to be worth the effort, given all the other slow phases. [10:09] Jamie Lokier : David, ditto long time no see :-) Never could make an LPC conference before, it's nice to participate in one after all these years. [10:10] Jeff Law : jamie; we've considered that from time to time, but there just isn't enough to be gained to make it a high priority [10:13] Jamie Lokier : Pre-startup is way less work than speeding up real startup, because fork() is very good for this sort of thing. It may actually improve throughput too for bulk compiles with a compile server: Once you've produced a program state you can cache and clone it quickly. [10:13] Joseph Myers : From memory, there were once hot spots in debug info emission via text assembly (that analysis was for STABS output around 2004, but it wouldn't surprise me if the cost of debug info via text is still significant for DWARF in 2020). But that's no so relevant for JIT. [10:26] Carlos O'Donell : Tap dance please. [10:27] Carlos O'Donell : ;-) [10:29] Pedro Alves : will this fix "-Wmaybe-uninitialized" ? :-D [10:29] Pedro Alves : aka "but will it blend?" GNU Poke tutorial ----------------- [10:30] Andrew MacLeod : we can make it fix lots of things.. just need the requirements :-) [10:30] Andrew MacLeod : i forgot my tapdance shoes [10:30] Carlos O'Donell : Screen sharing is working! Font is good size. [10:30] Elena Zannoni : let me check the stream, maybe a bigger font [10:30] Jeremy Bennett : Possibly larger font for streaming users [10:31] Jamie Lokier : No screen sharing for me, unless rotating arrows are the screen. [10:31] Jamie Lokier : Ah, fixed now. [10:31] Elena Zannoni : yes needs to be a bit bigger [10:32] Elena Zannoni : i can read ok in the stream [10:32] Jamie Lokier : Blurry fonts remind us of Linux console in the 90s on a cheap CRT. Nostalgic. [10:32] Cengiz Can : Hello @Jose [10:33] Cengiz Can : I was there in Paris [10:33] Kevin Buettner : I took a quick look at the youtube stream. Looked fine to me. [10:35] Mark Wielaard : The youtube link https://www.youtube.com/watch?v=mMwC0QenvcA says: Your browser does not currently recognize any of the video formats available. [10:36] Nick Alcock : it probably requires vp9+opus or mp4+aac [10:36] Kevin Buettner : That link works for me. [10:36] Nick Alcock : (er, h.264+aac) [10:36] Elena Zannoni : yes, you need to use Chrome [10:37] Mark Wielaard : bleah, well I don't need it, I can see Jose here :) [10:37] Elena Zannoni : it was the only way to have good quality for lots of people watching, somebody checked with youtube [10:38] Florian Weimer : It works with Firefox too under Debian. It's the Fedora codec thing, I assume. [10:40] Tobias Burnus : It shows "Codecs: avc1.4d401f (135) / mp4a.40.2 (140)" here under Firefox. [10:42] Elena Zannoni : we are using H.264 and AAC to YouTube. (mp4 1920x1080 HLS 6000k , avc1.4d4028, 30.0fps, mp4a.40.2@256k to be precise) [10:45] Elena Zannoni : only for live streaming, everything else is free codecs [10:51] Nick Alcock : commonplace in .a archives :) [10:58] Mark Wielaard : heay there is a dwarf.pk but it doesn't load [10:59] Pedro Alves : ah, I was wondering whether there's a dwarf pk file! [10:59] Mark Wielaard : It is in the directory future [11:00] Mark Wielaard : I wonder if that directory name is trying to tell me something [11:00] Pedro Alves : "I'll be back!" ? [11:00] Mark Wielaard : haha [11:01] Ben Woodard : Yeah one thing that we would like to do is rewrite paths like rpaths in ELF files [11:02] Nick Alcock : hmm, length changes (if you make rapths longer) are *hard* [11:02] Nick Alcock : rpaths, I mean [11:02] Ben Woodard : That is one of the problems. [11:02] Pedro Alves : maybe that could be hacked into dwz. [11:02] Nick Alcock : I'm sure poke can do non-growing fixups now [11:04] Nick Alcock : needs a new libvte no doubt [11:04] Mark Wielaard : I wonder if we should simply always add some zero space at the end of .dynamic and .dynstr to make things like rpath editing simpler [11:06] Jamie Lokier : I'm curious about the "app:" protocol. [11:06] Jamie Lokier : If that's what the terminal's link URL contains, I mean. [11:06] Nick Alcock : "send stuff over a socket", looks like. no security implications *there* :) [11:06] Ben Woodard : Considering the size of DWARF a few extra bytes probably wouldn't hurt much. [11:07] Jamie Lokier : Nick, if it were to send it over the terminal as an escape sequence (simulated keyboard) that would be handy. [11:07] Nick Alcock : /me wonders why he's trying to shave individual bytes off ctf if people say that :) [11:08] Ben Woodard : Can poke dump text into assembly and allow you to edit the assembly? [11:08] William Cohen : mark wielaard. I have a friend that has found ISV provided software needed to have the rpath edited and the limited space can cause problems. [11:09] Nick Alcock : Jamie: simulated keyboard would be really good. works over ssh etc [11:10] Carlos O'Donell : @William Cohen, We could pad .dynamic to give space for DT_RPATH/DT_RUNPATH editing. We've just never done that. [11:10] Peter Jones : We also have similar issues in a lot of places with the debuginfo source file paths [11:10] Mark Wielaard : https://blogs.oracle.com/solaris/changing-elf-runpaths-code-included-v2 [11:10] Ben Woodard : WRT padding - most of the time we need at most a few hundred bytes. [11:12] Mark Wielaard : So what they do on solaris is add 512 extra bytes at the end of the dynstr and have a new dynamic STRPAD that tells you how much padding you have to work with [11:12] Peter Jones : Am I the only person who thinks that's unbelievably hacky? [11:13] Nick Alcock : (plus, new dynamic means ld.so changes, doesn't it? :/ ) [11:13] Ben Woodard : @peter jones real life is messy [11:13] Peter Jones : I am well aware ;) [11:14] Peter Jones : nick: does it? seems like the consumer can just ignore it [11:14] Mark Wielaard : It is a hack, but imho better than nothing. [11:14] Nick Alcock : vague memory,could well be wrong [11:14] Carlos O'Donell : @Peter Jones, It is a terrible idea. We should avoid modifying files. [11:14] Pedro Alves : If only we had a DWARF rewriter *cough*dwz*cough. [11:14] Ben Woodard : It would also be GREAT if poke could digest the DWARF [11:15] Nick Alcock : happening in the future/ :) [11:16] Peter Jones : But also the solaris impl above requires that any future /better/ solutions know how to adjust the hack version, or carefully avoid needing to do so. [11:16] Carlos O'Donell : @Peter Jones, You want something that is additive and modularly allows you to specify where to lookup libraries. Something we've talked to Ben Woodard about. [11:16] Carlos O'Donell : @Peter Jones, Like an ENV VAR that specifies a transformation to take. [11:17] Mark Wielaard : carlos, Since this is a talk about poke I think modifying files is kind of what everything is about :) [11:17] Peter Jones : @Carlos O'Donell do you mean when the toolchain is creating it? [11:17] Carlos O'Donell : @Mark Wielaard, Not at all. Poke can be used to validate data files indepenent of implementations e.g. glibc testing compiled locales have certain fields set correctly. [11:18] Carlos O'Donell : @Mark Wielaard, That is my ideal use of poke. [11:18] Mark Wielaard : grin, you want GNU Peek [11:18] Serhei Makarov : @William Cohen, Carlos O'Donell editing rpath also came up as a potential hack in some of my container-injection work (to install an executable into a non-standard path inside a remote container) [11:18] Peter Jones : A+ [11:18] Serhei Makarov : for what it's worth [11:19] Carlos O'Donell : @Serhei Makarov, Keep me in the loop for those questions. I've love to know them and add them to the backlog of things we might support. [11:19] Carlos O'Donell : @Peter Jones, Who was that A+ for??? :-) [11:19] Carlos O'Donell : /me wants to earn that. [11:19] Peter Jones : @Carlos O'Donell that was for Mark :) [11:19] Carlos O'Donell : :/ [11:19] Mark Wielaard : Not saying there could be nicer ways than hacking/poking at the dynamic structure. [11:20] Peter Jones : @Mark Weilaard sure, but what Poke presents here is a language for implementing such tools [11:20] Nick Alcock : peek-in-memory seems like a nice way to do what lib*_db currently do (nicer than probes, IMHO) [11:20] Carlos O'Donell : Correct, and you can use GNU Poke to implement a "Peek" or RO view of data for independent validation. [11:21] Carlos O'Donell : @Nick Alcock, Yes. [11:21] Nick Alcock : (o rrather peek-in-other-process's-memory) [11:21] Carlos O'Donell : @Nick Alcock, But you'd have to embed the Poke program *in* the libthread.so. [11:21] Mark Wielaard : nick, yes! lets add a ptrace layer over poke! [11:22] Nick Alcock : thi sort of thing is why the i/obackend is pluggable :) [11:22] Nick Alcock : (argh, this keyboard...) [11:22] Peter Jones : @Carlos O'Donnell ah, but I actually *have* that use case for Peek, because our EFI binaries are PE wrapped around ELF DSOs, with ELF relocate() as the entry point. [11:23] Carlos O'Donell : @Nick Alcock, https://infinitynotes.org/wiki/Infinity, Infinity uses DWARF-ish to do what you suggest... but GNU Poke might be farther along in some sense. [11:23] Nick Alcock : Jose has ideas there too :) [11:24] Carlos O'Donell : @Nick Alcock, Jose has lots of ideas :-) [11:24] Serhei Makarov : Carlos, if I understand my own notes correctly at https://github.com/serhei/oc-inject/issues/4 , I currently use LD_LIBRARY_PATH which has some 'considered harmful' issues (in my case, if the process spawns a subprocess, the nonstandard LD_LIBRARY_PATH is inherited). I think even a fixed size padding will work since I install to a path of my choice in /tmp -- but it's guaranteed to be longer than /usr/lib. Ugh, or I could just use three-letter folders inside of tmp :) [11:28] Carlos O'Donell : @Serhei Makarov, We should discuss offline, I don't quite understand your use case. I like what I see with oc-inject. Send me email? [11:29] Serhei Makarov : sure [11:29] Florian Weimer : Please Cc: me, Serhei. I might have a solution in the queue already. [11:32] Carlos O'Donell : Yay! elfextractor! [11:32] Carlos O'Donell : /me claps [11:32] Mark Wielaard : I have to drop out, sorry. [11:32] Joel Brobecker : We're giving Jose a couple more minutes to close and then we will take questions. [11:33] Nick Alcock : why can't we use this in bfd (oh wait, dependencies) [11:33] Carlos O'Donell : Why can't you use libelf? [11:33] Carlos O'Donell : I've written many small programs like this that use libelf. [11:33] Nick Alcock : poke gives you libanything :) [11:34] Carlos O'Donell : libstar [11:36] Carlos O'Donell : See everyone tomorrow! [11:37] Tim Ruehsen : CU at next Poke conf, Jose. Awesome work ! [11:38] Ben Woodard : Can poke disassemble program text and allow you to edit the assembly? [11:39] Pedro Alves : tcl! [11:42] Nick Alcock : I'im imagining a pickle for x86 asm and I don't think it's tiredness that's making me feel ill [11:45] Gaius Mulley : bye [11:46] Pedro Alves : see you in the lobby :-)