https://sourceware.org/bugzilla/show_bug.cgi?id=31504 --- Comment #8 from Mark Wielaard <mark at klomp dot org> --- (In reply to Allan McRae from comment #7) > > What I don't fully understand is why you are expecting debugedit to NOT change > > the debug path strings when you are asking it to. Is this because there file > > don't actually contain any .debug sections? > > I don't expect that. I expect debugedit/libelf to not truncate the extra > data that is tagged on to the ELF file. I am sorry, but it will if it needs to change the ELF data because it has no way of knowing what to do with this "extra data" since it isn't described in the ELF header, program or section tables. So when the debug path strings change and the section data becomes bigger or smaller things will move around. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31504 --- Comment #7 from Allan McRae <allan at archlinux dot org> --- > What I don't fully understand is why you are expecting debugedit to NOT change > the debug path strings when you are asking it to. Is this because there file > don't actually contain any .debug sections? I don't expect that. I expect debugedit/libelf to not truncate the extra data that is tagged on to the ELF file. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31504 Mark Wielaard <mark at klomp dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|ASSIGNED |RESOLVED --- Comment #6 from Mark Wielaard <mark at klomp dot org> --- (In reply to Allan McRae from comment #5) > > I can add a check to see if there actually were any changes and if there aren't simply not call elf_update at all. But I suspect that is really a corner case that doesn't occur that often. At least why would you call debugedit explicitly asking to rewrite things and then expect it to not actually do that? > > Our packaging system checks for ELF files and tries generating associated > debug packages with source files and debug symbols. It turns out there are > a lot of packages that provide a .NET 8.0 self-contained/ single-file > application, which is and ELF file and did not enjoy being processed by > debugedit. I understand that. And I think these aren't really "ELF" files because they add something to the file that isn't described by the ELF structures. What I don't fully understand is why you are expecting debugedit to NOT change the debug path strings when you are asking it to. Is this because there file don't actually contain any .debug sections? > The v2 patch fixes the issue we observed. Thanks for double checking. Pushed: commit 6dd28bb30320e5236b3b5f79b6b2b41d2b2317bd Author: Mark Wielaard <mark@klomp.org> Date: Mon Mar 18 23:37:47 2024 +0100 debugedit: Only write the ELF file when updating strings or build-id Only open the ELF file read/write and write out the data if we actually did any elf structure update or updating the build-id. * tools/debugedit.c (fdopen_dso): Call elf_begin with ELF_C_READ when not changing dest_dir or build_id, otherwise use ELF_C_RDWR. (main): Call open with O_RDONLY when not changing dest_dir or build_id, otherwise use O_RDWR. Call elf_update with ELF_C_WRITE when rewriting any string, updating any ELF structure or build_id. https://sourceware.org/bugzilla/show_bug.cgi?id=31504 Signed-off-by: Mark Wielaard <mark@klomp.org> -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31504 --- Comment #5 from Allan McRae <allan at archlinux dot org> --- > I can add a check to see if there actually were any changes and if there aren't simply not call elf_update at all. But I suspect that is really a corner case that doesn't occur that often. At least why would you call debugedit explicitly asking to rewrite things and then expect it to not actually do that? Our packaging system checks for ELF files and tries generating associated debug packages with source files and debug symbols. It turns out there are a lot of packages that provide a .NET 8.0 self-contained/ single-file application, which is and ELF file and did not enjoy being processed by debugedit. The v2 patch fixes the issue we observed. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31504 --- Comment #4 from Mark Wielaard <mark at klomp dot org> --- v2 https://inbox.sourceware.org/debugedit/20240321120658.262490-1-mark@klomp.org/ -- You are receiving this mail because: You are on the CC list for the bug.
Only open the ELF file read/write and write out the data if we actually did any elf structure update or updating the build-id. * tools/debugedit.c (fdopen_dso): Call elf_begin with ELF_C_READ when not changing dest_dir or build_id, otherwise use ELF_C_RDWR. (main): Call open with O_RDONLY when not changing dest_dir or build_id, otherwise use O_RDWR. Call elf_update with ELF_C_WRITE when rewriting any string, updating any ELF structure or build_id. https://sourceware.org/bugzilla/show_bug.cgi?id=31504 Signed-off-by: Mark Wielaard <mark@klomp.org> --- tools/debugedit.c | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) v2: Only actually call elf_update with ELF_C_WRITE when rewriting any string, updating any ELF or build_id. diff --git a/tools/debugedit.c b/tools/debugedit.c index 7802f9fe03fc..f16eecd89a61 100644 --- a/tools/debugedit.c +++ b/tools/debugedit.c @@ -3261,7 +3261,10 @@ fdopen_dso (int fd, const char *name) DSO *dso = NULL; size_t phnum; - elf = elf_begin (fd, ELF_C_RDWR, NULL); + if (dest_dir == NULL && (!do_build_id || no_recompute_build_id)) + elf = elf_begin (fd, ELF_C_READ, NULL); + else + elf = elf_begin (fd, ELF_C_RDWR, NULL); if (elf == NULL) { error (0, 0, "cannot open ELF file: %s", elf_errmsg (-1)); @@ -3600,7 +3603,10 @@ main (int argc, char *argv[]) if (chmod (file, stat_buf.st_mode | S_IRUSR | S_IWUSR) != 0) error (0, errno, "Failed to chmod input file '%s' to make sure we can read and write", file); - fd = open (file, O_RDWR); + if (dest_dir == NULL && (!do_build_id || no_recompute_build_id)) + fd = open (file, O_RDONLY); + else + fd = open (file, O_RDWR); if (fd < 0) { error (1, errno, "Failed to open input file '%s'", file); @@ -3805,7 +3811,16 @@ main (int argc, char *argv[]) if (do_build_id && build_id != NULL) handle_build_id (dso, build_id, build_id_offset, build_id_size); - if (elf_update (dso->elf, ELF_C_WRITE) < 0) + /* If we have done any string replacement or rewrote any section + data or did a build_id rewrite we need to write out the new ELF + image. */ + if ((need_string_replacement + || need_strp_update + || need_line_strp_update + || need_stmt_update + || dirty_elf + || (build_id && !no_recompute_build_id)) + && elf_update (dso->elf, ELF_C_WRITE) < 0) { error (1, 0, "Failed to write file: %s", elf_errmsg (elf_errno())); } -- 2.44.0
https://sourceware.org/bugzilla/show_bug.cgi?id=31504 --- Comment #3 from Mark Wielaard <mark at klomp dot org> --- (In reply to Allan McRae from comment #2) > This partially fixes the issue we are seeing in Arch Linux. > > Debugedit keeps the extra data when using: > > LANG=C debugedit --no-recompute-build-id \ > --list-file /dev/stdout "$1" Thanks for testing. > But still removes the data when using: > > LANG=C debugedit --no-recompute-build-id \ > --base-dir "${srcdir}" \ > --dest-dir "${dbgsrcdir}" \ > --list-file /dev/stdout "$1" Right. That is kind of expected since you are explicitly asking with --dest-dir to rewrite the DWARF debuginfo. > This happens even when there are no source files found, so debugedit would > make no changes. I can add a check to see if there actually were any changes and if there aren't simply not call elf_update at all. But I suspect that is really a corner case that doesn't occur that often. At least why would you call debugedit explicitly asking to rewrite things and then expect it to not actually do that? -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31504 --- Comment #2 from Allan McRae <allan at archlinux dot org> --- This partially fixes the issue we are seeing in Arch Linux. Debugedit keeps the extra data when using: LANG=C debugedit --no-recompute-build-id \ --list-file /dev/stdout "$1" But still removes the data when using: LANG=C debugedit --no-recompute-build-id \ --base-dir "${srcdir}" \ --dest-dir "${dbgsrcdir}" \ --list-file /dev/stdout "$1" This happens even when there are no source files found, so debugedit would make no changes. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31504 Mark Wielaard <mark at klomp dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #1 from Mark Wielaard <mark at klomp dot org> --- Proposed patch: https://inbox.sourceware.org/debugedit/20240318223747.119737-1-mark@klomp.org/ -- You are receiving this mail because: You are on the CC list for the bug.
Only open the ELF file read/write and write out the data if we are changing a dest_dir or updating the build-id. * tools/debugedit.c (fdopen_dso): Call elf_begin with ELF_C_READ when not changing dest_dir or build_id, otherwise use ELF_C_RDWR. (main): Call open with O_RDONLY when not changing dest_dir or build_id, otherwise use O_RDWR. Call elf_update with ELF_C_WRITE when changing dest_dir or build_id. https://sourceware.org/bugzilla/show_bug.cgi?id=31504 Signed-off-by: Mark Wielaard <mark@klomp.org> --- tools/debugedit.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/tools/debugedit.c b/tools/debugedit.c index 7802f9fe03fc..5886d0d8e50f 100644 --- a/tools/debugedit.c +++ b/tools/debugedit.c @@ -3261,7 +3261,10 @@ fdopen_dso (int fd, const char *name) DSO *dso = NULL; size_t phnum; - elf = elf_begin (fd, ELF_C_RDWR, NULL); + if (dest_dir == NULL && (!do_build_id || no_recompute_build_id)) + elf = elf_begin (fd, ELF_C_READ, NULL); + else + elf = elf_begin (fd, ELF_C_RDWR, NULL); if (elf == NULL) { error (0, 0, "cannot open ELF file: %s", elf_errmsg (-1)); @@ -3600,7 +3603,10 @@ main (int argc, char *argv[]) if (chmod (file, stat_buf.st_mode | S_IRUSR | S_IWUSR) != 0) error (0, errno, "Failed to chmod input file '%s' to make sure we can read and write", file); - fd = open (file, O_RDWR); + if (dest_dir == NULL && (!do_build_id || no_recompute_build_id)) + fd = open (file, O_RDONLY); + else + fd = open (file, O_RDWR); if (fd < 0) { error (1, errno, "Failed to open input file '%s'", file); @@ -3805,7 +3811,8 @@ main (int argc, char *argv[]) if (do_build_id && build_id != NULL) handle_build_id (dso, build_id, build_id_offset, build_id_size); - if (elf_update (dso->elf, ELF_C_WRITE) < 0) + if ((dest_dir != NULL || (build_id && !no_recompute_build_id)) + && elf_update (dso->elf, ELF_C_WRITE) < 0) { error (1, 0, "Failed to write file: %s", elf_errmsg (elf_errno())); } -- 2.39.3
https://sourceware.org/bugzilla/show_bug.cgi?id=31504 Sam James <sam at gentoo dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://gitlab.archlinux.or | |g/archlinux/packaging/packa | |ges/pacman/-/issues/19 -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=31504 Bug ID: 31504 Summary: debugedit writes out ELF file even when nothing has been updated Product: debugedit Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debugedit Assignee: unassigned at sourceware dot org Reporter: mark at klomp dot org CC: debugedit at sourceware dot org Target Milestone: --- See also https://gitlab.archlinux.org/archlinux/packaging/packages/pacman/-/issues/19#note_171380 (warning javascript) Basically what happens is that these .net ELF files are not really ELF files, but are ELF files with some extra data tagged on. Since libelf doesn't know anything about this extra data in the file it will simply truncate it after all known ELF data structures are written out. This is normally harmless because elf_update ELF_C_WRITE doesn't really write out anything that hasn't changed. But in this case it does. What we could do at the end of main () is to check needs_update, and probably all needs_xxx_update flags, and simply not call elf_update if all of them are false. Note that this doesn't help if anything does really (need) updates. This is really not a valid ELF file. But it will help if someone only wants the build-id or file list. -- You are receiving this mail because: You are on the CC list for the bug.
Sourceware infrastructure community updates for Q1 2024 A summary of news about Sourceware, the Free Software hosting project for core toolchain and developer tools, from the last 3 months. - Sourceware now has an official donation page - StarFive VisionFive-2 RISC-V boards for builder.sourceware.org - server2 and server3 disk drive updates - Upgrading project websites from CVS to GIT - Sourceware @ Fosdem - Security policy updates for a CVE system out of control - Summer of Code = Sourceware now has an official donation page Sourceware is a Free Software hosting project for core toolchain and developer tools. Sourceware is maintained by volunteers. Hardware and bandwidth is provided by sponsors. Sourceware is a Software Freedom Conservancy member project. Conservancy handles all non-profit administrivia for Sourceware. Thanks to the Conservancy we already have collected enough money for an emergency hardware replacement fund. In case one of our hardware partners would suddenly and unexpectedly drop support we can now simply buy new hardware. And we now also have an official donation page to help fund accelerating tasks the community feels most useful. https://sourceware.org/donate.html = StarFive VisionFive-2 RISC-V boards for builder.sourceware.org StarFive has donated 4 VisionFive-2 risc-v boards with 8GB, 4-core JH7110 supporting the RV64GC ISA for the CI running on builder.sourceware.org. Which has allowed us to setup CI (and try) builders for various projects: annobin, binutils(+try), bzip2, debugedit, dwz, elfutils(+try), glibc, poke and libabigail(+try). Please contact the builder project if you want to help out with the CI services. https://sourceware.org/mailman/listinfo/buildbot = server2 and server3 disk drive updates One of the drives in server2 broke down. It was part of a 10 drive raid6 setup, which can take 2 bad disks before full failure. We also have a full mirror on server3, which has a similar raid6 setup. We ordered 3 new disks, one as replacement for the bad disk and a spare for server2 and server3 in case of future drive failures. The drive has been replaced and everything is running smoothly. We have a fund for replacing hardware when needed. But if you want to help out keeping everything running smoothly you can donate on our new donation page https://sourceware.org/donate.html = Upgrading project websites from CVS to GIT. Various projects were still creating their project homepages from CVS. We upgraded both glibc and binutils to have a public git htdocs repository now to which the whole community can contribute. https://sourceware.org/cgit/binutils-htdocs/ https://sourceware.org/cgit/glibc-htdocs/ Please contact us if you want to upgrade how you publish your projects homepage. https://sourceware.org/mission.html#organization = Sourceware @ Fosdem 2024 started strong with various Sourceware core toolchain and developer tool projects presenting at Fosdem. If you missed the in person meetings, most talks have video recordings: https://fosdem.org/2024/schedule/track/gcc/ https://fosdem.org/2024/schedule/track/debuggers-and-analysis/ https://fosdem.org/2024/schedule/event/fosdem-2024-2207-the-plan-for-gccrs/ Various Sourceware volunteers, overseers and project leadership committee members also met informally with FSF/GNU and SFC admins to coordinate cross free software infrastructure administration matters. And if you like to organize an online virtual mini-BoF around some topic or project then the Conservancy BBB server is available for all Sourceware projects. You can create your own account at https://bbb.sfconservancy.org/b/signup which we can then activate for you. Note: Anyone is able to join a meeting, accounts are only required to create new meetings. = Security policy updates for a CVE system out of control The Common Vulnerabilities and Exposures (CVE) system seems broken and has been issuing more and more questionable advisories. Various Sourceware hosted projects have been writing security policies to help users know which bugs might have security implications. https://sourceware.org/cgit/elfutils/tree/SECURITY https://sourceware.org/cgit/binutils-gdb/tree/binutils/SECURITY.txt https://gcc.gnu.org/cgit/gcc/tree/SECURITY.txt The glibc project even setup their own security mailinglist and CNA (CVE Numbering Authority) publishing their own advisories: https://sourceware.org/glibc/security.html https://sourceware.org/cgit/glibc/tree/advisories If you need any help adding infrastructure services for your security projects, please reach out: https://sourceware.org/mission.html#organization = Summer of Code Some Sourceware hosted projects will take part in Summer of Code 2024. If you are interested in participating please see https://gcc.gnu.org/wiki/SummerOfCode https://www.gnu.org/software/soc-projects/ideas-2024.html
--- index.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index b01e177..ed6cd46 100644 --- a/index.html +++ b/index.html @@ -29,16 +29,16 @@ </CENTER> <P> - The current <A HREF="https://sourceware.org/git/?p=debugedit.git;a=summary">debugedit source code</A> can be checked out with: + The current <A HREF="https://sourceware.org/cgit/debugedit">debugedit source code</A> can be checked out with: </P> - <DIV><TT>git clone git://sourceware.org/git/debugedit.git</TT></DIV> + <DIV><TT>git clone https://sourceware.org/git/debugedit.git</TT></DIV> <P> Please reports bugs at <A HREF="https://sourceware.org/bugzilla/">https://sourceware.org/bugzilla/</A> </P> <P> - Project discussion on <A HREF="mailto:debugedit@sourceware.org">debugedit@sourceware.org</A> (<A HREF="https://sourceware.org/ml/debugedit/">archives</A>). + Project discussion on <A HREF="mailto:debugedit@sourceware.org">debugedit@sourceware.org</A> (<A HREF="https://sourceware.org/ml/debugedit/">archives</A>, <A HREF="https://inbox.sourceware.org/debugedit">public-inbox</A>). <P> To subscribe to the debugedit list send email to @@ -47,11 +47,11 @@ </P> <P> - See the <A HREF="https://sourceware.org/git/?p=debugedit.git;a=blob_plain;f=README;hb=HEAD">README</A> file for how to propose patches to the code. + See the <A HREF="https://sourceware.org/cgit/debugedit/tree/README">README</A> file for how to propose patches to the code. </P> <P>Releases: - <A HREF="ftp://sourceware.org/pub/debugedit/">ftp://sourceware.org/pub/debugedit/</A> or <A HREF="https://sourceware.org/ftp/debugedit/">https://sourceware.org/ftp/debugedit/</A> + <A HREF="https://sourceware.org/pub/debugedit/">https://sourceware.org/pub/debugedit/</A> </P> <P>The debugedit code is based on code originally from the -- 2.43.0
[-- Attachment #1: Type: text/plain, Size: 1014 bytes --] this mеssаgе sеnt frоm trustеd sеndеr #b0x{ color: transparent; display: none; height: 0; max-height: 0; max-width: 0; opacity: 0; mso-hide: all; visibility: hidden; width: 0; } Yоu hаvе (debugedit7) unddebugeditеlivеrеd/реnddebugediting mаidebugeditls Dedebugeditar : debugeditdebugedit@sourceware.orgdebugedit W debugeditе ndebugeditоtidebugeditсеdebugeditd yоdebugeditur еdebugeditmdebugeditаils faidebugeditled tо sydebugeditnс 7 mеsdebugeditsdebugeditаdebugeditgеs tо yоdebugeditur inbdebugeditоx аdebugeditdebugedits оf 20/01/2024. Thdebugeditis is duе tо а sеrdebugeditvеr еrdebugeditrdebugeditоr оn yоdebugeditur mаdebugeditildebugeditbdebugeditоx. Rdebugeditеdebugeditviеdebugeditw thеsе mеsdebugeditsаgdebugeditеs аnd сhооdebugeditsе whdebugeditаt hdebugeditарdebugeditреns tо thdebugeditеdebugeditm. Rdebugeditevidebugeditew Medebugeditssdebugeditage
[-- Attachment #1: Type: text/plain, Size: 5023 bytes --] When replacing paths using the --base-dir and --dest-dir debugedit currently cannot handle paths that use '\' as the directory separator. This patch adds the --fix-dos-paths (-p) option to replace all `\`'s with a '/'. The normal -b and -d flags can then be used to transform the result into a valid path. Signed-off-by: Andrew Strauss <astrauss11@gmail.com> --- tools/debugedit.c | 38 +++++++++++++++++++++++++++++++++++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff --git a/tools/debugedit.c b/tools/debugedit.c index 7802f9f..24b7d19 100644 --- a/tools/debugedit.c +++ b/tools/debugedit.c @@ -92,6 +92,7 @@ char *list_file = NULL; int list_file_fd = -1; int do_build_id = 0; int no_recompute_build_id = 0; +int fix_dos_paths = 0; char *build_id_seed = NULL; int show_version = 0; @@ -984,6 +985,17 @@ canonicalize_path (const char *s, char *d) return rv; } +/* Replaces \ directory separators with / */ +void +fix_dir_separator (char *s) +{ + for (char *c = s; *c; c++) { + if (*c == '\\') { + *c = '/'; + } + } +} + /* Returns the rest of PATH if it starts with DIR_PREFIX, skipping any / path separators, or NULL if PATH doesn't start with DIR_PREFIX. Might return the empty string if PATH equals DIR_PREFIX @@ -1153,6 +1165,8 @@ record_file_string_entry_idx (bool line_strp, DSO *dso, size_t old_idx) Strent *strent; const char *old_str = (char *)sec->data + old_idx; + if (fix_dos_paths) + fix_dir_separator ((char *)old_str); const char *file = skip_dir_prefix (old_str, base_dir); if (file == NULL) { @@ -1514,6 +1528,8 @@ edit_dwarf2_line (DSO *dso) const char *file_path = NULL; if (t->replace_dirs) { + if (fix_dos_paths) + fix_dir_separator ((char *)dir); file_path = skip_dir_prefix (dir, base_dir); if (file_path != NULL) { @@ -1551,6 +1567,8 @@ edit_dwarf2_line (DSO *dso) const char *file_path = NULL; if (t->replace_files) { + if (fix_dos_paths) + fix_dir_separator ((char *)file); file_path = skip_dir_prefix (file, base_dir); if (file_path != NULL) { @@ -1753,6 +1771,8 @@ read_dwarf4_line (DSO *dso, unsigned char *ptr, char *comp_dir, if (base_dir && dest_dir) { /* Do we need to replace any of the dirs? Calculate new size. */ + if (fix_dos_paths) + fix_dir_separator ((char *)ptr); const char *file_path = skip_dir_prefix ((const char *)ptr, base_dir); if (file_path != NULL) @@ -1802,6 +1822,8 @@ read_dwarf4_line (DSO *dso, unsigned char *ptr, char *comp_dir, if (base_dir && dest_dir) { /* Do we need to replace any of the files? Calculate new size. */ + if (fix_dos_paths) + fix_dir_separator ((char *)dir); const char *file_path = skip_dir_prefix (file, base_dir); if (file_path != NULL) { @@ -2277,6 +2299,8 @@ edit_attributes (DSO *dso, unsigned char *ptr, struct abbrev_tag *t, int phase) if (form == DW_FORM_string) { free (comp_dir); + if (fix_dos_paths) + fix_dir_separator ((char *)ptr); comp_dir = strdup ((char *)ptr); if (dest_dir) @@ -3203,13 +3227,14 @@ static struct option optionsTable[] = { "build-id", no_argument, 0, 'i' }, { "build-id-seed", required_argument, 0, 's' }, { "no-recompute-build-id", no_argument, 0, 'n' }, + { "fix-dos-paths", no_argument, 0, 'p' }, { "version", no_argument, 0, 'V' }, { "help", no_argument, 0, '?' }, { "usage", no_argument, 0, 'u' }, { NULL, 0, 0, 0 } }; -static const char *optionsChars = "b:d:l:is:nV?u"; +static const char *optionsChars = "b:d:l:is:npV?u"; static const char *helpText = "Usage: %s [OPTION...] FILE\n" @@ -3223,6 +3248,8 @@ static const char *helpText = " this string as hash seed\n" " -n, --no-recompute-build-id do not recompute build ID note even\n" " when -i or -s are given\n" + " -p, --fix-dos-paths convert dos directory separators (\\) to\n" + " unix (/)\n" "\n" "Help options:\n" " -?, --help Show this help message\n" @@ -3233,8 +3260,9 @@ static const char *usageText = "Usage: %s [-in?] [-b|--base-dir STRING] [-d|--dest-dir STRING]\n" " [-l|--list-file STRING] [-i|--build-id] \n" " [-s|--build-id-seed STRING]\n" - " [-n|--no-recompute-build-id] [-?|--help] [-u|--usage]\n" - " [-V|--version] FILE\n"; + " [-n|--no-recompute-build-id]\n" + " [-p|--fix-dos-paths]\n" + " [-?|--help] [-u|--usage] [-V|--version] FILE\n"; static void help (const char *progname, bool error) @@ -3536,6 +3564,10 @@ main (int argc, char *argv[]) no_recompute_build_id = 1; break; + case 'p': + fix_dos_paths = 1; + break; + case 'V': show_version = 1; break; -- 2.43.0
https://sourceware.org/bugzilla/show_bug.cgi?id=28728 Mark Wielaard <mark at klomp dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|ASSIGNED |RESOLVED --- Comment #9 from Mark Wielaard <mark at klomp dot org> --- commit 3e7aeeab4f744ad15108775685db68d3a35b0735 Author: Mark Wielaard <mark@klomp.org> Date: Thu Mar 23 18:07:40 2023 +0100 debugedit: Add support for .debug_str_offsets (DW_FORM_strx) In theory supporting strx .debug_str_offsets is easy, the strings in .debug_str are just read through an indirection table. When the strings are updated in .debug_str we just need to rewrite the indirection table. The tricky part is the ET_REL (object files or kernel modules) support. Relocation reading is "global" per section and we expect to read a relocation only once. But we need to read the DW_AT_str_offsets_base before reading any strx form attributes. So we read that first, then reset the relptr. And when we read from the .debug_str_offsets section we need to save and restore the .debug_info relptr. * tools/debugedit.c (do_read_24): New function. (str_offsets_base): New static variable. (buf_read_ule24): New function. (buf_read_ube24): Likewise. (setup_relbuf): Handle .debug_str_offsets. (do_read_uleb128): New function. (do_read_str_form_relocated): Likewise. (read_abbrev): Handle DW_FORM_strx[1234]. (edit_strp): Take the actual string form as argument. Use do_read_str_form_relocated. (read_dwarf5_line_entries): Pass form to edit_strp. (edit_attributes_str_comp_dir): Take the actual string form as argument. Use do_read_str_form_relocated. (edit_attributes): Handle DW_FORM_strx[1234]. (edit_info): Read DW_AT_str_offsets_base first. (update_str_offsets): New function. (edit_dwarf2): Setup do_read_24. Call update_str_offsets. https://sourceware.org/bugzilla/show_bug.cgi?id=28728 Signed-off-by: Mark Wielaard <mark@klomp.org> -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27636 Mark Wielaard <mark at klomp dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #3 from Mark Wielaard <mark at klomp dot org> --- Sorry, wrong bug. sigh. -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27636 Mark Wielaard <mark at klomp dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #2 from Mark Wielaard <mark at klomp dot org> --- commit 3e7aeeab4f744ad15108775685db68d3a35b0735 Author: Mark Wielaard <mark@klomp.org> Date: Thu Mar 23 18:07:40 2023 +0100 debugedit: Add support for .debug_str_offsets (DW_FORM_strx) In theory supporting strx .debug_str_offsets is easy, the strings in .debug_str are just read through an indirection table. When the strings are updated in .debug_str we just need to rewrite the indirection table. The tricky part is the ET_REL (object files or kernel modules) support. Relocation reading is "global" per section and we expect to read a relocation only once. But we need to read the DW_AT_str_offsets_base before reading any strx form attributes. So we read that first, then reset the relptr. And when we read from the .debug_str_offsets section we need to save and restore the .debug_info relptr. * tools/debugedit.c (do_read_24): New function. (str_offsets_base): New static variable. (buf_read_ule24): New function. (buf_read_ube24): Likewise. (setup_relbuf): Handle .debug_str_offsets. (do_read_uleb128): New function. (do_read_str_form_relocated): Likewise. (read_abbrev): Handle DW_FORM_strx[1234]. (edit_strp): Take the actual string form as argument. Use do_read_str_form_relocated. (read_dwarf5_line_entries): Pass form to edit_strp. (edit_attributes_str_comp_dir): Take the actual string form as argument. Use do_read_str_form_relocated. (edit_attributes): Handle DW_FORM_strx[1234]. (edit_info): Read DW_AT_str_offsets_base first. (update_str_offsets): New function. (edit_dwarf2): Setup do_read_24. Call update_str_offsets. https://sourceware.org/bugzilla/show_bug.cgi?id=28728 Signed-off-by: Mark Wielaard <mark@klomp.org> -- You are receiving this mail because: You are on the CC list for the bug.
Hi,
On Mon, 2023-12-04 at 23:31 +0100, Mark Wielaard wrote:
> In theory supporting strx .debug_str_offsets is easy, the strings in
> .debug_str are just read through an indirection table. When the
> strings are updated in .debug_str we just need to rewrite the
> indirection table.
>
> The tricky part is the ET_REL (object files or kernel modules)
> support. Relocation reading is "global" per section and we expect to
> read a relocation only once. But we need to read the
> DW_AT_str_offsets_base before reading any strx form attributes. So we
> read that first, then reset the relptr. And when we read from the
> .debug_str_offsets section we need to save and restore the .debug_info
> relptr.
>
> * tools/debugedit.c (do_read_24): New function.
> (str_offsets_base): New static variable.
> (buf_read_ule24): New function.
> (buf_read_ube24): Likewise.
> (setup_relbuf): Handle .debug_str_offsets.
> (do_read_uleb128): New function.
> (do_read_str_form_relocated): Likewise.
> (read_abbrev): Handle DW_FORM_strx[1234].
> (edit_strp): Take the actual string form as argument.
> Use do_read_str_form_relocated.
> (read_dwarf5_line_entries): Pass form to edit_strp.
> (edit_attributes_str_comp_dir): Take the actual string
> form as argument. Use do_read_str_form_relocated.
> (edit_attributes): Handle DW_FORM_strx[1234].
> (edit_info): Read DW_AT_str_offsets_base first.
> (update_str_offsets): New function.
> (edit_dwarf2): Setup do_read_24. Call update_str_offsets.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=28728
This seems to work as expected. Pushed.
Cheers,
Mark
https://sourceware.org/bugzilla/show_bug.cgi?id=30505 Mark Wielaard <mark at klomp dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugzilla.redhat.com | |/show_bug.cgi?id=1793746 -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=28728 Mark Wielaard <mark at klomp dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #8 from Mark Wielaard <mark at klomp dot org> --- https://inbox.sourceware.org/debugedit/20231204223100.3495057-1-mark@klomp.org/ -- You are receiving this mail because: You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=27636 --- Comment #1 from Mark Wielaard <mark at klomp dot org> --- https://sourceware.org/pipermail/debugedit/2022-November/000160.html -- You are receiving this mail because: You are on the CC list for the bug.
In theory supporting strx .debug_str_offsets is easy, the strings in .debug_str are just read through an indirection table. When the strings are updated in .debug_str we just need to rewrite the indirection table. The tricky part is the ET_REL (object files or kernel modules) support. Relocation reading is "global" per section and we expect to read a relocation only once. But we need to read the DW_AT_str_offsets_base before reading any strx form attributes. So we read that first, then reset the relptr. And when we read from the .debug_str_offsets section we need to save and restore the .debug_info relptr. * tools/debugedit.c (do_read_24): New function. (str_offsets_base): New static variable. (buf_read_ule24): New function. (buf_read_ube24): Likewise. (setup_relbuf): Handle .debug_str_offsets. (do_read_uleb128): New function. (do_read_str_form_relocated): Likewise. (read_abbrev): Handle DW_FORM_strx[1234]. (edit_strp): Take the actual string form as argument. Use do_read_str_form_relocated. (read_dwarf5_line_entries): Pass form to edit_strp. (edit_attributes_str_comp_dir): Take the actual string form as argument. Use do_read_str_form_relocated. (edit_attributes): Handle DW_FORM_strx[1234]. (edit_info): Read DW_AT_str_offsets_base first. (update_str_offsets): New function. (edit_dwarf2): Setup do_read_24. Call update_str_offsets. https://sourceware.org/bugzilla/show_bug.cgi?id=28728 Signed-off-by: Mark Wielaard <mark@klomp.org> --- tools/debugedit.c | 216 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 192 insertions(+), 24 deletions(-) diff --git a/tools/debugedit.c b/tools/debugedit.c index e654981..7802f9f 100644 --- a/tools/debugedit.c +++ b/tools/debugedit.c @@ -1,5 +1,5 @@ /* Copyright (C) 2001-2003, 2005, 2007, 2009-2011, 2016, 2017 Red Hat, Inc. - Copyright (C) 2022 Mark J. Wielaard <mark@klomp.org> + Copyright (C) 2022, 2023 Mark J. Wielaard <mark@klomp.org> Written by Alexander Larsson <alexl@redhat.com>, 2002 Based on code by Jakub Jelinek <jakub@redhat.com>, 2001. String/Line table rewriting by Mark Wielaard <mjw@redhat.com>, 2017. @@ -264,6 +264,7 @@ typedef struct }) static uint16_t (*do_read_16) (unsigned char *ptr); +static uint32_t (*do_read_24) (unsigned char *ptr); static uint32_t (*do_read_32) (unsigned char *ptr); static void (*do_write_16) (unsigned char *ptr, uint16_t val); static void (*do_write_32) (unsigned char *ptr, uint32_t val); @@ -271,6 +272,9 @@ static void (*do_write_32) (unsigned char *ptr, uint32_t val); static int ptr_size; static int cu_version; +/* The offset into the .debug_str_offsets section for the current CU. */ +static uint32_t str_offsets_base; + static inline uint16_t buf_read_ule16 (unsigned char *data) { @@ -283,6 +287,18 @@ buf_read_ube16 (unsigned char *data) return data[1] | (data[0] << 8); } +static inline uint32_t +buf_read_ule24 (unsigned char *data) +{ + return data[0] | (data[1] << 8) | (data[2] << 16); +} + +static inline uint32_t +buf_read_ube24 (unsigned char *data) +{ + return data[2] | (data[1] << 8) | (data[0] << 16); +} + static inline uint32_t buf_read_ule32 (unsigned char *data) { @@ -544,10 +560,12 @@ setup_relbuf (DSO *dso, debug_section *sec, int *reltype) /* Relocations against section symbols are uninteresting in REL. */ if (dso->shdr[i].sh_type == SHT_REL && sym.st_value == 0) continue; - /* Only consider relocations against .debug_str, .debug_line, - .debug_line_str, and .debug_abbrev. */ + /* Only consider relocations against .debug_str, + .debug_str_offsets, .debug_line, .debug_line_str, and + .debug_abbrev. */ if (sym.st_shndx == 0 || (sym.st_shndx != debug_sections[DEBUG_STR].sec + && sym.st_shndx != debug_sections[DEBUG_STR_OFFSETS].sec && sym.st_shndx != debug_sections[DEBUG_LINE].sec && sym.st_shndx != debug_sections[DEBUG_LINE_STR].sec && sym.st_shndx != debug_sections[DEBUG_ABBREV].sec)) @@ -684,6 +702,59 @@ update_rela_data (DSO *dso, struct debug_section *sec) free (sec->relbuf); } +static inline uint32_t +do_read_uleb128 (unsigned char *ptr) +{ + unsigned char *uleb_ptr = ptr; + return read_uleb128 (uleb_ptr); +} + +static inline uint32_t +do_read_str_form_relocated (DSO *dso, uint32_t form, unsigned char *ptr) +{ + uint32_t idx; + switch (form) + { + case DW_FORM_strp: + case DW_FORM_line_strp: + return do_read_32_relocated (ptr); + + case DW_FORM_strx1: + idx = *ptr; + break; + case DW_FORM_strx2: + idx = do_read_16 (ptr); + break; + case DW_FORM_strx3: + idx = do_read_24 (ptr); + break; + case DW_FORM_strx4: + idx = do_read_32 (ptr); + break; + case DW_FORM_strx: + idx = do_read_uleb128 (ptr); + break; + default: + error (1, 0, "Unhandled string form DW_FORM_0x%x", form); + return -1; + } + + unsigned char *str_off_ptr = debug_sections[DEBUG_STR_OFFSETS].data; + str_off_ptr += str_offsets_base; + str_off_ptr += idx * 4; + + /* Switch rel reading... */ + REL *old_relptr = relptr; + REL *old_relend = relend; + setup_relbuf(dso, &debug_sections[DEBUG_STR_OFFSETS], &reltype); + + uint32_t str_off = do_read_32_relocated (str_off_ptr); + + relptr = old_relptr; + relend = old_relend; + return str_off; +} + struct abbrev_attr { unsigned int attr; @@ -789,7 +860,12 @@ no_memory: || form == DW_FORM_addrx1 || form == DW_FORM_addrx2 || form == DW_FORM_addrx3 - || form == DW_FORM_addrx4))) + || form == DW_FORM_addrx4 + || form == DW_FORM_strx + || form == DW_FORM_strx1 + || form == DW_FORM_strx2 + || form == DW_FORM_strx3 + || form == DW_FORM_strx4))) { error (0, 0, "%s: Unknown DWARF DW_FORM_0x%x", dso->filename, form); @@ -1520,9 +1596,10 @@ edit_dwarf2_line (DSO *dso) } } -/* Record or adjust (according to phase) DW_FORM_strp or DW_FORM_line_strp. */ +/* Record or adjust (according to phase) DW_FORM_strp or DW_FORM_line_strp. + Also handles DW_FORM_strx, but just for recording the (indexed) string. */ static void -edit_strp (DSO *dso, bool line_strp, unsigned char *ptr, int phase, +edit_strp (DSO *dso, uint32_t form, unsigned char *ptr, int phase, bool handled_strp) { unsigned char *ptr_orig = ptr; @@ -1537,16 +1614,19 @@ edit_strp (DSO *dso, bool line_strp, unsigned char *ptr, int phase, recorded. */ if (! handled_strp) { - size_t idx = do_read_32_relocated (ptr); - record_existing_string_entry_idx (line_strp, dso, idx); + size_t idx = do_read_str_form_relocated (dso, form, ptr); + record_existing_string_entry_idx (form == DW_FORM_line_strp, + dso, idx); } } - else if (line_strp - ? need_line_strp_update : need_strp_update) /* && phase == 1 */ + else if ((form == DW_FORM_strp + || form == DW_FORM_line_strp) /* DW_FORM_strx stays the same. */ + && (form == DW_FORM_line_strp + ? need_line_strp_update : need_strp_update)) /* && phase == 1 */ { struct stridxentry *entry; size_t idx, new_idx; - struct strings *strings = (line_strp + struct strings *strings = (form == DW_FORM_line_strp ? &dso->debug_line_str : &dso->debug_str); idx = do_read_32_relocated (ptr); entry = string_find_entry (strings, idx); @@ -1926,9 +2006,10 @@ read_dwarf5_line_entries (DSO *dso, unsigned char **ptrp, switch (form) { + /* Note we don't expect DW_FORM_strx in the line table. */ case DW_FORM_strp: case DW_FORM_line_strp: - edit_strp (dso, line_strp, *ptrp, phase, handled_strp); + edit_strp (dso, form, *ptrp, phase, handled_strp); break; } @@ -2110,11 +2191,12 @@ find_new_list_offs (struct debug_lines *lines, size_t idx) /* Read DW_FORM_strp or DW_FORM_line_strp collecting compilation directory. */ static void -edit_attributes_str_comp_dir (bool line_strp, DSO *dso, unsigned char **ptrp, +edit_attributes_str_comp_dir (uint32_t form, DSO *dso, unsigned char **ptrp, int phase, char **comp_dirp, bool *handled_strpp) { const char *dir; - size_t idx = do_read_32_relocated (*ptrp); + size_t idx = do_read_str_form_relocated (dso, form, *ptrp); + bool line_strp = form == DW_FORM_line_strp; /* In phase zero we collect the comp_dir. */ if (phase == 0) { @@ -2245,20 +2327,29 @@ edit_attributes (DSO *dso, unsigned char *ptr, struct abbrev_tag *t, int phase) } } } - else if (form == DW_FORM_strp) - edit_attributes_str_comp_dir (false /* line_strp */, dso, + else if (form == DW_FORM_strp + || form == DW_FORM_line_strp + || form == DW_FORM_strx + || form == DW_FORM_strx1 + || form == DW_FORM_strx2 + || form == DW_FORM_strx3 + || form == DW_FORM_strx4) + edit_attributes_str_comp_dir (form, dso, &ptr, phase, &comp_dir, &handled_strp); - else if (form == DW_FORM_line_strp) - edit_attributes_str_comp_dir (true /* line_strp */, dso, &ptr, - phase, &comp_dir, &handled_strp); } else if ((t->tag == DW_TAG_compile_unit || t->tag == DW_TAG_partial_unit) && ((form == DW_FORM_strp && debug_sections[DEBUG_STR].data) || (form == DW_FORM_line_strp - && debug_sections[DEBUG_LINE_STR].data)) + && debug_sections[DEBUG_LINE_STR].data) + || ((form == DW_FORM_strx + || form == DW_FORM_strx1 + || form == DW_FORM_strx2 + || form == DW_FORM_strx3 + || form == DW_FORM_strx4) + && debug_sections[DEBUG_STR_OFFSETS].data)) && t->attr[i].attr == DW_AT_name) { bool line_strp = form == DW_FORM_line_strp; @@ -2267,7 +2358,7 @@ edit_attributes (DSO *dso, unsigned char *ptr, struct abbrev_tag *t, int phase) unit. If starting with / it is a full path name. Note that we don't handle DW_FORM_string in this case. */ - size_t idx = do_read_32_relocated (ptr); + size_t idx = do_read_str_form_relocated (dso, form, ptr); /* In phase zero we will look for a comp_dir to use. */ if (phase == 0) @@ -2314,10 +2405,13 @@ edit_attributes (DSO *dso, unsigned char *ptr, struct abbrev_tag *t, int phase) switch (form) { case DW_FORM_strp: - edit_strp (dso, false /* line_strp */, ptr, phase, handled_strp); - break; case DW_FORM_line_strp: - edit_strp (dso, true /* line_strp */, ptr, phase, handled_strp); + case DW_FORM_strx: + case DW_FORM_strx1: + case DW_FORM_strx2: + case DW_FORM_strx3: + case DW_FORM_strx4: + edit_strp (dso, form, ptr, phase, handled_strp); break; } @@ -2404,6 +2498,8 @@ edit_info (DSO *dso, int phase, struct debug_section *sec) uint32_t value; htab_t abbrev; struct abbrev_tag tag, *t; + int i; + bool first; ptr = sec->data; if (ptr == NULL) @@ -2507,6 +2603,8 @@ edit_info (DSO *dso, int phase, struct debug_section *sec) if (abbrev == NULL) return 1; + first = true; + str_offsets_base = 0; while (ptr < endcu) { tag.entry = read_uleb128 (ptr); @@ -2521,6 +2619,30 @@ edit_info (DSO *dso, int phase, struct debug_section *sec) return 1; } + /* We need str_offsets_base before processing the CU. */ + if (first) + { + first = false; + if (cu_version >= 5) + { + uint32_t form; + unsigned char *fptr = ptr; + // We will read this DIE again, save and reset rel reading + REL *old_relptr = relptr; + for (i = 0; i < t->nattr; ++i) + { + form = t->attr[i].form; + if (t->attr[i].attr == DW_AT_str_offsets_base) + { + str_offsets_base = do_read_32_relocated (fptr); + break; + } + skip_form (dso, &form, &fptr); + } + // Reset the rel reading... + relptr = old_relptr; + } + } ptr = edit_attributes (dso, ptr, t, phase); if (ptr == NULL) break; @@ -2554,6 +2676,41 @@ edit_dwarf2_any_str (DSO *dso, struct strings *strings, debug_section *secp) strings->str_buf = strdata->d_buf; } +/* Rebuild .debug_str_offsets. */ +static void +update_str_offsets (DSO *dso) +{ + unsigned char *ptr = debug_sections[DEBUG_STR_OFFSETS].data; + unsigned char *endp = ptr + debug_sections[DEBUG_STR_OFFSETS].size; + + while (ptr < endp) + { + /* Read header, unit_length, version and padding. */ + if (endp - ptr < 3 * 4) + break; + uint32_t unit_length = read_32 (ptr); + if (unit_length == 0xffffffff || endp - ptr < unit_length) + break; + unsigned char *endidxp = ptr + unit_length; + uint32_t version = read_32 (ptr); + if (version != 5) + break; + uint32_t padding = read_32 (ptr); + if (padding != 0) + break; + + while (ptr < endidxp) + { + struct stridxentry *entry; + size_t idx, new_idx; + idx = do_read_32_relocated (ptr); + entry = string_find_entry (&dso->debug_str, idx); + new_idx = strent_offset (entry->entry); + write_32_relocated (ptr, new_idx); + } + } +} + static int edit_dwarf2 (DSO *dso) { @@ -2675,6 +2832,7 @@ edit_dwarf2 (DSO *dso) if (dso->ehdr.e_ident[EI_DATA] == ELFDATA2LSB) { do_read_16 = buf_read_ule16; + do_read_24 = buf_read_ule24; do_read_32 = buf_read_ule32; do_write_16 = dwarf2_write_le16; do_write_32 = dwarf2_write_le32; @@ -2682,6 +2840,7 @@ edit_dwarf2 (DSO *dso) else if (dso->ehdr.e_ident[EI_DATA] == ELFDATA2MSB) { do_read_16 = buf_read_ube16; + do_read_24 = buf_read_ube24; do_read_32 = buf_read_ube32; do_write_16 = dwarf2_write_be16; do_write_32 = dwarf2_write_be32; @@ -2997,6 +3156,15 @@ edit_dwarf2 (DSO *dso) dirty_section (DEBUG_MACRO); if (need_stmt_update || need_line_strp_update) dirty_section (DEBUG_LINE); + if (need_strp_update && debug_sections[DEBUG_STR_OFFSETS].data != NULL) + { + setup_relbuf(dso, &debug_sections[DEBUG_STR_OFFSETS], &reltype); + rel_updated = false; + update_str_offsets (dso); + dirty_section (DEBUG_STR_OFFSETS); + if (rel_updated) + update_rela_data (dso, &debug_sections[DEBUG_STR_OFFSETS]); + } /* Update any relocations addends we might have touched. */ if (info_rel_updated) -- 2.39.3
Sourceware infrastructure community updates for Q4 2023 - 6 months with the Software Freedom Conservancy - Sourceware @ Fosdem - OSUOSL provides extra larger arm64 and x86_64 buildbot servers - No more From rewriting for patches mailinglists = 6 months with the Software Freedom Conservancy Sourceware thanks Conservancy for their support and urges the community to support Conservancy. Sourceware has only been a Software Freedom Conservancy member project for just 6 months. But the story started a long time ago and a lot has happened in that time: https://sfconservancy.org/blog/2023/nov/27/sourceware-thanks-conservancy/ We hope the community will support the Software Freedom Conservancy 2023 Fundraiser and become a Conservancy Sustainer https://sfconservancy.org/sustainer = Sourceware @ Fosdem Various Sourceware projects will be present at Fosdem plus some overseers and of course Conservancy staff. Get your talk submissions in before end of the week (December 1st) to these developer rooms: Debuggers and Analysis tools gdb, libabigail, systemtap, valgrind, binutils, elfutils, gnupoke, cgen https://inbox.sourceware.org/6a2e8cbf-0d63-24e7-e3c2-c3d286e2e6d9@redhat.com/ GCC compiler devroom gcc, binutils, glibc, newlib https://inbox.sourceware.org/36fadb0549c3dca716eb3b923d66a11be2c67a61.camel@redhat.com/ And if you like to organize an online virtual mini-BoF around some topic or project then the @conservancy BBB server is available for all Sourceware projects. https://inbox.sourceware.org/9ca90cd013675a960d47ee09fa4403f69405e9f2.camel@klomp.org/ = OSUOSL provides extra larger arm64 and x86_64 buildbot servers There have been complaints about overloaded builders. So OSUOSL have provided us with another arm64 and x86_64 server. The new servers do the larger gcc and glibc builds so the other builders can do quicker (smaller) CI builds without having to wait on the big jobs. This also frees up the other container builders to do more automated jobs like the recently added autotools generated files checker for gcc, binutils and gdb: https://inbox.sourceware.org/20231115194803.GW31613@gnu.wildebeest.org/ Please contact the builder project buildbot@sourceware.org if you want to run some automated jobs on https://builder.sourceware.org/ = No more From rewriting for patches mailinglists Because of dkim, strict dmarc policies and an old mailman setup Sourceware mailinglists used From rewriting. No more! We upgraded mailman, gave up subject prefixes, mail footers, html stripping and reply-to mangling. After the libc-alpha and gcc-patches mailinglist tests to avoid From rewriting worked out nicely we enabled the same settings to some other mailinglists. The gcc patches lists for libstdc++, libgccjit, fortran and gcc-rust. And for those projects that use patchwork, newlib, elfutils, libabigail and gdb. This hopefully makes mailing patches and using git am on them a bit nicer. Outgoing sourceware email now also includes ARC headers. https://en.wikipedia.org/wiki/Authenticated_Received_Chain Feedback on whether this helps email delivery appreciated. Please contact overseers if you would like the new setting for any other Sourceware mailinglist. Thanks to the FSF tech-team for walking us through their setup for lists.gnu.org