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

[joe-lawrence]

Any change that might provoke fs/smb/client/misc.c to be recompiled (for example, a blank line added tofs/smb/common/smbacl.h) may result in an unmodified misc.o that create-diff-object falsely identifies as a .data change:

ERROR: data section .data selected for inclusion
ERROR: misc.o: 1 unsupported section change(s)

Here is a reproducer script that shows the bug with a sym-linked misc.PATCHED.o to misc.ORIG.o file:
repro-ppc64le-toc-data.tar.gz

[joe-lawrence]

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.