Andrew Cagney writes:
> On 23 February 2018 at 03:41, Maxime Villard wrote:
>
> > Many of our ASM functions don't push frames, but that's a different issue.
>
> /me mumbles something about the assembler needing to be marked up with
> .cfi directives
yup -- with proper directives you can debug c
Two things come to mind:
- was this the innermost (newest) frame? If it wasn't something
earlier could be the problem
- is the dwarf debug info being used, or is it relying on heuristics
(annoyingly I can't spot an easy way to tell)
and when this happens, 'info frame' may help diagnose things.
On 23 February 2018 at 03:41, Maxime Villard wrote:
> Many of our ASM functions don't push frames, but that's a different issue.
/me mumbles something about the assembler needing to be marked up with
.cfi directives
Le 18/02/2018 à 21:37, Maxime Villard a écrit :
Le 11/02/2018 à 12:04, Krister Walfridsson a écrit :
On Sun, Feb 11, 2018 at 9:11 AM, Maxime Villard wrote:
[...] we need to find a way
to tell GCC to always push the frame at the beginning of the functions.
This is done by passing the -fno-shr
Le 11/02/2018 à 12:04, Krister Walfridsson a écrit :
On Sun, Feb 11, 2018 at 9:11 AM, Maxime Villard wrote:
[...] we need to find a way
to tell GCC to always push the frame at the beginning of the functions.
This is done by passing the -fno-shrink-wrap flag to GCC.
/Krister
Sorry for t
On Sun, Feb 11, 2018 at 04:13:56PM +0700, Robert Elz wrote:
> Date:Sun, 11 Feb 2018 09:11:45 +0100
> From:Maxime Villard
> Message-ID: <2c83e9d9-f49c-479b-7a4c-1df581a2b...@m00nbsd.net>
>
> | So we have the same problem, and we need to find a way
> | to tell GCC t
On Sun, Feb 11, 2018 at 9:11 AM, Maxime Villard wrote:
> [...] we need to find a way
> to tell GCC to always push the frame at the beginning of the functions.
This is done by passing the -fno-shrink-wrap flag to GCC.
/Krister
Date:Sun, 11 Feb 2018 09:11:45 +0100
From:Maxime Villard
Message-ID: <2c83e9d9-f49c-479b-7a4c-1df581a2b...@m00nbsd.net>
| So we have the same problem, and we need to find a way
| to tell GCC to always push the frame at the beginning of the functions.
Either that
Le 09/02/2018 à 13:32, Joerg Sonnenberger a écrit :
On Fri, Feb 09, 2018 at 11:23:17AM +0100, Maxime Villard wrote:
It implies that if a bug occurs _before_ these two instructions are executed,
we have a %rbp that points to the _previous_ function, the one we got called
from. And therefore, GDB
Le 09/02/2018 à 13:32, Joerg Sonnenberger a écrit :
On Fri, Feb 09, 2018 at 11:23:17AM +0100, Maxime Villard wrote:
It implies that if a bug occurs _before_ these two instructions are executed,
we have a %rbp that points to the _previous_ function, the one we got called
from. And therefore, GDB
Le 09/02/2018 à 12:13, Valery Ushakov a écrit :
[Summoning Krister]
On Fri, Feb 09, 2018 at 11:23:17 +0100, Maxime Villard wrote:
There are also several cases where functions in the call tree can disappear
from the backtrace. In the following call tree:
A -> B -> C -> D (and D panic
On Fri, Feb 09, 2018 at 11:23:17AM +0100, Maxime Villard wrote:
> It implies that if a bug occurs _before_ these two instructions are executed,
> we have a %rbp that points to the _previous_ function, the one we got called
> from. And therefore, GDB does not display the current function (where the
[Summoning Krister]
On Fri, Feb 09, 2018 at 11:23:17 +0100, Maxime Villard wrote:
> There are also several cases where functions in the call tree can disappear
> from the backtrace. In the following call tree:
>
> A -> B -> C -> D (and D panics)
>
> if, in B, GCC put the two instruction
Le 09/02/2018 à 12:08, Valery Ushakov a écrit :
On Fri, Feb 09, 2018 at 11:38:47 +0100, Martin Husemann wrote:
On Fri, Feb 09, 2018 at 11:23:17AM +0100, Maxime Villard wrote:
When I spotted this several months ago (while developing Live
Kernel ASLR), I tried to look for GCC options that say "
On Fri, Feb 09, 2018 at 11:38:47 +0100, Martin Husemann wrote:
> On Fri, Feb 09, 2018 at 11:23:17AM +0100, Maxime Villard wrote:
>
> > When I spotted this several months ago (while developing Live
> > Kernel ASLR), I tried to look for GCC options that say "optimize
> > with -O2, but keep the stack
On Fri, Feb 09, 2018 at 11:23:17AM +0100, Maxime Villard wrote:
> When I spotted this several months ago (while developing Live Kernel ASLR), I
> tried to look for GCC options that say "optimize with -O2, but keep the stack
> trace intact". I couldn't find one, and the only thing I ended up doing w
An issue I spotted a few months ago, but PR/52560 just reminded me about it.
Basically, in order to get a backtrace, GDB reads the %rbp register. At the
beginning of each function, GCC inserts the two following instructions:
pushq %rbp
movq%rsp,%rbp
Therefore, at any given
17 matches
Mail list logo
