Forum

Forum

Robbert Haarman

2014-02-15

Posted by inglorion
at 2014-11-10 02:28:17

I just released version 1.1.4 of the Voodoo Compiler. This is a maintenance release, and contains the following bug fixes and improvements:

- References to symbols are now always position-independent, even if the symbol is not exported or imported. This means shared libraries can now have symbols that are not externally visible.

- On AMD64, tail-call now restores all callee-save registers in the active frame to their saved values before transferring control to the function being called. Before this fix, calling code generated by the Voodoo compiler from code generated by a different compiler would, under certain circumstances, cause callee-save registers to have wrong values upon return to the code from the other compiler.

- On AMD64, rbx is now a callee-save register, as required by the ABI.

- More rigorous tests for expressions have been added. These exposed some bugs in the generated code on AMD64, which have been fixed.

- The ARM code generator now emits constant pools as necessary to keep them within limited distance from the code that uses them. Previously, constant pools were only emitted at the end of blocks, which could cause the offset between a constant and an instruction that uses that constant to be larger than what can be encoded in the instruction.

  • View this thread (0 comments)
Posted by inglorion
at 2014-10-28 12:51:23

As on other architectures, position-independent code for MIPS on GNU/Linux is accomplished with the help of a global offset table. This table contains the addresses of symbols used by the code. Instead of using the address of a symbol directly, as one would in non-position-independent code, a reference to a symbol is resolved by looking up the symbol's entry in the global offset table and then using the address stored there. Of course, we still need to find the address of the global offset table (abbreviated GOT).

On Mips on GNU/Linux, functions are passed the address of their entry point in register $25. The global offset table is at a fixed offset to this. By convention, $28 is used to hold the address of the GOT. The correct value can be computed as follows:


lui $28, %hi(_gp_disp)
addiu $28, %lo(_gp_disp)
addu $28, $28, $25

This is what the GNU assembler's .cpload $25 pseudo-op expands to.

Once you have the address of the global offset table in $28, you can get the address of a symbol that your object imports or exports by doing something like


lw $2, %got(foo)($28)

where foo is the name of your symbol. This would store the address foo is at in register $2, assuming $28 holds the address of the GOT.

However, for symbols that are defined in your object but not exported, the situation is slightly different. For such symbols, you need to also add the %lo of your symbol's address to the address you get from the GOT. So, for symbols that aren't imported or exported, but defined in the same object as your code, the position-independent way to get the address of the symbol is


lw $2, %got(foo)($28)
addiu $2, %lo(foo)

  • View this thread (0 comments)
Posted by inglorion
at 2014-04-04 00:16:01

Discovery of the day: "less +F". It's something I've been looking for, but hadn't found until recently. Some background: "tail" shows the last couple of lines in a file. "tail -f" does the same, but also "follows" the file, showing new lines as they are added to the file. "less" is a pager, it allows you to view a file screenful by screenful. It also allows you to scroll up, search, and a number of other useful things. One of those is a follow function, which basically does the same as "tail -f", but allows you to go back to less's normal mode of operation, so you can scroll back, etc.

Often, I want to see new lines being added to a file, with the option to scroll back, search, etc. if something interesting happens (e.g. an error message is printed). The way I used to do this is by running "less $filename", then typing an uppercase F, which invokes the follow function. Today, I discovered that you can do this in one go by doing "less +F $filename". This also works for other less commands, e.g. "less +G $filename" will run less on a file, but start at the end of the file, rather than at the beginning. "less +/foo $filename" will open the file and scroll to the first occurrence of "foo".

  • View this thread (0 comments)
Posted by inglorion
at 2014-03-28 09:56:07

Internet.org just announced that they will be using satellites, lasers, and solar-powered planes to give everyone on Earth access to the Internet. You can read about it in the announcement, or watch the video. I'm ridiculously excited about this.

  • View this thread (0 comments)
Posted by inglorion
at 2014-02-02 14:56:41

If you are getting the error message "ValueError: bad marshal data (unknown type code)" while trying to import a Python module, it may be that the compiled version of the module (the .pyc file) is corrupt. There is an easy way to fix that: just delete the .pyc file.

For example, on my Linaro 13.09 system, I got this error whenever I ran any of the package management commands (aptitude et al.):


Traceback (most recent call last):
  File "/usr/bin/py3compile", line 34, in <module>
    from debpython.version import SUPPORTED, debsorted, vrepr, \
  File "/usr/share/python3/debpython/version.py", line 26, in <module>
    from configparser import ConfigParser
  File "<frozen importlib._bootstrap>", line 1564, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1531, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 586, in _check_name_wrapper
  File "<frozen importlib._bootstrap>", line 1023, in load_module
  File "<frozen importlib._bootstrap>", line 1004, in load_module
  File "<frozen importlib._bootstrap>", line 562, in module_for_loader_wrapper
  File "<frozen importlib._bootstrap>", line 854, in _load_module
  File "<frozen importlib._bootstrap>", line 968, in get_code
ValueError: bad marshal data (unknown type code)

I was able to fix this by doing:

sudo rm /usr/lib/python3.3/__pycache__/configparser.cpython-33.pyc

  • View this thread (0 comments)

View previous 5 threads