On Mon, Jul 28, 2014 at 11:09 AM, Markus Trippelsdorf
wrote:
>
> It shouldn't be too hard to implement a simple check for the bug in the
> next release. Just compile the gcc/testsuite/gcc.target/i386/pr61801.c
> testcase with -fcompare-debug. If gcc returns 0 then
> -fvar-tracking-assignments coul
On Sun, Jul 27, 2014 at 8:47 PM, Michel Dänzer wrote:
> On 27.07.2014 04:56, Linus Torvalds wrote:
>>
>> Also, Michel - can you try this patch if you still have your
>> gcc-4.9.0 install, and send me the resulting fair.s file again?
>
> Attached.
The frame setup looks
On Mon, Jul 28, 2014 at 5:26 AM, Frank Ch. Eigler wrote:
>
> Please note that the data produced by "-g -fvar-tracking" is consumed
> by tools like systemtap, perf, crash, and makes a significant
> difference to the observability of debug AND non-debug kernels.
Yeah, and compared to having a buggy
On Sat, Jul 26, 2014 at 1:19 PM, Markus Trippelsdorf
wrote:
>
> Yes. The option only affects -g builds.
Ok, good. I'll wait a bit to hopefully get confirmation from Michel's
setup, but this does seem to be the solution.
> So, the option should only be enabled for debugging builds. Something
> li
On Sat, Jul 26, 2014 at 12:56 PM, Linus Torvalds
wrote:
>
> Also, Michel - can you try this patch if you still have your
> gcc-4.9.0 install, and send me the resulting fair.s file again?
Hmm. The good news is that with that patch, the GCC_COMPARE_DEBUG
build succeeds. At least for
On Sat, Jul 26, 2014 at 12:35 PM, Markus Trippelsdorf
wrote:
>
> But fortunately the workaround for the new inode.c bug is the same as
> for the original bug: -fno-var-tracking-assignments.
>
> It would make sense to enabled it unconditionally for all debug
> configurations for now.
So how is cod
On Sat, Jul 26, 2014 at 11:28 AM, Linus Torvalds
wrote:
>
> That's a bit worrisome. I haven't actually checked if the code
> generation differs in significant ways yet..
Nope. Just three instructions that got re-ordered from ABC to CAB in a
way that makes no difference. But
On Fri, Jul 25, 2014 at 11:29 AM, Linus Torvalds
wrote:
>
> I'm sure it's possible, but it sounds potentially complicated.
Hmm. The bugzilla entry just taught me a new gcc flag:
"-fcompare-debug". That apparently makes gcc compile things twice,
once with debugging an
On Fri, Jul 25, 2014 at 11:29 AM, Linus Torvalds
wrote:
>
> Some simple pattern to make sure that the "sub $frame-size,%rsp" comes
> before any accesses to (%rbp) (when frame pointers are enabled)
> *might* work, but it might also end up missing things.
You're goin
On Fri, Jul 25, 2014 at 7:02 AM, Steven Rostedt wrote:
>
> But wouldn't it be rather trivial to run a static analyzer on the final
> vmlinux to make sure there are no red zones? I mean, you would only need
> to read each function and check to make sure that the offset of rbp is
> within the change
On Thu, Jul 24, 2014 at 6:25 PM, Michel Dänzer wrote:
>
> Attached is fair.s from Debian gcc 4.8.3-5. Does that look better? I'm
> going to try reproducing the problem with a kernel built by that now.
This looks better. For roughly that same code sequence it does
(ignoring the debug line and cfi
11 matches
Mail list logo
