7 ms·

Any program that uses a logging framework, including the stdlib log package, will wind up depending on runtime.Callers at least transitively. That’s probably mo

Any program that uses a logging framework, including the stdlib log package, will wind up depending on runtime.Callers at least transitively. That’s probably most Go programs; certainly most of the programs large enough to be worrying about binary size. Unlike in C, there are no macros like __FILE__ and __LINE__, so there is no alternative to runtime.Callers (short of preprocessing your Go source code).

umanwizard 7y ago
You can still get a backtrace without symbols though. Why couldn't the Go team introduce a flag that strips symbols, while making clear to people that they should only use it if they are okay with backtraces looking like #1 0x00007ffff7ddb899 in __GI_abort () at abort.c:79 #2 0x0000555555555156 in ?? () #3 0x0000555555555168 in ?? () #4 0x000055555555517d in ?? () #5 0x0000555555555192 in ?? () or similar
- giovannibajo1 7y ago
  Because one of the mantra of Go is not telling users to have a "debug" build and a "release" build. The development build is the one that goes into production, with no difference in optimizations, symbols and whatnot. This has pros and cons, like all tradeoffs.
  - umanwizard 7y ago
    Thanks; I didn’t know that, but it makes sense. Not a design decision I agree with, but it’s coherent, at least.
  - roberson87 7y ago
    Are you sure this is true? Doesn't delve for example build Go source with special flags (gcflags=all='-N -l')to generate debugging symbols. I also remember having to build Go code with those flags for Stackdriver to get the correct debugging information without any optimisations.
    - sagichmal 7y ago
      This shouldn't be necessary anymore.
      - roberson87 7y ago
        Thanks for the reply. Would appreciate if you could expand on this a little, since when? FWITW Google Stackdriver documentation [1] still states that you have to build source with those flags for version 1.1>. [1]https://cloud.google.com/debugger/docs/setup/go https://cloud.google.com/debugger/docs/setup/go
  - shaklee3 7y ago
    It seems like this can only be a con if other languages give you a choice. In other words, in C++ you can decide that your debug and release are the same, or you can make them different if you know what you're doing (like a good IDE does).
    - firethief 7y ago
      Having more options is inherently better in C++, a language designed to reward mastery. Having fewer choices is better in Go, a language designed to make onboarding a new developer easy.
      - umanwizard 7y ago
        In my experience, new developers are not normally charged with determining the details of build flags, deployment systems, etc.
        dodobirdlord 7y ago
        Not to be too judgmental, because I recognize that every organization has its own way, but that sounds like a sign of organizational disfunction.
        umanwizard 7y ago
        I just mean, when you join an existing project, most of that would already be set up. In every project I’ve been on, I was asked to ramp up in the first few weeks by fixing small bugs here and there in the core codebase, not by setting up CI/makefiles/build infra/etc... I actually think I might be totally missing your point, since I don’t really understand what you mean or how you arrived at the conclusion that it’s a sign of dysfunction.
        HeWhoLurksLate 7y ago
        I hope that's how it would work for me- getting the task of setting up makefiles on the first day- before I know anything about the codebase- would feel pretty daunting, to say the least.
  - jasonhansel 7y ago
    The "26M pclntab" issue sounds like an excellent argument against that design decision.
    - loeg 7y ago
      Counterpoint: our work infrastructure for symbolizing stripped binary stacks sucks. I'd love to get backtraces with symbols from the field. But also this entire section could be compressed and seekable and only expanded on demand. No need to leave it as a bloated uncompressed blob.
      - umanwizard 7y ago
        > our work infrastructure for symbolizing stripped binary stacks sucks. I'd love to get backtraces with symbols from the field. If stripped binaries don't work for you, nobody is saying you should be forced to use them. You would presumably just not avail yourself of the option. (As an aside -- what's wrong with your symbolification infrastructure at work? This is something I spent significant time working on in a past job, so I'm always curious how other people are doing it).
        loeg 7y ago
        My employer's internal infrastructure for this just sucks; it's not endemic to stripping binaries. Specifics? The automation to associate cores with specific builds is bad or non-existent; the automation to load up GDB with the right files and corresponding sources or source branch is bad/non-existent; the fileserver storing symbol data is slow and sometimes remote to the developer across a very thin pipe; etc, etc. All to some extent foot-shooting by my organization. But we have TBs and TBs of build artifacts and hundreds of unique daemons producing cores and also have to debug kernel cores and multiple product branches. Part of the pain is perhaps that we're cross-building for an embedded FreeBSD-derived system, but the majority of our developers use Linux or Mac, so we can't necessarily use host-native (or host-native-only) tools. I think basically the situation is begging for someone familiar with the problem-space to sit down and bang out a FUSE filesystem or two (e.g. fetching sources on-demand as GDB reads them, instead of checking out a full multi-GB repo copy) along with a shell or Python script to load up a core. But no one has done it yet and management doesn't really prioritize developer tools.

umanwizard 7y ago

You can still get a backtrace without symbols though. Why couldn't the Go team introduce a flag that strips symbols, while making clear to people that they should only use it if they are okay with backtraces looking like #1 0x00007ffff7ddb899 in __GI_abort () at abort.c:79 #2 0x0000555555555156 in ?? () #3 0x0000555555555168 in ?? () #4 0x000055555555517d in ?? () #5 0x0000555555555192 in ?? () or similar

giovannibajo1 7y ago
Because one of the mantra of Go is not telling users to have a "debug" build and a "release" build. The development build is the one that goes into production, with no difference in optimizations, symbols and whatnot. This has pros and cons, like all tradeoffs.
- umanwizard 7y ago
  Thanks; I didn’t know that, but it makes sense. Not a design decision I agree with, but it’s coherent, at least.
- roberson87 7y ago
  Are you sure this is true? Doesn't delve for example build Go source with special flags (gcflags=all='-N -l')to generate debugging symbols. I also remember having to build Go code with those flags for Stackdriver to get the correct debugging information without any optimisations.
  - sagichmal 7y ago
    This shouldn't be necessary anymore.
    - roberson87 7y ago
      Thanks for the reply. Would appreciate if you could expand on this a little, since when? FWITW Google Stackdriver documentation [1] still states that you have to build source with those flags for version 1.1>. [1]https://cloud.google.com/debugger/docs/setup/go https://cloud.google.com/debugger/docs/setup/go
- shaklee3 7y ago
  It seems like this can only be a con if other languages give you a choice. In other words, in C++ you can decide that your debug and release are the same, or you can make them different if you know what you're doing (like a good IDE does).
  - firethief 7y ago
    Having more options is inherently better in C++, a language designed to reward mastery. Having fewer choices is better in Go, a language designed to make onboarding a new developer easy.
    - umanwizard 7y ago
      In my experience, new developers are not normally charged with determining the details of build flags, deployment systems, etc.
      - dodobirdlord 7y ago
        Not to be too judgmental, because I recognize that every organization has its own way, but that sounds like a sign of organizational disfunction.
        umanwizard 7y ago
        I just mean, when you join an existing project, most of that would already be set up. In every project I’ve been on, I was asked to ramp up in the first few weeks by fixing small bugs here and there in the core codebase, not by setting up CI/makefiles/build infra/etc... I actually think I might be totally missing your point, since I don’t really understand what you mean or how you arrived at the conclusion that it’s a sign of dysfunction.
        HeWhoLurksLate 7y ago
        I hope that's how it would work for me- getting the task of setting up makefiles on the first day- before I know anything about the codebase- would feel pretty daunting, to say the least.
- jasonhansel 7y ago
  The "26M pclntab" issue sounds like an excellent argument against that design decision.
  - loeg 7y ago
    Counterpoint: our work infrastructure for symbolizing stripped binary stacks sucks. I'd love to get backtraces with symbols from the field. But also this entire section could be compressed and seekable and only expanded on demand. No need to leave it as a bloated uncompressed blob.
    - umanwizard 7y ago
      > our work infrastructure for symbolizing stripped binary stacks sucks. I'd love to get backtraces with symbols from the field. If stripped binaries don't work for you, nobody is saying you should be forced to use them. You would presumably just not avail yourself of the option. (As an aside -- what's wrong with your symbolification infrastructure at work? This is something I spent significant time working on in a past job, so I'm always curious how other people are doing it).
      - loeg 7y ago
        My employer's internal infrastructure for this just sucks; it's not endemic to stripping binaries. Specifics? The automation to associate cores with specific builds is bad or non-existent; the automation to load up GDB with the right files and corresponding sources or source branch is bad/non-existent; the fileserver storing symbol data is slow and sometimes remote to the developer across a very thin pipe; etc, etc. All to some extent foot-shooting by my organization. But we have TBs and TBs of build artifacts and hundreds of unique daemons producing cores and also have to debug kernel cores and multiple product branches. Part of the pain is perhaps that we're cross-building for an embedded FreeBSD-derived system, but the majority of our developers use Linux or Mac, so we can't necessarily use host-native (or host-native-only) tools. I think basically the situation is begging for someone familiar with the problem-space to sit down and bang out a FUSE filesystem or two (e.g. fetching sources on-demand as GDB reads them, instead of checking out a full multi-GB repo copy) along with a shell or Python script to load up a core. But no one has done it yet and management doesn't really prioritize developer tools.