[RFC PATCH v5 17/28] dyndbg: prevent build bugs via -DNO_DYNAMIC_DEBUG_TABLE

[jim.cromie at gmail.com]

On Wed, May 12, 2021 at 8:55 AM Ard Biesheuvel <ardb at kernel.org> wrote:
>
> On Tue, 11 May 2021 at 20:51, Jim Cromie <jim.cromie at gmail.com> wrote:
> >
> > The next patch adds DEFINE_DYNAMIC_DEBUG_TABLE(), which broke several
> > subtrees, including efi, vdso, and some of arch/*/boot/compressed,
> > with various relocation errors, iirc.
> >
> > Avoid those problems by adding a define to suppress the "transparent"
> > DEFINE_DYNAMIC_DEBUG_TABLE() invocation.  I found the x86 problems
> > myself, lkp at intel.com found arm & sparc problems, and may yet find
> > others.
> >
>
> Given that I was only cc'ed on this patch in isolation, would you mind
> adding more clarification here? What is DEFINE_DYNAMIC_DEBUG_TABLE()
> supposed to do, and why is it breaking standalone binaries?
>
>

hi Ard,

the thread starts here:
https://lore.kernel.org/linux-mm/20210511185057.3815777-1-jim.cromie@gmail.com/

the _TABLE macro derives from DEFINE_DYNAMIC_DEBUG_METADATA,
which puts private static struct _ddebug's in section("__dyndbg")
the _TABLE macro populates a different section(".gnu.linkonce.dyndbg"),
which is then placed by linker script at the start of the section.

ISTM that the new section might be whats breaking things.
And maybe that the vmlinux linker script isnt involved.
so the storage the _TABLE wants to define is unbound
(and unused, since there are no pr_debugs)
I did see relocation errors somewhere...

This is my 1st time doing something creative with the linker


As to larger purpose, I'll try to restate the patchset mission:

theres ~45kb savings possible by compressing the highly redundant data (~70kb)
 which decorates pr_debug messages.

1 - split the compressible/decoration columns to a different
section|block, for block compression
      this adds temporary .site pointer from _ddebug -> _ddebug_site

2 -  change code so !site is safe.


_TABLEs only real job is to provide a header record, at the beginning
of the section/array,
for a single .site pointer to the _dyndbg_sites section added in 1.
Because the header has a fixed offset from any pr_debug in the vector,
all pr_debugs can use the headers copy of .site, and dont need their own.
specialize & unionize

So it allows to drop the temporary pointer, restoring memory size
parity with master.
And we then have the _dyndbg_sites  section, full of redundant data,
ready to compress.

suppression with -DNO_DYNAMIC_DEBUG was a workaround, didnt think
about it afterwards

does this clarify ?


thanks
Jim