* h...@zytor.com wrote:
> This assumes that it actually ends up being feasible for objtool to do so.
Yes, agreed, that's a big precondition. I'm cautiously optimistic based on
Josh's
experiments that he posted about in this thread.
Thanks,
Ingo
On May 22, 2017 10:49:06 PM PDT, Ingo Molnar wrote:
>
>* H. Peter Anvin wrote:
>
>> On 05/22/17 04:12, Ingo Molnar wrote:
>> \>>
>> >> This construct might be useful for other arches, which is why I
>called
>> >> it "FP" instead of "BP". But then I ruined that with the last 3
>:-)
>> >
>> > Ple
On Fri, May 26, 2017 at 01:29:01PM +0200, Jiri Slaby wrote:
> On 05/26/2017, 08:54 AM, Jiri Slaby wrote:
> > On 05/19/2017, 11:35 PM, Josh Poimboeuf wrote:
> >>
> >> https://github.com/jpoimboe/linux/blob/undwarf/arch/x86/kernel/unwind_undwarf.c
> >
> > JFYI, it crashes in sha1_transform_avx du
On 05/26/2017, 08:54 AM, Jiri Slaby wrote:
> On 05/19/2017, 11:35 PM, Josh Poimboeuf wrote:
>>
>> https://github.com/jpoimboe/linux/blob/undwarf/arch/x86/kernel/unwind_undwarf.c
>
> JFYI, it crashes in sha1_transform_avx due to crypto changes. You
> perhaps missed that this beast uses ebp (not
On 05/19/2017, 11:35 PM, Josh Poimboeuf wrote:
>
> https://github.com/jpoimboe/linux/blob/undwarf/arch/x86/kernel/unwind_undwarf.c
JFYI, it crashes in sha1_transform_avx due to crypto changes. You
perhaps missed that this beast uses ebp (not rbp) register for
computations. I had to do:
--- a/a
* Peter Zijlstra wrote:
> On Wed, May 10, 2017 at 10:32:06AM +0200, Jiri Slaby wrote:
> > > But it does hurt, in the sense that the complicated format of DWARF CFI
> > > means the unwinder has to jump through a lot more hoops to read it.
> >
> > Why that matters, actually? Unwinder is nothing t
On Wed, May 10, 2017 at 10:32:06AM +0200, Jiri Slaby wrote:
> > But it does hurt, in the sense that the complicated format of DWARF CFI
> > means the unwinder has to jump through a lot more hoops to read it.
>
> Why that matters, actually? Unwinder is nothing to be performance
> oriented. And if s
* H. Peter Anvin wrote:
> On 05/22/17 04:12, Ingo Molnar wrote:
> \>>
> >> This construct might be useful for other arches, which is why I called
> >> it "FP" instead of "BP". But then I ruined that with the last 3 :-)
> >
> > Please call it BP - 'FP' can easily be read as floating-point, maki
On Mon, 22 May 2017, H. Peter Anvin wrote:
> > Please call it BP - 'FP' can easily be read as floating-point, making
> > it all super-confusing. We should use canonical x86 register names and
> > ordering - even if not all registers are used straight away.
>
> Seriously, I suspect that at the e
On Mon, May 22, 2017 at 02:37:50PM -0700, H. Peter Anvin wrote:
> On 05/22/17 14:07, H. Peter Anvin wrote:
> > On 05/20/17 13:01, H.J. Lu wrote:
> >> On Sat, May 20, 2017 at 9:20 AM, Josh Poimboeuf
> >> wrote:
> >>
>
> (H.J., could we get a binutils feature that allows is to do:
>
On 05/22/17 14:07, H. Peter Anvin wrote:
> On 05/20/17 13:01, H.J. Lu wrote:
>> On Sat, May 20, 2017 at 9:20 AM, Josh Poimboeuf wrote:
>>
(H.J., could we get a binutils feature that allows is to do:
pushq %whatever
.cfi_adjust_sp -8
...
popq %whatever
.cfi_a
On 05/22/17 04:12, Ingo Molnar wrote:
\>>
>> This construct might be useful for other arches, which is why I called
>> it "FP" instead of "BP". But then I ruined that with the last 3 :-)
>
> Please call it BP - 'FP' can easily be read as floating-point, making it all
> super-confusing. We should
On 05/20/17 13:01, H.J. Lu wrote:
> On Sat, May 20, 2017 at 9:20 AM, Josh Poimboeuf wrote:
>
>>>
>>> (H.J., could we get a binutils feature that allows is to do:
>>>
>>> pushq %whatever
>>> .cfi_adjust_sp -8
>>> ...
>>> popq %whatever
>>> .cfi_adjust_sp 8
>>>
>
> Np. Compiler needs to generate
On Mon, May 22, 2017 at 4:34 AM, Jiri Kosina wrote:
> On Sat, 20 May 2017, H.J. Lu wrote:
>
>> pushq %whatever
>> .cfi_adjust_sp -8
>> ...
>> popq %whatever
>> .cfi_adjust_sp 8
>>
>> >>
>> >> Np. Compiler needs to generate this.
>> >>
>> >
>> > How would the compiler
On Sat, 20 May 2017, H.J. Lu wrote:
> pushq %whatever
> .cfi_adjust_sp -8
> ...
> popq %whatever
> .cfi_adjust_sp 8
>
> >>
> >> Np. Compiler needs to generate this.
> >>
> >
> > How would the compiler generate this when inline asm is involved? For
> > the kernel, ob
* Josh Poimboeuf wrote:
> > How are you handling control flow?
>
> Control flow of what?
>
> > > Here's the struct in its current state:
> > >
> > > #define UNDWARF_REG_UNDEFINED 0
> > > #define UNDWARF_REG_CFA 1
> > > #define UNDWARF_REG_SP 2
On Sat, May 20, 2017 at 4:00 PM, Linus Torvalds
wrote:
>
> hjl already posted an example of the kinds of horrors glibc does to do
> things "right".
Side note: we'd hopefully/presumably never need anything _that_
disgusting for the kernel, so hjl's example is probably an extreme
one.
But even whe
On Sat, May 20, 2017 at 2:56 PM, Andy Lutomirski wrote:
> On Sat, May 20, 2017 at 1:16 PM, Linus Torvalds
> wrote:
>>
>> The amount of unreadable crap and bugs it requires is not worth the
>> pain. Not for *any* amount of gain, and the gain here is basically
>> zero.
>
> But what if objtool autog
On Sat, May 20, 2017 at 2:58 PM, Andy Lutomirski wrote:
> On Sat, May 20, 2017 at 1:01 PM, H.J. Lu wrote:
>> On Sat, May 20, 2017 at 9:20 AM, Josh Poimboeuf wrote:
>>
(H.J., could we get a binutils feature that allows is to do:
pushq %whatever
.cfi_adjust_sp -8
...
On Sat, May 20, 2017 at 1:01 PM, H.J. Lu wrote:
> On Sat, May 20, 2017 at 9:20 AM, Josh Poimboeuf wrote:
>
>>>
>>> (H.J., could we get a binutils feature that allows is to do:
>>>
>>> pushq %whatever
>>> .cfi_adjust_sp -8
>>> ...
>>> popq %whatever
>>> .cfi_adjust_sp 8
>>>
>
> Np. Compiler needs
On Sat, May 20, 2017 at 1:16 PM, Linus Torvalds
wrote:
> On Fri, May 19, 2017 at 10:23 PM, Andy Lutomirski wrote:
>>
>> I personally like the idea of using real DWARF annotations in the
>> entry code because it makes gdb work better (not kgdb -- real gdb
>> attached to KVM). I bet that we could
On Fri, May 19, 2017 at 10:23 PM, Andy Lutomirski wrote:
>
> I personally like the idea of using real DWARF annotations in the
> entry code because it makes gdb work better (not kgdb -- real gdb
> attached to KVM). I bet that we could get entry asm annotations into
> good shape if we really wante
On Sat, May 20, 2017 at 9:20 AM, Josh Poimboeuf wrote:
>>
>> (H.J., could we get a binutils feature that allows is to do:
>>
>> pushq %whatever
>> .cfi_adjust_sp -8
>> ...
>> popq %whatever
>> .cfi_adjust_sp 8
>>
Np. Compiler needs to generate this.
--
H.J.
On Sat, May 20, 2017 at 11:20:34AM -0500, Josh Poimboeuf wrote:
>But then, if we're going that far, why not just have objtool reformat
>the data into something much simpler? It already has the knowledge
>to do so. Then we don't have to jump through all those hoops to
>justify jump
On Fri, May 19, 2017 at 10:23:53PM -0700, Andy Lutomirski wrote:
> On Fri, May 19, 2017 at 2:35 PM, Josh Poimboeuf wrote:
> > On Fri, May 19, 2017 at 04:29:13PM -0500, Josh Poimboeuf wrote:
> >> > How are you handling control flow?
> >>
> >> Control flow of what?
> >>
> >> > > Here's the struct in
On Fri, May 19, 2017 at 2:35 PM, Josh Poimboeuf wrote:
> On Fri, May 19, 2017 at 04:29:13PM -0500, Josh Poimboeuf wrote:
>> > How are you handling control flow?
>>
>> Control flow of what?
>>
>> > > Here's the struct in its current state:
>> > >
>> > > #define UNDWARF_REG_UNDEFINED 0
>
On Fri, May 19, 2017 at 04:29:13PM -0500, Josh Poimboeuf wrote:
> > How are you handling control flow?
>
> Control flow of what?
>
> > > Here's the struct in its current state:
> > >
> > > #define UNDWARF_REG_UNDEFINED 0
> > > #define UNDWARF_REG_CFA 1
> > > #defi
> How are you handling control flow?
Control flow of what?
> > Here's the struct in its current state:
> >
> > #define UNDWARF_REG_UNDEFINED 0
> > #define UNDWARF_REG_CFA 1
> > #define UNDWARF_REG_SP 2
> > #define UNDWARF_REG_FP
On 05/19/17 13:53, Josh Poimboeuf wrote:
>
> Here's the struct in its current state:
>
> #define UNDWARF_REG_UNDEFINED 0
> #define UNDWARF_REG_CFA 1
> #define UNDWARF_REG_SP 2
> #define UNDWARF_REG_FP 3
> #d
On 05/19/17 13:53, Josh Poimboeuf wrote:
>>
>> One instance of the structure would exist for each time the stack
>> pointer changes, e.g. for every function entry, push/pop, and rsp
>> add/subtract. The data could be assembled and sorted offline, possibly
>> derived from DWARF, or more likely, gen
On Sun, May 07, 2017 at 11:55:24AM -0500, Josh Poimboeuf wrote:
> I'm thinking/hoping that information can be expressed in a simple, easy
> to parse, reasonably sized data structure. Something like a sorted
> array of this:
>
> struct undwarf {
> unsigned int ip;/* ins
On Wed, May 10, 2017 at 12:39 AM, Jiri Slaby wrote:
>
> Every SUSE user has been using this for almost a decade and we are not
> about to switch to FP for performance reasons as noted by Jiri Kosina.
The whole "not about to switch on frame pointers" argument is bogus.
Lots of people don't have f
On Wed, May 10, 2017 at 6:09 AM, Josh Poimboeuf wrote:
> On Wed, May 10, 2017 at 10:15:09AM +0200, Jiri Slaby wrote:
>> > I'm, ahem, highly skeptical to creating our own unwinding data
>> > format unless there is *documented, supported, and tested* way to
>> > force the compiler to *automatically*
On Wed, May 10, 2017 at 10:32:06AM +0200, Jiri Slaby wrote:
> On 05/09/2017, 09:22 PM, Josh Poimboeuf wrote:
> > On Tue, May 09, 2017 at 08:47:50PM +0200, Jiri Kosina wrote:
> >> On Sun, 7 May 2017, Josh Poimboeuf wrote:
> >>
> >>> DWARF is great for debuggers. It helps you find all the registers
On Wed, May 10, 2017 at 10:15:09AM +0200, Jiri Slaby wrote:
> > I'm, ahem, highly skeptical to creating our own unwinding data
> > format unless there is *documented, supported, and tested* way to
> > force the compiler to *automatically* fall back to frame pointers
> > any time there may be comple
On 05/10/2017, 02:42 PM, Josh Poimboeuf wrote:
> On Wed, May 10, 2017 at 09:39:39AM +0200, Jiri Slaby wrote:
>> OTOH, TBH, I am not sure KASAN can be enabled for dwarf.c, the same as
>> holds now for the rest of the current unwinding:
>> KASAN_SANITIZE_dumpstack.o := n
On Wed, May 10, 2017 at 09:39:39AM +0200, Jiri Slaby wrote:
> OTOH, TBH, I am not sure KASAN can be enabled for dwarf.c, the same as
> holds now for the rest of the current unwinding:
> KASAN_SANITIZE_dumpstack.o := n
> KASAN_SANITIZE_dumpstack_$(BITS).o
On 05/09/2017, 09:22 PM, Josh Poimboeuf wrote:
> On Tue, May 09, 2017 at 08:47:50PM +0200, Jiri Kosina wrote:
>> On Sun, 7 May 2017, Josh Poimboeuf wrote:
>>
>>> DWARF is great for debuggers. It helps you find all the registers on
>>> the stack, so you can see function arguments and local variabl
On 05/09/2017, 12:00 PM, h...@zytor.com wrote:
> As far as I understand, the .eh_frame section is supposed to contain the
> subset of the DWARF bytecode needed to do a stack unwind when an exception is
> thrown, whereas the .debug* sections contain the full DWARF data a debugger
> might want. T
On 05/06/2017, 09:19 AM, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
>> On Fri, May 5, 2017 at 5:22 AM, Jiri Slaby wrote:
>>> The DWARF unwinder is in place and ready. So introduce the config option
>>> to allow users to enable it. It is by default off due to missing
>>> assembly annotatio
On 05/05/2017, 09:57 PM, Linus Torvalds wrote:
> On Fri, May 5, 2017 at 5:22 AM, Jiri Slaby wrote:
>> The DWARF unwinder is in place and ready. So introduce the config option
>> to allow users to enable it. It is by default off due to missing
>> assembly annotations.
>
> Who actually ends up usin
On Tue, May 09, 2017 at 08:47:50PM +0200, Jiri Kosina wrote:
> On Sun, 7 May 2017, Josh Poimboeuf wrote:
>
> > DWARF is great for debuggers. It helps you find all the registers on
> > the stack, so you can see function arguments and local variables. All
> > expressed in a nice compact format.
On Sun, 7 May 2017, Josh Poimboeuf wrote:
> DWARF is great for debuggers. It helps you find all the registers on
> the stack, so you can see function arguments and local variables. All
> expressed in a nice compact format.
>
> But that's overkill for unwinders. We don't need all those regist
On Tue, May 9, 2017 at 7:58 AM, Josh Poimboeuf wrote:
> On Tue, May 09, 2017 at 03:00:45AM -0700, h...@zytor.com wrote:
>> I'm, ahem, highly skeptical to creating our own unwinding data format
>> unless there is *documented, supported, and tested* way to force the
>> compiler to *automatically* fa
On Tue, May 09, 2017 at 03:00:45AM -0700, h...@zytor.com wrote:
> I'm, ahem, highly skeptical to creating our own unwinding data format
> unless there is *documented, supported, and tested* way to force the
> compiler to *automatically* fall back to frame pointers any time there
> may be complexity
On May 8, 2017 8:38:31 PM PDT, Josh Poimboeuf wrote:
>On Mon, May 08, 2017 at 07:31:50PM -0700, Andy Lutomirski wrote:
>> On Mon, May 8, 2017 at 6:38 PM, Josh Poimboeuf
>wrote:
>> >> Also, don't you need some indication of which reg is the base from
>> >> which you find previous frame? After all
On Mon, May 08, 2017 at 07:31:50PM -0700, Andy Lutomirski wrote:
> On Mon, May 8, 2017 at 6:38 PM, Josh Poimboeuf wrote:
> >> Also, don't you need some indication of which reg is the base from
> >> which you find previous frame? After all, sometimes GCC will emit a
> >> frame pointer even in an o
On Mon, May 8, 2017 at 6:38 PM, Josh Poimboeuf wrote:
> On Mon, May 08, 2017 at 05:21:24PM -0700, Andy Lutomirski wrote:
>> On Sun, May 7, 2017 at 9:55 AM, Josh Poimboeuf wrote:
>> > struct undwarf {
>> > unsigned int ip;/* instruction pointer (relative
>> > offse
On Mon, May 08, 2017 at 05:21:24PM -0700, Andy Lutomirski wrote:
> On Sun, May 7, 2017 at 9:55 AM, Josh Poimboeuf wrote:
> > struct undwarf {
> > unsigned int ip;/* instruction pointer (relative
> > offset from base) */
> > unsigned prev_frame:13; /
On Sun, May 7, 2017 at 9:55 AM, Josh Poimboeuf wrote:
> On Fri, May 05, 2017 at 12:57:11PM -0700, Linus Torvalds wrote:
>> On Fri, May 5, 2017 at 5:22 AM, Jiri Slaby wrote:
>> > The DWARF unwinder is in place and ready. So introduce the config option
>> > to allow users to enable it. It is by def
On May 8, 2017 7:40:49 AM PDT, Josh Poimboeuf wrote:
>On Sun, May 07, 2017 at 10:35:28PM -0700, Andy Lutomirski wrote:
>> I think that, if the code were sufficiently robust, it would be handy
>> if the unwinder displayed function arguments. DWARF can do that to a
>> limited extent.
>
>Honestly I
On Sun, May 07, 2017 at 10:35:28PM -0700, Andy Lutomirski wrote:
> I think that, if the code were sufficiently robust, it would be handy
> if the unwinder displayed function arguments. DWARF can do that to a
> limited extent.
Honestly I get the feeling that displaying function arguments wouldn't
On Mon, May 08, 2017 at 09:50:54AM +0200, Vojtech Pavlik wrote:
> On Sun, May 07, 2017 at 04:48:36PM -0500, Josh Poimboeuf wrote:
>
> > > Can objtool verify the unwinder at each address in the kernel, or is that
> > > an AI-complete problem?
> >
> > It can't verify the *unwinder*, but it can ver
On Sun, May 07, 2017 at 04:48:36PM -0500, Josh Poimboeuf wrote:
> > Can objtool verify the unwinder at each address in the kernel, or is that
> > an AI-complete problem?
>
> It can't verify the *unwinder*, but it can verify the data which is fed
> to the unwinder (either DWARF or the structs I p
* Andy Lutomirski wrote:
> I think that, if the code were sufficiently robust, it would be handy if the
> unwinder displayed function arguments. DWARF can do that to a limited extent.
>
> That being said, having a simpler table format would probably cover most of
> the
> use cases.
I'd say
On Sun, May 7, 2017 at 9:55 AM, Josh Poimboeuf wrote:
> On Fri, May 05, 2017 at 12:57:11PM -0700, Linus Torvalds wrote:
>> On Fri, May 5, 2017 at 5:22 AM, Jiri Slaby wrote:
>> > The DWARF unwinder is in place and ready. So introduce the config option
>> > to allow users to enable it. It is by def
On May 7, 2017 10:59:16 AM PDT, Ingo Molnar wrote:
>
>* Josh Poimboeuf wrote:
>
>> One instance of the structure would exist for each time the stack
>> pointer changes, e.g. for every function entry, push/pop, and rsp
>> add/subtract. The data could be assembled and sorted offline,
>possibly
>>
On Sun, May 07, 2017 at 11:08:19AM -0700, h...@zytor.com wrote:
> On May 7, 2017 10:59:16 AM PDT, Ingo Molnar wrote:
> >
> >* Josh Poimboeuf wrote:
> >
> >> One instance of the structure would exist for each time the stack
> >> pointer changes, e.g. for every function entry, push/pop, and rsp
> >
On Fri, May 05, 2017 at 12:57:11PM -0700, Linus Torvalds wrote:
> On Fri, May 5, 2017 at 5:22 AM, Jiri Slaby wrote:
> > The DWARF unwinder is in place and ready. So introduce the config option
> > to allow users to enable it. It is by default off due to missing
> > assembly annotations.
>
> Who a
* Josh Poimboeuf wrote:
> One instance of the structure would exist for each time the stack
> pointer changes, e.g. for every function entry, push/pop, and rsp
> add/subtract. The data could be assembled and sorted offline, possibly
> derived from DWARF, or more likely, generated by objtool. A
[ adding Josh to CC ]
On Fri, 5 May 2017, Linus Torvalds wrote:
> > The DWARF unwinder is in place and ready. So introduce the config option
> > to allow users to enable it. It is by default off due to missing
> > assembly annotations.
>
> Who actually ends up using this?
As a datapoint -- we'
* Linus Torvalds wrote:
> On Fri, May 5, 2017 at 5:22 AM, Jiri Slaby wrote:
> > The DWARF unwinder is in place and ready. So introduce the config option
> > to allow users to enable it. It is by default off due to missing
> > assembly annotations.
>
> Who actually ends up using this?
Also, wh
On Fri, May 5, 2017 at 5:22 AM, Jiri Slaby wrote:
> The DWARF unwinder is in place and ready. So introduce the config option
> to allow users to enable it. It is by default off due to missing
> assembly annotations.
Who actually ends up using this?
Because from the last time we had fancy unwindo
The DWARF unwinder is in place and ready. So introduce the config option
to allow users to enable it. It is by default off due to missing
assembly annotations.
And we now allow turning off FRAME_POINTERS if DWARF unwinder is
selected.
Signed-off-by: Jiri Slaby
Cc: Thomas Gleixner
Cc: Ingo Molna
64 matches
Mail list logo