Sorry state of dynamic libraries on Linux

---------

I do programming for work and for fun. When I'm relaxing at home, I like to fire-up LoseThos and do neat stuff, like ASM programming where I can tinker with system instructions. That's why I made LoseThos ring-zero-only. I want to play with the cool instructions... in fact, why would I not want all instructions available! Heck, I never need ring 3. It's my own computer and my own programs, of course I want full access at all times!

I put all code in lowest 2 Gig so I only need CALL REL32 for system calls. I don't bother to learn how you have to do it from ring 3, not my problem. That's fer peons who don't have full access.

It's a blemish on 64-bit-edness that I impose "all code in lowest 2 Gig", ugly in a way, but nobody will ever need more than 2 Gig of code and it's very nice what you get in return. By the way, there is no "kernel" or "user", it's all ring 0. It's single-address-map, too. Virtual, identity mapped to physical.

Do this benchmark, heh heh heh:

for (i=0;ithree seconds! I beat Linux and Windows by an order of magnitude.

The C64 was ring-0-only and single-address-mapped. Trust me, it's not dangerous.

-----

We'll leave impotence in God's court. He's just.

God says... everythings_a_okay you're_no_fun et_tu vermin rip_off thank_you_very_much thats_just_wrong Yawn big_fish wastoid astronomical resume jobs oops I_hate_when_that_happens let's_roll delicious do_I_have_to lift BBC not_too_shabby no_news_is_good_news what_a_mess on_the_otherhand I_love_you I'm_good_you_good can_you_hear_me_now California no_news_is_good_news whazza_matter_for_you it's_my_world these_cans_are_defective do_you_like_it Vegas caution tree_hugger manufacturing cosmetics Oy I'm_busy slumin industrious in_theory huh Ghost adultery BRB that's_for_me_to_know prosperity naughty

----

Just kill them, God. They are stupid. People that stupid and stubborn don't deserve to live! Please?

God says... commanded sad let's_see thats_right chaos wastoid okay how_about_a_comic naughty I_gotta_piss what_the_heck whiner repent laziness unsung_hero employee not_the_sharpest_knife_in_the_drawer epic_fail how_come I_got_your_back how_do_I_put_this holier_than_thou Give_me_praise God_is_not_mocked go_ahead_make_my_day hate scorning joker didn't_I_say_that surprise_surprise do_you_want_another honesty WooHoo you_better_not adultery a_flag_on_that_play Percival I'm_God_and_you're_not once_upon_a_time I_quit do_you_get_a_cookie anger you_should_be_so_lucky how_hard_could_it_be why_is_it

----------

LoseThos is 130,000 LOC including compiler. Linux is 15 Million. That's two orders of magnitude.

LoseThos printfs to 1,000,000 in 3 seconds. I think Linux and Winwods take at least 30 seconds.

I started writing a comment before the site went down (hah, I knew it would be WordPress) and now I'll probably forget to post it there so I'll just post it here.

Is the address of externalFunction that is stored in the GOT really resolved to the address of the stub and not the final real address of the function? Because it has to be for data (or code simply wouldn't work), and I don't see why function symbols would be any different.

Also C and C++ say that a function has the same address in all translation units, so comparing the address ought to match regardless of PIC or shared libraries or symbol overriding, and if they don't it's probably a bug in the compiler/linker (or you're using a nonstandard option that breaks this guarantee, e.g. symbol hiding.) And actually this should require that the address in the GOT is the final address of the function.

By the way, any CPU that has static destination branch prediction will predict as well for a double indirect call as a single indirect call (assuming of course the addresses don't change.) The cost is taking up two entries in the branch prediction tables, another L1I cacheline for the stub, and a hiccup in instruction decoding which may or may not have a real effect depending on the code before and after.

> If there’s a reason for getting the address indirectly like this, I have yet to find it.

It should be because of PIC, and the fact that PC-relative addressing on x86_64 has only ±2GB displacement, so if your final binary is over 2GB the linker could fail to put the symbol within range of the offset and fail. Whereas for calls the linker can just insert a stub if this happens and noone's the wiser. Disabling PIC results in "movq $externalFunction, externalVariable(%rip)" for me.

But -mcmodel=small is the default, which should contradict this explanation...

EDIT: so I just tried a test and it appears the GOT on Linux really does contain the address of the stub. what the fuck

On OS X it contains the real address.

While we're complaining about the sorry state of Linux, something it's desperately lacking (for those of us who ship binary-only libraries and executables) is an equivalent of Windows's PDBs or OS X's dSYMs for post-mortem debugging without bloating the shipping binaries.

The bloating can be extraordinary. When you're shipping libraries to discerning customers (programmers, not end users), perception really does matter.

A related issue which is more about the compiler than the operating system is that PDBs with Visual C++ on Windows are much more useful with highly optimized binaries than symbols (either embedded or separate) are with GCC-optimized binaries. This is understandable when you consider the different development cultures, but that doesn't make it any less of a problem for us. :)

See http://linux.die.net/man/1/objcopy -> --only-keep-debug

Then you can open the core file as usual: gdb executable core (just be sure to have debug files in the same directory)