nubi
[Top] [All Lists]

Comments on NUBI spec. 0.19

To: nubi@linux-mips.org
Subject: Comments on NUBI spec. 0.19
From: David Daney <ddaney@avtrex.com>
Date: Thu, 13 Oct 2005 11:46:07 -0700
Original-recipient: rfc822;nubi@linux-mips.org
Sender: nubi-bounce@linux-mips.org
User-agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929)
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 back trace.

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.

David Daney

<Prev in Thread] Current Thread [Next in Thread>
  • Comments on NUBI spec. 0.19, David Daney <=