Stories
Slash Boxes
Comments

SoylentNews is people

posted by n1 on Tuesday December 20 2016, @03:46AM   Printer-friendly
from the do-not-parse-go dept.

Arthur T Knackerbracket has found the following story:

GO binaries are weird, or at least, that is where this all started out. While delving into some Linux malware named Rex, I came to the realization that I might need to understand more than I wanted to. Just the prior week I had been reversing Linux Lady which was also written in GO, however it was not a stripped binary so it was pretty easy. Clearly the binary was rather large, many extra methods I didn't care about - though I really just didn't understand why. To be honest - I still haven't fully dug into the Golang code and have yet to really write much code in Go, so take this information at face value as some of it might be incorrect; this is just my experience while reversing some ELF Go binaries! If you don't want to read the whole page, or scroll to the bottom to get a link to the full repo, just go here.

-- submitted from IRC


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Funny) by FatPhil on Tuesday December 20 2016, @10:21AM

    by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Tuesday December 20 2016, @10:21AM (#443670) Homepage
    Go must be an desperately immature language, at least from the toolset point of view, as it appears to offer no optimisation at all. Worse, it even jumps around a mov. cmov was introduced into x86 back in 1993-ish. How can the compiler for a language that's not even 10 years old be 23 years behind the processors it's targetting? That's just shameful. That's not a missed optimisation, that's simply not using the facilities that are available (i.e. I'd want a cmov even with optimisation turned off).

    However, the bigger problem appears to be the several thousand functions of bloat, which smacks of kitchen-sink-ism. It would be nice to perform a coverage run of the code, and see how much of that compile-time-deterministic code is actually needed.

    Fortunately, they've made the source code much more compact by not requiring semicolons at the end of lines - phew, it's good to know they've got their priorities right!
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    Starting Score:    1  point
    Moderation   +3  
       Insightful=1, Funny=2, Total=3
    Extra 'Funny' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 2) by RamiK on Tuesday December 20 2016, @07:02PM

    by RamiK (1813) on Tuesday December 20 2016, @07:02PM (#443972)

    Worse, it even jumps around a mov. cmov was introduced into x86 back in 1993-ish.

    cmov is often slower [yarchive.net].

    However, the bigger problem appears to be the several thousand functions of bloat...

    Some work was done for 1.7 [golang.org] but during 1.8 efforts were refocused on expanding the SSA backend since it involved linker refractoring that should make stuff like dead-code elimination during the linking stage easier.

    The thing to remember is that Go's GC and the stdlib's unicode, TLS and HTTP2 support can always be improved upon so shaving off a few bytes off the binaries is just not that appealing as a standalone priority.

    --
    compiling...