Don't let .debug_gdb_scripts become loadable into memory.

[eddyb]

Fixes #41626 by applying what I did in #35409 for metadata sections, to this section.

[rust-highfive]

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

[japaric]

Thanks for the quick fix @eddyb!

@bors r+

cc @whitequark

[bors]

📌 Commit bc6f725 has been approved by japaric

[frewsxcv]

@bors r-

i think this pr caused this fail in this rollup

[eddyb]

Hah, although I have no idea why it succeeds here.

[whitequark]

"side-effect free" stares

[japaric]

@eddyb Travis error

[00:41:03] /checkout/src/test/codegen/gdb_debug_script_load.rs:20:11: error: expected string not found in input
[00:41:03] // CHECK: load volatile i8, i8* getelementptr inbounds ([[B:[[0-9]* x i8]]], [[B]]* @rustc_debug_gdb_scripts_section, i32 0, i32 0), align 1

Looks like this test is looking for the volatile load you just swapped with llvm.used.

[japaric]

"by the linker" - you mean the compiler, right? The linker doesn't know or care about llvm.used stuff but likely it has some special case to preserve the .debug_gdb_scripts section.

[whitequark]

No, by the linker. I thought that too, and started writing a comment, but turns out that it's not true; LLVM has a separate !llvm.compiler.used for what you say, and !llvm.used is defined to keep the symbol through the linking process as well.

[whitequark]

Upon further investigation, on ELF, !llvm.used doesn't actually change anything in the object file, so LangRef is blatantly lying. On MachO, it uses a .no_dead_strip directive. On ELF...

  case MCSA_NoDeadStrip:
    // Ignore for now.
    break;

[whitequark]

To add to this, the default linker script on x86_64 Linux has no mention of .debug_gdb_scripts (or a wildcard over all .debug* sections), and the logic of --gc-sections does not appear to special-case any of that either (it only really special-cases .eh_frame, in general; the rest is handled by traversing the graph). So this is interesting.

[eddyb]

FWIW I only modified the part of the comment that was obviously wrong to me. Is it possible --gc-sections will strip this section, making it useless?

[whitequark]

I have confirmed that the linker, called with --gc-sections, will, in fact, remove .debug_gdb_scripts (whether or not !llvm.used is used, of course). Not only that, but it will also gladly remove this section even when used exactly as directed by the gcc manual, and building with gcc and binutils ld!

My conclusion is that, I suppose not completely unexpectedly, this feature is poorly thought out and is not widely supported by toolchains, and Rust's original solution is gross but undeniably effective. Ideally, linker scripts (on ELF platforms) would be updated to do something like...

SECTIONS {
  .debug_gdb_scripts 0 (NOLOAD) : {
    KEEP(*(.debug_gdb_scripts))
  }
}

... but unfortunately, this doesn't work! Without the directive above, the section shows in objdump as:

  1 .debug_gdb_scripts 000000aa  ffff0000  ffff0000  00020000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA

which is of course not what we want because it's LOAD. With (NOLOAD), however, it's another story entirely:

  1 .debug_gdb_scripts 000000aa  ffff0000  ffff0000  00020000  2**0
                  ALLOC, READONLY

So in a direct contradiction with the ld manual, which claims that:

The linker will process the section normally, but will mark it so that a program loader will not load it into memory. [...] The contents of the [...] section will appear in the linker output file as usual.

the contents of the section does not, in fact, appear in the output file at all.

I'd like to be proven wrong but I am afraid it's not possible to implement this feature.

[whitequark]

Actually, I have proven myself wrong. If I use the extremely obscure output section type of INFO in the linker script, then exactly the thing that I expect happens!

.debug_gdb_scripts 0 (INFO) : {
  KEEP(*(.debug_gdb_scripts))
}

  1 .debug_gdb_scripts 000000aa  00000000  00000000  00011848  2**0
                  CONTENTS, READONLY, DEBUGGING

I do not believe it is viable to integrate this into upstream rustc and so this PR and its parent issue may be closed.

[whitequark]

So incidentally I was curious where did the DEBUGGING bit appear, since that's not something gcc (or gas) can do, and I looked at the binutils source code. It looks like all .debug* sections should have their SEC_ALLOC bit removed (and SEC_DEBUGGING bit added)...

  if ((flags & SEC_ALLOC) == 0)
    {
      /* The debugging sections appear to be recognized only by name,
	 not any sort of flag.  Their SEC_ALLOC bits are cleared.  */
      if (name [0] == '.')
	{
	  const char *p;
	  int n;
	  if (name[1] == 'd')
	    p = ".debug", n = 6;
	  // [snip]
	  else
	    p = NULL, n = 0;
	  if (p != NULL && strncmp (name, p, n) == 0)
	    flags |= SEC_DEBUGGING;
	}

... but this is evidently not happening for .debug_gdb_scripts for some reason that I have no doubt is deeply unsettling in more than one way. There's really a large amount of logic in binutils that touches SEC_DEBUGGING, most of which is almost but not exactly identical platform code, and the more I look into it, the less I want to be aware of it. Or be conscious.