This is the mail archive of the
mailing list for the GCC project.
Re: random commentary on -fsplit-stack (and a bug report)
- From: Ian Lance Taylor <iant at google dot com>
- To: "Jay Freeman \(saurik\)" <saurik at saurik dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 04 Mar 2012 12:10:38 -0800
- Subject: Re: random commentary on -fsplit-stack (and a bug report)
- Authentication-results: mr.google.com; spf=pass (google.com: domain of firstname.lastname@example.org designates 10.68.204.129 as permitted sender) email@example.com; dkim=pass firstname.lastname@example.org
- References: <1236278723.8201330758670008.JavaMail.root@frigate>
"Jay Freeman (saurik)" <email@example.com> writes:
> So, imagine a more general linker feature (again, one which may
> already exist) that allowed you to have a "low-priority symbol" in
> your object file. As in, one which if you find a copy elsewhere the
> linker will use that one, but if it doesn't then it will "fall back"
> to using the one defined locally in this object file. I think that
> this fairly general mechanism is easy to specify and can probably be
> used for all sorts of other tasks that people may come up with; it
> also is not architecture-dependent (as parsing the instructions for
> split-stacks is).
You can do this with most ELF linkers by defining the local symbol as a
weak global symbol.
> Then, when compiling an object file with -fsplit-stack, you A)
> generate both the original symbols and the ".split.*" symbols, as I
> described in my e-mail and B) make the lookup of /all/ function
> symbols be to the ".split.*" varieties. At this point, of course,
> using libraries compiled without -fsplit-stack would be
> impossible. However, then we then C) additionally throw a "fall back"
> ".split.*" stub for every function that we call from the library whose
> implementation is two instructions: call __morestack_non_split, and
> then branch to the original symbol.
Nice idea. I like it.
It would be nice if the linker could discard unused stubs here. The
stubs could go in their own section, of course, but it would be great if
the linker could discard them without using general garbage collection.
Of course this could be a special purpose linker feature, but I also
wonder if it could be more generalized somehow.