Re: build-ids, .debug_sup and other IDs (Was: [PATCH] Handle DWARF 5 separate debug sections)
Hi - > I'm concerned about using dwo IDs to index debuginfod. They are only > 64-bits and there will be many more dwo IDs than build ids or > supplemental file ids [...] AIUI, -gsplit-dwarf is more suitable for development/scratch builds than for distro binaries. If distros agree, then I would not expect .dwo files to show up in distro-wide debuginfod services, but rather within developers' own build trees. Then debuginfod indexing collisions would only be a risk within a particular local set of trees (if serviced by a local debuginfod), rather than distro wide or wider. > What about using `/buildid/BUILDID/dwp` instead? This is not a > perfect solution, since (currently) no one puts the build-id into > the *.dwp file, but it does get around this collision problem. The hypothetical problem is collision between dwo/dwp files, not between dwo/dwp and normal buildid dwarf files, right? In that case, are you talking about two levels of indexing (buildid of final linked binary + dwo_id)? That would resemble the indexing work required from debuginfod to match up binaries with their source files plus binaries with dwz supplemental files). - FChE
Re: build-ids, .debug_sup and other IDs (Was: [PATCH] Handle DWARF 5 separate debug sections)
Thanks for the thoughts! > AIUI, -gsplit-dwarf is more suitable for development/scratch builds > than for distro binaries. If distros agree, then I would not expect > .dwo files to show up in distro-wide debuginfod services, but rather > within developers' own build trees. That's a good point. My concerns are only valid if distros decide to start building packages using -gsplit-dwarf and dwp to package up the .dwo files into one .dwp file. I also agree that split dwarfs (split dwarves?) are more suitable for local builds than for distro builds. The one advantage I can think of that split dwarfs offer distro binaries is a faster build for larger packages (since dwp does not do all the relocations the linker would normally do). But I don't know enough about building packages to say what will happen in the future. > The hypothetical problem is collision between dwo/dwp files, not > between dwo/dwp and normal buildid dwarf files, right? That's correct. > In that case, are you talking about two levels of indexing (buildid > of final linked binary + dwo_id)? I was suggesting one level of indexing. The buildid of the final linked binary would be used to reference the dwp file directly. This solution would not work for individual dwo files. For individual dwo files we could still use the dwo_id as they should only be for local builds. -Matt
[Bug debuginfod/27982] New: debuginfod client maximum-transfer-size and -time parameters
https://sourceware.org/bugzilla/show_bug.cgi?id=27982 Bug ID: 27982 Summary: debuginfod client maximum-transfer-size and -time parameters Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- DEBUGINFOD_TIMEOUT is a good way to catch servers that are too slow to *start* transmitting a file. But we have no way of limiting total download time or space. A user might prefer to have his debugger fetch only quick & small files, and make do without the bigger ones. Some transitive dependencies of e.g. gnome programs are huge: 3GB of LLVM debuginfo, 1GB of webkitgtk, etc. etc. We could add a $DEBUGINFOD_MAXSIZE and/or $DEBUGINFOD_MAXTIME parameters to the client side environment variable suite. The MAXSIZE one could be communicated to the server in the query as an extra header, so it can quickly respond with some HTTP error code (since it can generally find out the destination file sizes prior to actually decompressing them); it can also be enforced during download, as soon as a Content-Length: header is received. The MAXTIME one could be added as a debuginfod-client.c main loop parameter. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/27983] New: debuginfod client should eliminate duplicate outgoing server urls
https://sourceware.org/bugzilla/show_bug.cgi?id=27983 Bug ID: 27983 Summary: debuginfod client should eliminate duplicate outgoing server urls Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Gazing at server logs, one sees a minority of clients who appear to have duplicate query traffic coming in: the same URL, milliseconds apart. Chances are the user accidentally doubled her $DEBUGINFOD_URLS somehow, and the client library is dutifully asking the servers TWICE. Bug #27863 reduces the pain on the servers' CPU, but dupe network traffic is still being paid. We should reject sending outright duplicate concurrent traffic. -- You are receiving this mail because: You are on the CC list for the bug.
