For starters: I think NUBI is a good idea.
There are several areas where I think the specification could be more
clear, or added to to improve it.
* The first point is about debugging and in particular the ability to
generate a stack trace at runtime without having to process DWARF data.
Currently in o32 as implemented by GCC 3.3.x I can generate a stack
trace by doing code examination because all function prologs have a
fixed form and can be found by searching backwards from the call point.
With Gcc 3.4.x and beyond, simple leaf functions usually do not need to
initialize their gp or adjust the stack pointer, so they omit the
function prolog. This makes it much more difficult to generate a stack
It seems that the only reason that the rules in section 3.5 (NUBI Stack
Frame Standards) exist is to make this type analysis possible.
I would propose that the specification be enhanced as follows to ensure
that generating stack traces is possible:
1) In section 7.2 where initialization of the gp is discussed, specify
the exact raw instruction sequences that are allowed to be used.
2) For functions where gp initialization is deemed not to be needed for
correct operation of the code a fixed guard sequence is emitted before
the function. It is possible that you could just require that the gp
initialization code always be emitted, even if it can be proved to be
unneeded, but a single fixed form of nop might be a preferable guard
word if it were smaller.
* The second issue I saw is in section 5.1.4 (Relocations and relocation
types). In the sub-section "Relocation types table" it is stated that
the symbol "_gp" is stored in the symbol table under the name "_gp".
Although this is correct, current versions of GNU binutils use a couple
of internally computed magic symbols (_gp_disp and __gnu_local_gp) to
refer to the GOT for a particular function. In large objects where
there are multiple GOTs there cannot be a single fixed symbol in the
object's symbol table.
If the NUBI is to allow for inter linking modules from different
sources, the specification must be more specific about the conventions
and symbol names used for referring to the GOT.
* I would like to see more specifics how exactly relocations like
R_MIPS_JALR and R_MIPS_PJUMP are used. And how they interact with
linker optimizations to bypass gp initialization.
* I am not sure if the current specification deals with this issue. In
the name of ABI compliance GNU binutils later than 2.15 were changed so
that it was no longer possible to specify relative offsets between
exception handling tables and text segments. The result was that
exception handling tables for shared libraries have to have more dynamic
relocations than they would if the relative offset could be used.
Well, that is my initial brain dump on the subject.