create-diff-object: unsupported .data section change for unmodified ppc64le object file #1524

Activity

1. joe-lawrence commented on Sep 25, 2026

   

   joe-lawrence

   on Sep 25, 2026

   ContributorAuthor

   More actions

   Here's the AI analysis, which sounds plausible:

   It's not a .data symbol in general.  Named STT_OBJECT locals with
   status SAME are not pulled in.  The problematic case is a TOC rela to
   the .data section symbol (STT_SECTION, e.g. .data + 0 for that compound
   literal).
   
     ┌─────────────── CU: misc.o (from misc.c) ────────────────┐
     │                                                         │
     │  cifs_get_dfs_tcon_super()                              │
     │           │                                             │
     │           │  TOC16                                      │
     │           ▼                                             │
     │        .toc                                             │
     │     +0x440 → cifs_fs_type    (named object; undef here, │
     │                               defined in cifsfs.o)      │
     │     +0x448 → .data + 0       (STT_SECTION)   < trigger  │
     │           │                                             │
     │           ▼                                             │
     │        .data                                            │
     │     [ &cifs_fs_type | &smb3_fs_type | NULL ]            │
     │       ▲                                                 │
     │       └── compound literal from __cifs_get_super()      │
     │           (no named STT_OBJECT; lives in this CU)       │
     └─────────────────────────────────────────────────────────┘
     smbacl.h ──► cifsacl.h ──► cifsglob.h ──► misc.c   (rebuild only)
                      └── also ──► cifsacl.c (= different CU; real patch)
   
   For any .o that has that:
   
   1. CDO always includes the full .toc (ppc64le)
   2. That always includes .data via the section-symbol rela
   3. Verify then always fatals on included non-NEW .data
   
   So once CDO runs on that CU, it will always error, even if orig ==
   patched and even if no function in that file changed.
   
   CDO only runs if that .o is in changed_objs (e.g. header-driven
   rebuild). Untouched CUs never hit it.  Mostly rare — and this case is a
   narrow intersection.
   
   With -fdata-sections (normal for kpatch kernel builds), almost all
   locals land in named sections like .data._rs.229.  TOC may still relocate
   to those section names at first, but kpatch_replace_sections_syms()
   rewrites them to the bundled object symbol (_rs.229). For STT_OBJECT +
   status SAME, CDO does not pull the section in.
   
   The landmine is specifically:
   
   TOC -> plain .data (or .bss) as STT_SECTION, with no named object to
   rewrite to.
   
   That shows up for things -fdata-sections does not give their own section
   — here, the anonymous compound literal in misc.c.  In this misc.o there
   is exactly one such TOC rela (.data + 0). The dozens of .data._rs.* TOC
   entries are the common, non-fatal pattern after symbol replacement.