Re: [PATCH 7/7] setup_git_env: avoid blind fall-back to ".git"

From: Duy Nguyen <pclouds@gmail.com>
Date: Oct 26, 2016, 12:26 UTC
Message-ID: <CACsJy8AHMJ7OJFKyjYAsPuT0nG=e0RGn59PuX06PJ5pYjinsqA@mail.gmail.com>
In-Reply-To: <20161026121058.a2pmf57oc7p2mlsp@sigill.intra.peff.net>

On Wed, Oct 26, 2016 at 7:10 PM, Jeff King <peff@peff.net> wrote:

Show 25 quoted lines

> On Wed, Oct 26, 2016 at 05:29:21PM +0700, Duy Nguyen wrote:
>
>> > I think you could conditionally make git_path() and all of its
>> > counterparts macros, similar to the way the trace code works. It seems
>> > like a pretty maintenance-heavy solution, though. I'd prefer
>> > conditionally compiling backtrace(); that also doesn't hit 100% of
>> > cases, but at least it isn't too invasive.
>>
>> OK, a more polished patch is this. There are warnings about
>> -fomit-function-pointers in glibc man page, at least in my simple
>> tests it does not cause any issue.
>
> Yeah, I tried with -fno-omit-frame-pointer, but it didn't help. The
> glibc backtrace(3) manpage specifically says:
>
>   The symbol names may be unavailable without the use of special linker
>   options. For systems using the GNU linker, it is necessary to use the
>   -rdynamic linker option. Note that names of "static" functions are not
>   exposed, and won't be available in the backtrace.
>
> which matches the behavior I get.
>
> Gcc ships with a libbacktrace which does seem to give reliable results
> (patch below for reference). But that's still relying on gcc, and on
> having debug symbols available.

Yep. On an optimized build you can't get anywhere without debug info, which has a giant database to describe "if your rip/pc register is here, then you clue to find your caller is there" for basically every instruction in your program. Dwarf3 at least is a crazy world.

> I'm not sure this is really any convenience over dumping a corefile and using gdb to pull out the
> symbols after the fact.

So are we back to forcing core files? I'm ok with that! The only inconvenience I see is pointing out where the core file is, which should be where `pwd` originally is. On linux we can even peek into /proc/sys/kernel/core_pattern if we want to be precise. ulimit can get in the way, but I don't if the default out there is enable or disable core dumping. Once we got OS info and git version, our chances of cracking the core files should be reasonably high.

-- 
Duy