Add link_section attribute for static and fn items

[kemurphy]

This allows for control over the section placement of static, static
mut, and fn items. One caveat is that if a static and a static mut are
placed in the same section, the static is declared first, and the static
mut is assigned to, the generated program crashes. For example:

[link_section=".boot"]

static foo : uint = 0xdeadbeef;

[link_section=".boot"]

static mut bar : uint = 0xcafebabe;

Declaring bar first would mark .bootdata as writable, preventing the
crash when bar is written to.

[alexcrichton]

That seems odd that the program crashes as a result of that. Could you detect this to generate a lint/error? That definitely seems like non-obvious behavior which might bite some people.

[kemurphy]

@alexcrichton: This seems expected to me. By defualt, rustc tells LLVM to emit static items in a read-only section (typically .rodata), and static mut items in a writable section (.data). Whatever new section gets defined takes the mode of the first thing that goes in it. The equivalent code in C is:

const unsigned foo attribute ((section ("boot"))) = 10;
unsigned bar attribute ((section ("boot"))) = 15;

GCC will throw an error on that, saying there's a section type mismatch. Clang, on the other hand, accepts it and segfaults if you assign to bar. This makes me think it's LLVM's problem.

[alexcrichton]

Looking at the LLVM source:

class GlobalValue {
  ...
  std::string Section;
  ...
  void setSection(StringRef S) { Section = S; }
}

added with

class StringRef {
  ...
  std::string str() const {             
    if (Data == 0) return std::string();
    return std::string(Data, Length);   
  }                                     
  operator std::string() const {
    return str();               
  }                             
}

I think that assigning into the GlobalValue actually does copy the data so it's OK that the pointer doesn't last forever.

[alexcrichton]

@kemurphy Is there a reason to call it link_section instead of section like with C?

[kemurphy]

@alexcrichton: Not really, it was arbitrary; "section" just seemed a little bare and there's already another attribute prefixed with "link_" somewhere. Is "section" preferred? #rust didn't seem to have a preference when I asked about it.

[alexcrichton]

Hmm... I'd be fine with link_section then. Could you add a test to at least just exercise to make sure that it doesn't die when talking to LLVM? I'm not sure if you could write a test to ensure that it actually ends up in the specified section, but a test could certainly at least exercise the attribute.

[kemurphy]

dbaupp suggested to let it land and then ask graydon what the test is capable of doing, but yeah I can add a test to just exercise the path.

[huonw]

@graydon: is it possible for the test runner to somehow check that a certain symbol ends up in a specific section (even just on one platform)?

(@kemurphy, I'm dbaupp on IRC, btw.)

[kemurphy]

@huonw: Ah, cool. :) I did think of one failing test idea: put a static mut in .rodata and make sure writing to it causes a segfault. Also, putting a function in .data might have an interesting failure mode.