2 ms·
carefully designed LOL what kind of joke is this $ echo "pub fn my_function() -> i32 { 0 }" > bar.rs ; rustc --crate-type=dylib bar.rs && nm -A libbar.so|
by jcelerier 6y ago
carefully designed LOL what kind of joke is this
$ echo "pub fn my_function() -> i32 { 0 }" > bar.rs ; rustc --crate-type=dylib bar.rs && nm -A libbar.so| grep my_fun
_ZN3bar11my_function17hce21faeb92ac13c6E
$ echo "pub fn my_function() -> i32 { 1 }" > bar.rs ; rustc --crate-type=dylib bar.rs && nm -A libbar.so| grep my_fun
_ZN3bar11my_function17hce21faeb92ac13c6E
- deleted 6y ago[deleted]
- jeremysalwen 6y agoYou missed the c++filt at the end: $ echo "pub fn my_function() -> i32 { 1 }" > bar.rs ; rustc --crate-type=dylib bar.rs && nm -A libbar.so| grep my_fun | c++filt libbar.so:0000000000047230 T bar::my_function::h4ed6ea856a52cd6b So adding a single hash to the end of the symbol is a joke?
- jcelerier 6y agoI don't think that dlsym would accept "bar::my_function::h4ed6ea856a52cd6b" as a symbol, just like it would not accept "foo(std::vector<int, std::allocator<int> >&)" and wants "_Z3fooRSt6vectorIiSaIiEE" instead, no ? To be clear, my comment was about the fact that two different functions produce exactly the same symbol name, c++filt or not, which is not what I was told above in " It carefully designs its name mangling such that this doesn't happen in the first place, even in the presence of multiple slightly-different builds of a library." I have no particular comments on the idea of using hash though I believe that something that changes 95% of chance error in 0.5% of error (I'd assume, as it took me 10 seconds to find a collision) is very bad - you want errors consistently when you fuck up, not once every hash collision as it sounds like a really really big pain to debug when it happens.
- jeremysalwen 6y agoI see, I misunderstood your comment as about the mangling convention, not about the collision.