Re: [PATCH] kcsan: kconfig: Move to menu 'Generic Kernel Debugging Instruments'

[Randy Dunlap]

On 9/4/20 8:22 AM, Changbin Du wrote:
> This moves the KCSAN kconfig items under menu 'Generic Kernel Debugging
> Instruments' where UBSAN resides.
> 
> Signed-off-by: Changbin Du 

LGTM. Thanks.

Reviewed-by: Randy Dunlap 
Tested-by: Randy Dunlap 

> ---
>  lib/Kconfig.debug | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index e068c3c7189a..0c781f912f9f 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -520,8 +520,8 @@ config DEBUG_FS_ALLOW_NONE
>  endchoice
>  
>  source "lib/Kconfig.kgdb"
> -
>  source "lib/Kconfig.ubsan"
> +source "lib/Kconfig.kcsan"
>  
>  endmenu
>  
> @@ -1620,8 +1620,6 @@ config PROVIDE_OHCI1394_DMA_INIT
>  
>  source "samples/Kconfig"
>  
> -source "lib/Kconfig.kcsan"
> -
>  config ARCH_HAS_DEVMEM_IS_ALLOWED
>   bool
>  
> 

-- 
~Randy

[PATCH] kcsan: kconfig: Move to menu 'Generic Kernel Debugging Instruments'

[Changbin Du]

This moves the KCSAN kconfig items under menu 'Generic Kernel Debugging
Instruments' where UBSAN resides.

Signed-off-by: Changbin Du 
---
 lib/Kconfig.debug | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index e068c3c7189a..0c781f912f9f 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -520,8 +520,8 @@ config DEBUG_FS_ALLOW_NONE
 endchoice
 
 source "lib/Kconfig.kgdb"
-
 source "lib/Kconfig.ubsan"
+source "lib/Kconfig.kcsan"
 
 endmenu
 
@@ -1620,8 +1620,6 @@ config PROVIDE_OHCI1394_DMA_INIT
 
 source "samples/Kconfig"
 
-source "lib/Kconfig.kcsan"
-
 config ARCH_HAS_DEVMEM_IS_ALLOWED
bool
 
-- 
2.25.1

[RESEND PATCH v3 9/9] hacking: Move DEBUG_FS to 'Generic Kernel Debugging Instruments'

[Changbin Du]

DEBUG_FS does not belong to 'Compile-time checks and compiler options'.

Signed-off-by: Changbin Du 
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
---
 lib/Kconfig.debug | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 12727e12a28b..82cb1bcf07a8 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -286,18 +286,6 @@ config READABLE_ASM
   to keep kernel developers who have to stare a lot at assembler 
listings
   sane.
 
-config DEBUG_FS
-   bool "Debug Filesystem"
-   help
- debugfs is a virtual file system that kernel developers use to put
- debugging files into.  Enable this option to be able to read and
- write to these files.
-
- For detailed documentation on the debugfs API, see
- Documentation/filesystems/.
-
- If unsure, say N.
-
 config HEADERS_INSTALL
bool "Install uapi headers to usr/include"
depends on !UML
@@ -445,6 +433,18 @@ config MAGIC_SYSRQ_SERIAL
  This option allows you to decide whether you want to enable the
  magic SysRq key.
 
+config DEBUG_FS
+   bool "Debug Filesystem"
+   help
+ debugfs is a virtual file system that kernel developers use to put
+ debugging files into.  Enable this option to be able to read and
+ write to these files.
+
+ For detailed documentation on the debugfs API, see
+ Documentation/filesystems/.
+
+ If unsure, say N.
+
 source "lib/Kconfig.kgdb"
 
 source "lib/Kconfig.ubsan"
-- 
2.20.1

[RESEND PATCH v3 1/9] hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging Instruments'

[Changbin Du]

Group generic kernel debugging instruments sysrq/kgdb/ubsan together into
a new submenu.

Signed-off-by: Changbin Du 
Acked-by: Randy Dunlap 
Tested-by: Randy Dunlap 
---
 lib/Kconfig.debug | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index a0250e53954a..157db30e626d 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -401,6 +401,8 @@ config DEBUG_FORCE_WEAK_PER_CPU
 
 endmenu # "Compiler options"
 
+menu "Generic Kernel Debugging Instruments"
+
 config MAGIC_SYSRQ
bool "Magic SysRq key"
depends on !UML
@@ -434,6 +436,12 @@ config MAGIC_SYSRQ_SERIAL
  This option allows you to decide whether you want to enable the
  magic SysRq key.
 
+source "lib/Kconfig.kgdb"
+
+source "lib/Kconfig.ubsan"
+
+endmenu
+
 config DEBUG_KERNEL
bool "Kernel debugging"
help
@@ -2095,10 +2103,6 @@ config BUG_ON_DATA_CORRUPTION
 
 source "samples/Kconfig"
 
-source "lib/Kconfig.kgdb"
-
-source "lib/Kconfig.ubsan"
-
 config ARCH_HAS_DEVMEM_IS_ALLOWED
bool
 
-- 
2.20.1

[PATCH v3 9/9] hacking: Move DEBUG_FS to 'Generic Kernel Debugging Instruments'

[Changbin Du]

DEBUG_FS does not belong to 'Compile-time checks and compiler options'.

Cc: Randy Dunlap 
Signed-off-by: Changbin Du 
---
 lib/Kconfig.debug | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ceefe0c1e78b..09e82676e59c 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -302,18 +302,6 @@ config UNUSED_SYMBOLS
  you really need it, and what the merge plan to the mainline kernel for
  your module is.
 
-config DEBUG_FS
-   bool "Debug Filesystem"
-   help
- debugfs is a virtual file system that kernel developers use to put
- debugging files into.  Enable this option to be able to read and
- write to these files.
-
- For detailed documentation on the debugfs API, see
- Documentation/filesystems/.
-
- If unsure, say N.
-
 config HEADERS_INSTALL
bool "Install uapi headers to usr/include"
depends on !UML
@@ -463,6 +451,18 @@ config MAGIC_SYSRQ_SERIAL
  This option allows you to decide whether you want to enable the
  magic SysRq key.
 
+config DEBUG_FS
+   bool "Debug Filesystem"
+   help
+ debugfs is a virtual file system that kernel developers use to put
+ debugging files into.  Enable this option to be able to read and
+ write to these files.
+
+ For detailed documentation on the debugfs API, see
+ Documentation/filesystems/.
+
+ If unsure, say N.
+
 source "lib/Kconfig.kgdb"
 
 source "lib/Kconfig.ubsan"
-- 
2.20.1

[PATCH v3 1/9] hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging Instruments'

[Changbin Du]

Group generic kernel debugging instruments sysrq/kgdb/ubsan together into
a new submenu.

Signed-off-by: Changbin Du 
---
 lib/Kconfig.debug | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 10023dbac8e4..bd3938483514 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -419,6 +419,8 @@ config DEBUG_FORCE_WEAK_PER_CPU
 
 endmenu # "Compiler options"
 
+menu "Generic Kernel Debugging Instruments"
+
 config MAGIC_SYSRQ
bool "Magic SysRq key"
depends on !UML
@@ -452,6 +454,12 @@ config MAGIC_SYSRQ_SERIAL
  This option allows you to decide whether you want to enable the
  magic SysRq key.
 
+source "lib/Kconfig.kgdb"
+
+source "lib/Kconfig.ubsan"
+
+endmenu
+
 config DEBUG_KERNEL
bool "Kernel debugging"
help
@@ -2111,10 +2119,6 @@ config BUG_ON_DATA_CORRUPTION
 
 source "samples/Kconfig"
 
-source "lib/Kconfig.kgdb"
-
-source "lib/Kconfig.ubsan"
-
 config ARCH_HAS_DEVMEM_IS_ALLOWED
bool
 
-- 
2.20.1

[PATCH v2 9/9] kconfig/hacking: Move DEBUG_FS to 'Generic Kernel Debugging Instruments'

[Changbin Du]

DEBUG_FS does not belong to 'Compile-time checks and compiler options'.

Cc: Randy Dunlap 
Signed-off-by: Changbin Du 
---
 lib/Kconfig.debug | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ceefe0c1e78b..09e82676e59c 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -302,18 +302,6 @@ config UNUSED_SYMBOLS
  you really need it, and what the merge plan to the mainline kernel for
  your module is.
 
-config DEBUG_FS
-   bool "Debug Filesystem"
-   help
- debugfs is a virtual file system that kernel developers use to put
- debugging files into.  Enable this option to be able to read and
- write to these files.
-
- For detailed documentation on the debugfs API, see
- Documentation/filesystems/.
-
- If unsure, say N.
-
 config HEADERS_INSTALL
bool "Install uapi headers to usr/include"
depends on !UML
@@ -463,6 +451,18 @@ config MAGIC_SYSRQ_SERIAL
  This option allows you to decide whether you want to enable the
  magic SysRq key.
 
+config DEBUG_FS
+   bool "Debug Filesystem"
+   help
+ debugfs is a virtual file system that kernel developers use to put
+ debugging files into.  Enable this option to be able to read and
+ write to these files.
+
+ For detailed documentation on the debugfs API, see
+ Documentation/filesystems/.
+
+ If unsure, say N.
+
 source "lib/Kconfig.kgdb"
 
 source "lib/Kconfig.ubsan"
-- 
2.20.1

[PATCH v2 1/9] kconfig/hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging Instruments'

[Changbin Du]

Group generic kernel debugging instruments sysrq/kgdb/ubsan together into
a new submenu.

Signed-off-by: Changbin Du 
---
 lib/Kconfig.debug | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 10023dbac8e4..bd3938483514 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -419,6 +419,8 @@ config DEBUG_FORCE_WEAK_PER_CPU
 
 endmenu # "Compiler options"
 
+menu "Generic Kernel Debugging Instruments"
+
 config MAGIC_SYSRQ
bool "Magic SysRq key"
depends on !UML
@@ -452,6 +454,12 @@ config MAGIC_SYSRQ_SERIAL
  This option allows you to decide whether you want to enable the
  magic SysRq key.
 
+source "lib/Kconfig.kgdb"
+
+source "lib/Kconfig.ubsan"
+
+endmenu
+
 config DEBUG_KERNEL
bool "Kernel debugging"
help
@@ -2111,10 +2119,6 @@ config BUG_ON_DATA_CORRUPTION
 
 source "samples/Kconfig"
 
-source "lib/Kconfig.kgdb"
-
-source "lib/Kconfig.ubsan"
-
 config ARCH_HAS_DEVMEM_IS_ALLOWED
bool
 
-- 
2.20.1

[PATCH 1/8] kconfig/hacking: Group sysrq/kgdb/ubsan into 'Generic Kernel Debugging Instruments'

[Changbin Du]

Group generic kernel debugging instruments sysrq/kgdb/ubsan together into
a new submenu.

Signed-off-by: Changbin Du 
---
 lib/Kconfig.debug | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 5960e2980a8a..868fa64a0901 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -419,6 +419,8 @@ config DEBUG_FORCE_WEAK_PER_CPU
 
 endmenu # "Compiler options"
 
+menu "Generic Kernel Debugging Instruments"
+
 config MAGIC_SYSRQ
bool "Magic SysRq key"
depends on !UML
@@ -452,6 +454,12 @@ config MAGIC_SYSRQ_SERIAL
  This option allows you to decide whether you want to enable the
  magic SysRq key.
 
+source "lib/Kconfig.kgdb"
+
+source "lib/Kconfig.ubsan"
+
+endmenu
+
 config DEBUG_KERNEL
bool "Kernel debugging"
help
@@ -2099,10 +2107,6 @@ config BUG_ON_DATA_CORRUPTION
 
 source "samples/Kconfig"
 
-source "lib/Kconfig.kgdb"
-
-source "lib/Kconfig.ubsan"
-
 config ARCH_HAS_DEVMEM_IS_ALLOWED
bool
 
-- 
2.20.1

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[H. Nikolaus Schaller]

Hi Russell,

> Am 09.11.2017 um 18:35 schrieb Russell King - ARM Linux 
> :
> 
> Hi Nikkylos,
> 
> On Thu, Nov 09, 2017 at 06:16:29PM +0100, H. Nikolaus Schaller wrote:
>> Hi Russel,
>> 
>>> Am 09.11.2017 um 17:58 schrieb Russell King - ARM Linux 
>>> :
>>> 
>>> On Thu, Nov 09, 2017 at 06:44:49AM +0100, H. Nikolaus Schaller wrote:
 Hi Russel,
>>> 
>>> Nikolus,
>>> 
> Am 08.11.2017 um 23:38 schrieb Russell King - ARM Linux 
> :
> 
> On Wed, Nov 08, 2017 at 10:36:04PM +, Russell King - ARM Linux wrote:
>> We don't need a compiler warning there, we probably need better help
>> text against DEBUG_LL and against EARLY_PRINTK.
> 
> Actually, this is already clearly stated against DEBUG_LL:
> 
>Note that selecting this option will limit the kernel to a single
>UART definition, as specified below. Attempting to boot the kernel
>image on a different platform *will not work*, so this option 
> should
>not be enabled for kernels that are intended to be portable.
> 
> and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
> read help texts anymore.
 
 Yes, we read, but we face a situation where it doesn't help that it is a
 well known problem *for you* or anyone else and that it is described in
 the help.
>>> 
>>> Personally, I'd like early_printk not to be re-using this, but others
>>> disagree.  It's all about knowledge and compromise.
>> 
>> Sure, we have to make a lot of compromises...
>> 
>>> 
>>> What we don't want is more warnings in the kernel - it's already
>>> hard enough for people to spot the "bad" warnings that they need to
>>> fix to have a working system (such as wrong printf specifiers) that
>>> (a) they're not going to spot this #warning and (b) it's just going
>>> to be more noise for those who do try to spot the warnings.
>> 
>>> 
 Do you expect anybody to remember after 3 years of *not* changing DEBUG_LL
 what was written in a help message? Or to understand that DEBUG_LL has
 anything to do with the mysteriously appearing boot problem? Which can't
 easily be debugged since there are no messages despite playing with
 EARLY_PRINTK/EARLYCON?
>>> 
>>> Do you expect people to read the build log of their kernel and spot
>>> the additional warning?
>> 
>> I am doing it and I rarely see warnings by the compiler. Maybe sometimes
>> during the -rc phase but not in stable.
> 
> The warnings you see are compiler specific, and I hardly ever see builds
> that are fully clean.

I can just contribute my experience that mine are usually.

> 
>>> You might be on the ball enough to do that,
>>> but not everyone does, or is.  Not everyone logs the output of the
>>> kernel build so they can review it later.  I suspect that many just
>>> set the build going in a terminal, walk away and come back sometime
>>> later when they think it's done.
>> 
>> In this case they would have a good trigger and reason to look into the
>> build log: the kernel they just built isn't booting and doesn't tell
>> anything. Then I guess for many of us the next logical step would be to
>> look trough the build log (but not through a defconfig that wasn't touched
>> for ages).
>> 
>> Well, I have to admit that if someone doesn't try a clean build, it
>> will not see it again if the initial log wasn't captured somewhere...
>> 
>> So it should more be an #error than a #warning. Then people must notice.
>> But I don't know if there are situations where this would be too strict.
> 
> There are - it's perfectly valid to have your kernel, but with DEBUG_LL
> enabled and configured correctly so it outputs to a real UART on your
> platform.  As I've explained already, DEBUG_LL exists as a way of last
> resort to solve the "it doesn't boot" problem, because it gives a
> way for the early assembler to be instrumented and debugged before
> anything else is up, through the kernel boot sequence and into the C
> code.

Indeed - except that DEBUG_LL can be the reason for the "it doesn't boot"
which I assume nobody expects. t would be like placing a voltmeter somewhere
and you have power outage.

> 
> That is its primary purpose.  Adding a #error or #warning is going to
> turn people who most need the infrastructure to solve the "it silently
> doesn't boot" away.

This confirms my assumption that a #warning seems more appropriate than
an #error. You can ignore it if you know what you are doing.

> 
> Unfortunately, DEBUG_LL is one of those things that is platform specific,
> it has to be to guarantee output, so situations such as missing DT can
> still produce output.  Unfortunately, it got used for early_printk
> because it was easier to add early_printk rather than telling people
> to add a printascii() call in kernel/printk/printk.c (which is what I
> used to tell people, and what I _still_ do today.)

Yes, I have used printascii() in 

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[H. Nikolaus Schaller]

Hi Russell,

> Am 09.11.2017 um 18:35 schrieb Russell King - ARM Linux 
> :
> 
> Hi Nikkylos,
> 
> On Thu, Nov 09, 2017 at 06:16:29PM +0100, H. Nikolaus Schaller wrote:
>> Hi Russel,
>> 
>>> Am 09.11.2017 um 17:58 schrieb Russell King - ARM Linux 
>>> :
>>> 
>>> On Thu, Nov 09, 2017 at 06:44:49AM +0100, H. Nikolaus Schaller wrote:
 Hi Russel,
>>> 
>>> Nikolus,
>>> 
> Am 08.11.2017 um 23:38 schrieb Russell King - ARM Linux 
> :
> 
> On Wed, Nov 08, 2017 at 10:36:04PM +, Russell King - ARM Linux wrote:
>> We don't need a compiler warning there, we probably need better help
>> text against DEBUG_LL and against EARLY_PRINTK.
> 
> Actually, this is already clearly stated against DEBUG_LL:
> 
>Note that selecting this option will limit the kernel to a single
>UART definition, as specified below. Attempting to boot the kernel
>image on a different platform *will not work*, so this option 
> should
>not be enabled for kernels that are intended to be portable.
> 
> and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
> read help texts anymore.
 
 Yes, we read, but we face a situation where it doesn't help that it is a
 well known problem *for you* or anyone else and that it is described in
 the help.
>>> 
>>> Personally, I'd like early_printk not to be re-using this, but others
>>> disagree.  It's all about knowledge and compromise.
>> 
>> Sure, we have to make a lot of compromises...
>> 
>>> 
>>> What we don't want is more warnings in the kernel - it's already
>>> hard enough for people to spot the "bad" warnings that they need to
>>> fix to have a working system (such as wrong printf specifiers) that
>>> (a) they're not going to spot this #warning and (b) it's just going
>>> to be more noise for those who do try to spot the warnings.
>> 
>>> 
 Do you expect anybody to remember after 3 years of *not* changing DEBUG_LL
 what was written in a help message? Or to understand that DEBUG_LL has
 anything to do with the mysteriously appearing boot problem? Which can't
 easily be debugged since there are no messages despite playing with
 EARLY_PRINTK/EARLYCON?
>>> 
>>> Do you expect people to read the build log of their kernel and spot
>>> the additional warning?
>> 
>> I am doing it and I rarely see warnings by the compiler. Maybe sometimes
>> during the -rc phase but not in stable.
> 
> The warnings you see are compiler specific, and I hardly ever see builds
> that are fully clean.

I can just contribute my experience that mine are usually.

> 
>>> You might be on the ball enough to do that,
>>> but not everyone does, or is.  Not everyone logs the output of the
>>> kernel build so they can review it later.  I suspect that many just
>>> set the build going in a terminal, walk away and come back sometime
>>> later when they think it's done.
>> 
>> In this case they would have a good trigger and reason to look into the
>> build log: the kernel they just built isn't booting and doesn't tell
>> anything. Then I guess for many of us the next logical step would be to
>> look trough the build log (but not through a defconfig that wasn't touched
>> for ages).
>> 
>> Well, I have to admit that if someone doesn't try a clean build, it
>> will not see it again if the initial log wasn't captured somewhere...
>> 
>> So it should more be an #error than a #warning. Then people must notice.
>> But I don't know if there are situations where this would be too strict.
> 
> There are - it's perfectly valid to have your kernel, but with DEBUG_LL
> enabled and configured correctly so it outputs to a real UART on your
> platform.  As I've explained already, DEBUG_LL exists as a way of last
> resort to solve the "it doesn't boot" problem, because it gives a
> way for the early assembler to be instrumented and debugged before
> anything else is up, through the kernel boot sequence and into the C
> code.

Indeed - except that DEBUG_LL can be the reason for the "it doesn't boot"
which I assume nobody expects. t would be like placing a voltmeter somewhere
and you have power outage.

> 
> That is its primary purpose.  Adding a #error or #warning is going to
> turn people who most need the infrastructure to solve the "it silently
> doesn't boot" away.

This confirms my assumption that a #warning seems more appropriate than
an #error. You can ignore it if you know what you are doing.

> 
> Unfortunately, DEBUG_LL is one of those things that is platform specific,
> it has to be to guarantee output, so situations such as missing DT can
> still produce output.  Unfortunately, it got used for early_printk
> because it was easier to add early_printk rather than telling people
> to add a printascii() call in kernel/printk/printk.c (which is what I
> used to tell people, and what I _still_ do today.)

Yes, I have used printascii() in early days of board bringup (especially
with broken u-boot setup)...

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[Russell King - ARM Linux]

Hi Nikkylos,

On Thu, Nov 09, 2017 at 06:16:29PM +0100, H. Nikolaus Schaller wrote:
> Hi Russel,
> 
> > Am 09.11.2017 um 17:58 schrieb Russell King - ARM Linux 
> > :
> > 
> > On Thu, Nov 09, 2017 at 06:44:49AM +0100, H. Nikolaus Schaller wrote:
> >> Hi Russel,
> > 
> > Nikolus,
> > 
> >>> Am 08.11.2017 um 23:38 schrieb Russell King - ARM Linux 
> >>> :
> >>> 
> >>> On Wed, Nov 08, 2017 at 10:36:04PM +, Russell King - ARM Linux wrote:
>  We don't need a compiler warning there, we probably need better help
>  text against DEBUG_LL and against EARLY_PRINTK.
> >>> 
> >>> Actually, this is already clearly stated against DEBUG_LL:
> >>> 
> >>> Note that selecting this option will limit the kernel to a single
> >>> UART definition, as specified below. Attempting to boot the kernel
> >>> image on a different platform *will not work*, so this option 
> >>> should
> >>> not be enabled for kernels that are intended to be portable.
> >>> 
> >>> and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
> >>> read help texts anymore.
> >> 
> >> Yes, we read, but we face a situation where it doesn't help that it is a
> >> well known problem *for you* or anyone else and that it is described in
> >> the help.
> > 
> > Personally, I'd like early_printk not to be re-using this, but others
> > disagree.  It's all about knowledge and compromise.
> 
> Sure, we have to make a lot of compromises...
> 
> > 
> > What we don't want is more warnings in the kernel - it's already
> > hard enough for people to spot the "bad" warnings that they need to
> > fix to have a working system (such as wrong printf specifiers) that
> > (a) they're not going to spot this #warning and (b) it's just going
> > to be more noise for those who do try to spot the warnings.
> 
> > 
> >> Do you expect anybody to remember after 3 years of *not* changing DEBUG_LL
> >> what was written in a help message? Or to understand that DEBUG_LL has
> >> anything to do with the mysteriously appearing boot problem? Which can't
> >> easily be debugged since there are no messages despite playing with
> >> EARLY_PRINTK/EARLYCON?
> > 
> > Do you expect people to read the build log of their kernel and spot
> > the additional warning?
> 
> I am doing it and I rarely see warnings by the compiler. Maybe sometimes
> during the -rc phase but not in stable.

The warnings you see are compiler specific, and I hardly ever see builds
that are fully clean.

> >  You might be on the ball enough to do that,
> > but not everyone does, or is.  Not everyone logs the output of the
> > kernel build so they can review it later.  I suspect that many just
> > set the build going in a terminal, walk away and come back sometime
> > later when they think it's done.
> 
> In this case they would have a good trigger and reason to look into the
> build log: the kernel they just built isn't booting and doesn't tell
> anything. Then I guess for many of us the next logical step would be to
> look trough the build log (but not through a defconfig that wasn't touched
> for ages).
> 
> Well, I have to admit that if someone doesn't try a clean build, it
> will not see it again if the initial log wasn't captured somewhere...
> 
> So it should more be an #error than a #warning. Then people must notice.
> But I don't know if there are situations where this would be too strict.

There are - it's perfectly valid to have your kernel, but with DEBUG_LL
enabled and configured correctly so it outputs to a real UART on your
platform.  As I've explained already, DEBUG_LL exists as a way of last
resort to solve the "it doesn't boot" problem, because it gives a
way for the early assembler to be instrumented and debugged before
anything else is up, through the kernel boot sequence and into the C
code.

That is its primary purpose.  Adding a #error or #warning is going to
turn people who most need the infrastructure to solve the "it silently
doesn't boot" away.

Unfortunately, DEBUG_LL is one of those things that is platform specific,
it has to be to guarantee output, so situations such as missing DT can
still produce output.  Unfortunately, it got used for early_printk
because it was easier to add early_printk rather than telling people
to add a printascii() call in kernel/printk/printk.c (which is what I
used to tell people, and what I _still_ do today.)

DEBUG_LL has always been intended for this purpose, and it's under the
"debugging" menus, because it's really not meant to be enabled for
production.  If you have folk who have enabled DEBUG_LL in your
configurations, and then left it enabled beyond this level of debugging,
I have to question the competence of that.

DEBUG_LL may be an extreme example of a config option that can land
your kernel in a non-bootable situation, but there are plenty of other
configuration options that will severely degrade the performance of
your kernel.  Should we go around adding #warning's 

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[Russell King - ARM Linux]

Hi Nikkylos,

On Thu, Nov 09, 2017 at 06:16:29PM +0100, H. Nikolaus Schaller wrote:
> Hi Russel,
> 
> > Am 09.11.2017 um 17:58 schrieb Russell King - ARM Linux 
> > :
> > 
> > On Thu, Nov 09, 2017 at 06:44:49AM +0100, H. Nikolaus Schaller wrote:
> >> Hi Russel,
> > 
> > Nikolus,
> > 
> >>> Am 08.11.2017 um 23:38 schrieb Russell King - ARM Linux 
> >>> :
> >>> 
> >>> On Wed, Nov 08, 2017 at 10:36:04PM +, Russell King - ARM Linux wrote:
>  We don't need a compiler warning there, we probably need better help
>  text against DEBUG_LL and against EARLY_PRINTK.
> >>> 
> >>> Actually, this is already clearly stated against DEBUG_LL:
> >>> 
> >>> Note that selecting this option will limit the kernel to a single
> >>> UART definition, as specified below. Attempting to boot the kernel
> >>> image on a different platform *will not work*, so this option 
> >>> should
> >>> not be enabled for kernels that are intended to be portable.
> >>> 
> >>> and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
> >>> read help texts anymore.
> >> 
> >> Yes, we read, but we face a situation where it doesn't help that it is a
> >> well known problem *for you* or anyone else and that it is described in
> >> the help.
> > 
> > Personally, I'd like early_printk not to be re-using this, but others
> > disagree.  It's all about knowledge and compromise.
> 
> Sure, we have to make a lot of compromises...
> 
> > 
> > What we don't want is more warnings in the kernel - it's already
> > hard enough for people to spot the "bad" warnings that they need to
> > fix to have a working system (such as wrong printf specifiers) that
> > (a) they're not going to spot this #warning and (b) it's just going
> > to be more noise for those who do try to spot the warnings.
> 
> > 
> >> Do you expect anybody to remember after 3 years of *not* changing DEBUG_LL
> >> what was written in a help message? Or to understand that DEBUG_LL has
> >> anything to do with the mysteriously appearing boot problem? Which can't
> >> easily be debugged since there are no messages despite playing with
> >> EARLY_PRINTK/EARLYCON?
> > 
> > Do you expect people to read the build log of their kernel and spot
> > the additional warning?
> 
> I am doing it and I rarely see warnings by the compiler. Maybe sometimes
> during the -rc phase but not in stable.

The warnings you see are compiler specific, and I hardly ever see builds
that are fully clean.

> >  You might be on the ball enough to do that,
> > but not everyone does, or is.  Not everyone logs the output of the
> > kernel build so they can review it later.  I suspect that many just
> > set the build going in a terminal, walk away and come back sometime
> > later when they think it's done.
> 
> In this case they would have a good trigger and reason to look into the
> build log: the kernel they just built isn't booting and doesn't tell
> anything. Then I guess for many of us the next logical step would be to
> look trough the build log (but not through a defconfig that wasn't touched
> for ages).
> 
> Well, I have to admit that if someone doesn't try a clean build, it
> will not see it again if the initial log wasn't captured somewhere...
> 
> So it should more be an #error than a #warning. Then people must notice.
> But I don't know if there are situations where this would be too strict.

There are - it's perfectly valid to have your kernel, but with DEBUG_LL
enabled and configured correctly so it outputs to a real UART on your
platform.  As I've explained already, DEBUG_LL exists as a way of last
resort to solve the "it doesn't boot" problem, because it gives a
way for the early assembler to be instrumented and debugged before
anything else is up, through the kernel boot sequence and into the C
code.

That is its primary purpose.  Adding a #error or #warning is going to
turn people who most need the infrastructure to solve the "it silently
doesn't boot" away.

Unfortunately, DEBUG_LL is one of those things that is platform specific,
it has to be to guarantee output, so situations such as missing DT can
still produce output.  Unfortunately, it got used for early_printk
because it was easier to add early_printk rather than telling people
to add a printascii() call in kernel/printk/printk.c (which is what I
used to tell people, and what I _still_ do today.)

DEBUG_LL has always been intended for this purpose, and it's under the
"debugging" menus, because it's really not meant to be enabled for
production.  If you have folk who have enabled DEBUG_LL in your
configurations, and then left it enabled beyond this level of debugging,
I have to question the competence of that.

DEBUG_LL may be an extreme example of a config option that can land
your kernel in a non-bootable situation, but there are plenty of other
configuration options that will severely degrade the performance of
your kernel.  Should we go around adding #warning's for those as well?

I know that the kernel 

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[H. Nikolaus Schaller]

Hi Russel,

> Am 09.11.2017 um 17:58 schrieb Russell King - ARM Linux 
> :
> 
> On Thu, Nov 09, 2017 at 06:44:49AM +0100, H. Nikolaus Schaller wrote:
>> Hi Russel,
> 
> Nikolus,
> 
>>> Am 08.11.2017 um 23:38 schrieb Russell King - ARM Linux 
>>> :
>>> 
>>> On Wed, Nov 08, 2017 at 10:36:04PM +, Russell King - ARM Linux wrote:
 We don't need a compiler warning there, we probably need better help
 text against DEBUG_LL and against EARLY_PRINTK.
>>> 
>>> Actually, this is already clearly stated against DEBUG_LL:
>>> 
>>> Note that selecting this option will limit the kernel to a single
>>> UART definition, as specified below. Attempting to boot the kernel
>>> image on a different platform *will not work*, so this option should
>>> not be enabled for kernels that are intended to be portable.
>>> 
>>> and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
>>> read help texts anymore.
>> 
>> Yes, we read, but we face a situation where it doesn't help that it is a
>> well known problem *for you* or anyone else and that it is described in
>> the help.
> 
> Personally, I'd like early_printk not to be re-using this, but others
> disagree.  It's all about knowledge and compromise.

Sure, we have to make a lot of compromises...

> 
> What we don't want is more warnings in the kernel - it's already
> hard enough for people to spot the "bad" warnings that they need to
> fix to have a working system (such as wrong printf specifiers) that
> (a) they're not going to spot this #warning and (b) it's just going
> to be more noise for those who do try to spot the warnings.

> 
>> Do you expect anybody to remember after 3 years of *not* changing DEBUG_LL
>> what was written in a help message? Or to understand that DEBUG_LL has
>> anything to do with the mysteriously appearing boot problem? Which can't
>> easily be debugged since there are no messages despite playing with
>> EARLY_PRINTK/EARLYCON?
> 
> Do you expect people to read the build log of their kernel and spot
> the additional warning?

I am doing it and I rarely see warnings by the compiler. Maybe sometimes
during the -rc phase but not in stable.

>  You might be on the ball enough to do that,
> but not everyone does, or is.  Not everyone logs the output of the
> kernel build so they can review it later.  I suspect that many just
> set the build going in a terminal, walk away and come back sometime
> later when they think it's done.

In this case they would have a good trigger and reason to look into the
build log: the kernel they just built isn't booting and doesn't tell
anything. Then I guess for many of us the next logical step would be to
look trough the build log (but not through a defconfig that wasn't touched
for ages).

Well, I have to admit that if someone doesn't try a clean build, it
will not see it again if the initial log wasn't captured somewhere...

So it should more be an #error than a #warning. Then people must notice.
But I don't know if there are situations where this would be too strict.

And in this special case someone may even have the idea to enable DEBUG_LL
to get better error reporting - but find it is already enabled. Not knowing
that this is the reason of the problem. This is what IMHO makes this case
very special.

Or the other option would be to automatically disable DEBUG_LL if it
conflicts. Then, there is no need for a warning that could be ignored.

>  (This view is based upon the number
> of warnings that I've seen crop up that are for things that are real
> bugs that others have introduced - had the warnings been spotted, it
> would've triggered a "oh, that's not right" moment.)

BR and thanks,
Nikolaus

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[H. Nikolaus Schaller]

Hi Russel,

> Am 09.11.2017 um 17:58 schrieb Russell King - ARM Linux 
> :
> 
> On Thu, Nov 09, 2017 at 06:44:49AM +0100, H. Nikolaus Schaller wrote:
>> Hi Russel,
> 
> Nikolus,
> 
>>> Am 08.11.2017 um 23:38 schrieb Russell King - ARM Linux 
>>> :
>>> 
>>> On Wed, Nov 08, 2017 at 10:36:04PM +, Russell King - ARM Linux wrote:
 We don't need a compiler warning there, we probably need better help
 text against DEBUG_LL and against EARLY_PRINTK.
>>> 
>>> Actually, this is already clearly stated against DEBUG_LL:
>>> 
>>> Note that selecting this option will limit the kernel to a single
>>> UART definition, as specified below. Attempting to boot the kernel
>>> image on a different platform *will not work*, so this option should
>>> not be enabled for kernels that are intended to be portable.
>>> 
>>> and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
>>> read help texts anymore.
>> 
>> Yes, we read, but we face a situation where it doesn't help that it is a
>> well known problem *for you* or anyone else and that it is described in
>> the help.
> 
> Personally, I'd like early_printk not to be re-using this, but others
> disagree.  It's all about knowledge and compromise.

Sure, we have to make a lot of compromises...

> 
> What we don't want is more warnings in the kernel - it's already
> hard enough for people to spot the "bad" warnings that they need to
> fix to have a working system (such as wrong printf specifiers) that
> (a) they're not going to spot this #warning and (b) it's just going
> to be more noise for those who do try to spot the warnings.

> 
>> Do you expect anybody to remember after 3 years of *not* changing DEBUG_LL
>> what was written in a help message? Or to understand that DEBUG_LL has
>> anything to do with the mysteriously appearing boot problem? Which can't
>> easily be debugged since there are no messages despite playing with
>> EARLY_PRINTK/EARLYCON?
> 
> Do you expect people to read the build log of their kernel and spot
> the additional warning?

I am doing it and I rarely see warnings by the compiler. Maybe sometimes
during the -rc phase but not in stable.

>  You might be on the ball enough to do that,
> but not everyone does, or is.  Not everyone logs the output of the
> kernel build so they can review it later.  I suspect that many just
> set the build going in a terminal, walk away and come back sometime
> later when they think it's done.

In this case they would have a good trigger and reason to look into the
build log: the kernel they just built isn't booting and doesn't tell
anything. Then I guess for many of us the next logical step would be to
look trough the build log (but not through a defconfig that wasn't touched
for ages).

Well, I have to admit that if someone doesn't try a clean build, it
will not see it again if the initial log wasn't captured somewhere...

So it should more be an #error than a #warning. Then people must notice.
But I don't know if there are situations where this would be too strict.

And in this special case someone may even have the idea to enable DEBUG_LL
to get better error reporting - but find it is already enabled. Not knowing
that this is the reason of the problem. This is what IMHO makes this case
very special.

Or the other option would be to automatically disable DEBUG_LL if it
conflicts. Then, there is no need for a warning that could be ignored.

>  (This view is based upon the number
> of warnings that I've seen crop up that are for things that are real
> bugs that others have introduced - had the warnings been spotted, it
> would've triggered a "oh, that's not right" moment.)

BR and thanks,
Nikolaus

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[Russell King - ARM Linux]

On Thu, Nov 09, 2017 at 06:44:49AM +0100, H. Nikolaus Schaller wrote:
> Hi Russel,

Nikolus,

> > Am 08.11.2017 um 23:38 schrieb Russell King - ARM Linux 
> > :
> > 
> > On Wed, Nov 08, 2017 at 10:36:04PM +, Russell King - ARM Linux wrote:
> >> We don't need a compiler warning there, we probably need better help
> >> text against DEBUG_LL and against EARLY_PRINTK.
> > 
> > Actually, this is already clearly stated against DEBUG_LL:
> > 
> >  Note that selecting this option will limit the kernel to a single
> >  UART definition, as specified below. Attempting to boot the kernel
> >  image on a different platform *will not work*, so this option 
> > should
> >  not be enabled for kernels that are intended to be portable.
> > 
> > and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
> > read help texts anymore.
> 
> Yes, we read, but we face a situation where it doesn't help that it is a
> well known problem *for you* or anyone else and that it is described in
> the help.

Personally, I'd like early_printk not to be re-using this, but others
disagree.  It's all about knowledge and compromise.

What we don't want is more warnings in the kernel - it's already
hard enough for people to spot the "bad" warnings that they need to
fix to have a working system (such as wrong printf specifiers) that
(a) they're not going to spot this #warning and (b) it's just going
to be more noise for those who do try to spot the warnings.

> Do you expect anybody to remember after 3 years of *not* changing DEBUG_LL
> what was written in a help message? Or to understand that DEBUG_LL has
> anything to do with the mysteriously appearing boot problem? Which can't
> easily be debugged since there are no messages despite playing with
> EARLY_PRINTK/EARLYCON?

Do you expect people to read the build log of their kernel and spot
the additional warning?  You might be on the ball enough to do that,
but not everyone does, or is.  Not everyone logs the output of the
kernel build so they can review it later.  I suspect that many just
set the build going in a terminal, walk away and come back sometime
later when they think it's done.  (This view is based upon the number
of warnings that I've seen crop up that are for things that are real
bugs that others have introduced - had the warnings been spotted, it
would've triggered a "oh, that's not right" moment.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[Russell King - ARM Linux]

On Thu, Nov 09, 2017 at 06:44:49AM +0100, H. Nikolaus Schaller wrote:
> Hi Russel,

Nikolus,

> > Am 08.11.2017 um 23:38 schrieb Russell King - ARM Linux 
> > :
> > 
> > On Wed, Nov 08, 2017 at 10:36:04PM +, Russell King - ARM Linux wrote:
> >> We don't need a compiler warning there, we probably need better help
> >> text against DEBUG_LL and against EARLY_PRINTK.
> > 
> > Actually, this is already clearly stated against DEBUG_LL:
> > 
> >  Note that selecting this option will limit the kernel to a single
> >  UART definition, as specified below. Attempting to boot the kernel
> >  image on a different platform *will not work*, so this option 
> > should
> >  not be enabled for kernels that are intended to be portable.
> > 
> > and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
> > read help texts anymore.
> 
> Yes, we read, but we face a situation where it doesn't help that it is a
> well known problem *for you* or anyone else and that it is described in
> the help.

Personally, I'd like early_printk not to be re-using this, but others
disagree.  It's all about knowledge and compromise.

What we don't want is more warnings in the kernel - it's already
hard enough for people to spot the "bad" warnings that they need to
fix to have a working system (such as wrong printf specifiers) that
(a) they're not going to spot this #warning and (b) it's just going
to be more noise for those who do try to spot the warnings.

> Do you expect anybody to remember after 3 years of *not* changing DEBUG_LL
> what was written in a help message? Or to understand that DEBUG_LL has
> anything to do with the mysteriously appearing boot problem? Which can't
> easily be debugged since there are no messages despite playing with
> EARLY_PRINTK/EARLYCON?

Do you expect people to read the build log of their kernel and spot
the additional warning?  You might be on the ball enough to do that,
but not everyone does, or is.  Not everyone logs the output of the
kernel build so they can review it later.  I suspect that many just
set the build going in a terminal, walk away and come back sometime
later when they think it's done.  (This view is based upon the number
of warnings that I've seen crop up that are for things that are real
bugs that others have introduced - had the warnings been spotted, it
would've triggered a "oh, that's not right" moment.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[H. Nikolaus Schaller]

Hi Russel,

> Am 08.11.2017 um 23:38 schrieb Russell King - ARM Linux 
> :
> 
> On Wed, Nov 08, 2017 at 10:36:04PM +, Russell King - ARM Linux wrote:
>> We don't need a compiler warning there, we probably need better help
>> text against DEBUG_LL and against EARLY_PRINTK.
> 
> Actually, this is already clearly stated against DEBUG_LL:
> 
>  Note that selecting this option will limit the kernel to a single
>  UART definition, as specified below. Attempting to boot the kernel
>  image on a different platform *will not work*, so this option should
>  not be enabled for kernels that are intended to be portable.
> 
> and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
> read help texts anymore.

Yes, we read, but we face a situation where it doesn't help that it is a
well known problem *for you* or anyone else and that it is described in the 
help.

We simply had a private defconfig for years and someone enabled DEBUG_LL some
years ago and it worked.

Then we upgrade the kernel for every -rc and it continued to work well. Then,
recently when doing just one update the compiled kernel failed to boot. Nobody
did change and look at the defconfig and its help. We just merged the latest
patches from linus/master.

Do you expect anybody to remember after 3 years of *not* changing DEBUG_LL what
was written in a help message? Or to understand that DEBUG_LL has anything to
do with the mysteriously appearing boot problem? Which can't easily be debugged
since there are no messages despite playing with EARLY_PRINTK/EARLYCON?

It took me several hours of git bisect to find out the problematic commits
and needed help by the author to relate it to DEBUG_LL in the defconfig.

So we are coming from the other end with much less knowledge than you have.
Linux has grown to be a beast that only a handful of people fully understand.
And this patch is to help those poor production kernel maintainers like me
who don't...

A technically different solution would be to automatically disable DEBUG_LL
if it is not compatible with some other setting.

BTW it appears that there was similar code elsewhere long time ago:

http://elixir.free-electrons.com/linux/v3.1.10/source/arch/arm/plat-mxc/include/mach/debug-macro.S

BR and thanks,
Nikolaus Schaller

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[H. Nikolaus Schaller]

Hi Russel,

> Am 08.11.2017 um 23:38 schrieb Russell King - ARM Linux 
> :
> 
> On Wed, Nov 08, 2017 at 10:36:04PM +, Russell King - ARM Linux wrote:
>> We don't need a compiler warning there, we probably need better help
>> text against DEBUG_LL and against EARLY_PRINTK.
> 
> Actually, this is already clearly stated against DEBUG_LL:
> 
>  Note that selecting this option will limit the kernel to a single
>  UART definition, as specified below. Attempting to boot the kernel
>  image on a different platform *will not work*, so this option should
>  not be enabled for kernels that are intended to be portable.
> 
> and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
> read help texts anymore.

Yes, we read, but we face a situation where it doesn't help that it is a
well known problem *for you* or anyone else and that it is described in the 
help.

We simply had a private defconfig for years and someone enabled DEBUG_LL some
years ago and it worked.

Then we upgrade the kernel for every -rc and it continued to work well. Then,
recently when doing just one update the compiled kernel failed to boot. Nobody
did change and look at the defconfig and its help. We just merged the latest
patches from linus/master.

Do you expect anybody to remember after 3 years of *not* changing DEBUG_LL what
was written in a help message? Or to understand that DEBUG_LL has anything to
do with the mysteriously appearing boot problem? Which can't easily be debugged
since there are no messages despite playing with EARLY_PRINTK/EARLYCON?

It took me several hours of git bisect to find out the problematic commits
and needed help by the author to relate it to DEBUG_LL in the defconfig.

So we are coming from the other end with much less knowledge than you have.
Linux has grown to be a beast that only a handful of people fully understand.
And this patch is to help those poor production kernel maintainers like me
who don't...

A technically different solution would be to automatically disable DEBUG_LL
if it is not compatible with some other setting.

BTW it appears that there was similar code elsewhere long time ago:

http://elixir.free-electrons.com/linux/v3.1.10/source/arch/arm/plat-mxc/include/mach/debug-macro.S

BR and thanks,
Nikolaus Schaller

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[Russell King - ARM Linux]

On Wed, Nov 08, 2017 at 10:36:04PM +, Russell King - ARM Linux wrote:
> We don't need a compiler warning there, we probably need better help
> text against DEBUG_LL and against EARLY_PRINTK.

Actually, this is already clearly stated against DEBUG_LL:

  Note that selecting this option will limit the kernel to a single
  UART definition, as specified below. Attempting to boot the kernel
  image on a different platform *will not work*, so this option should
  not be enabled for kernels that are intended to be portable.

and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
read help texts anymore.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[Russell King - ARM Linux]

On Wed, Nov 08, 2017 at 10:36:04PM +, Russell King - ARM Linux wrote:
> We don't need a compiler warning there, we probably need better help
> text against DEBUG_LL and against EARLY_PRINTK.

Actually, this is already clearly stated against DEBUG_LL:

  Note that selecting this option will limit the kernel to a single
  UART definition, as specified below. Attempting to boot the kernel
  image on a different platform *will not work*, so this option should
  not be enabled for kernels that are intended to be portable.

and since EARLY_PRINTK depends on DEBUG_LL... I guess people don't
read help texts anymore.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[Russell King - ARM Linux]

On Wed, Nov 08, 2017 at 02:27:55PM -0800, Tony Lindgren wrote:
> * H. Nikolaus Schaller  [171108 21:32]:
> > commit d2b310b0234c ("ARM: debug: Use generic 8250 debug_ll for omap2 and 
> > omap3/4/5 common uarts")
> > commit fc23beb8a577 ("ARM: debug: Use generic 8250 debug_ll for omap3/4/5")
> > 
> > switched to generic 8250 debug_ll code which seems to be incompatible
> > with at least OMAP5 boards (OMAP5EVM, Pyra) if CONFIG_DEBUG_LL is
> > still enabled in some legacy defconfig. Since this is very hard to
> > relate to these patches and difficult to identify, let's have the
> > compiler emit a warning.
> 
> Hmm the issue is the existing values in .config as Kconfig.debug
> does default XXX if DEBUG_XXX, right?
> 
> I think we have this issue in general if you enable DEBUG_LL for
> a SoC, then enable it for another SoC using the same .config?

As I keep saying, DEBUG_LL is the low level debugging code, which is
there to support people trying to debug the early bringup.  It can
only be configured for use with one particular port.  If that doesn't
match the SoC, then, if you make use of the DEBUG_LL code, it will
fail to boot.

Unfortunately, if you use early_printk rather than earlycon, as
early_printk uses the DEBUG_LL bits, it means that your early_printk
kernel is tied to the selected platform.

All well known issues.  early_printk should not be used in a multi-
platform kernel for this very reason.

We don't need a compiler warning there, we probably need better help
text against DEBUG_LL and against EARLY_PRINTK.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[Russell King - ARM Linux]

On Wed, Nov 08, 2017 at 02:27:55PM -0800, Tony Lindgren wrote:
> * H. Nikolaus Schaller  [171108 21:32]:
> > commit d2b310b0234c ("ARM: debug: Use generic 8250 debug_ll for omap2 and 
> > omap3/4/5 common uarts")
> > commit fc23beb8a577 ("ARM: debug: Use generic 8250 debug_ll for omap3/4/5")
> > 
> > switched to generic 8250 debug_ll code which seems to be incompatible
> > with at least OMAP5 boards (OMAP5EVM, Pyra) if CONFIG_DEBUG_LL is
> > still enabled in some legacy defconfig. Since this is very hard to
> > relate to these patches and difficult to identify, let's have the
> > compiler emit a warning.
> 
> Hmm the issue is the existing values in .config as Kconfig.debug
> does default XXX if DEBUG_XXX, right?
> 
> I think we have this issue in general if you enable DEBUG_LL for
> a SoC, then enable it for another SoC using the same .config?

As I keep saying, DEBUG_LL is the low level debugging code, which is
there to support people trying to debug the early bringup.  It can
only be configured for use with one particular port.  If that doesn't
match the SoC, then, if you make use of the DEBUG_LL code, it will
fail to boot.

Unfortunately, if you use early_printk rather than earlycon, as
early_printk uses the DEBUG_LL bits, it means that your early_printk
kernel is tied to the selected platform.

All well known issues.  early_printk should not be used in a multi-
platform kernel for this very reason.

We don't need a compiler warning there, we probably need better help
text against DEBUG_LL and against EARLY_PRINTK.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[Tony Lindgren]

* H. Nikolaus Schaller  [171108 21:32]:
> commit d2b310b0234c ("ARM: debug: Use generic 8250 debug_ll for omap2 and 
> omap3/4/5 common uarts")
> commit fc23beb8a577 ("ARM: debug: Use generic 8250 debug_ll for omap3/4/5")
> 
> switched to generic 8250 debug_ll code which seems to be incompatible
> with at least OMAP5 boards (OMAP5EVM, Pyra) if CONFIG_DEBUG_LL is
> still enabled in some legacy defconfig. Since this is very hard to
> relate to these patches and difficult to identify, let's have the
> compiler emit a warning.

Hmm the issue is the existing values in .config as Kconfig.debug
does default XXX if DEBUG_XXX, right?

I think we have this issue in general if you enable DEBUG_LL for
a SoC, then enable it for another SoC using the same .config?

Regards,

Tony

Re: [PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[Tony Lindgren]

* H. Nikolaus Schaller  [171108 21:32]:
> commit d2b310b0234c ("ARM: debug: Use generic 8250 debug_ll for omap2 and 
> omap3/4/5 common uarts")
> commit fc23beb8a577 ("ARM: debug: Use generic 8250 debug_ll for omap3/4/5")
> 
> switched to generic 8250 debug_ll code which seems to be incompatible
> with at least OMAP5 boards (OMAP5EVM, Pyra) if CONFIG_DEBUG_LL is
> still enabled in some legacy defconfig. Since this is very hard to
> relate to these patches and difficult to identify, let's have the
> compiler emit a warning.

Hmm the issue is the existing values in .config as Kconfig.debug
does default XXX if DEBUG_XXX, right?

I think we have this issue in general if you enable DEBUG_LL for
a SoC, then enable it for another SoC using the same .config?

Regards,

Tony

[PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[H. Nikolaus Schaller]

commit d2b310b0234c ("ARM: debug: Use generic 8250 debug_ll for omap2 and 
omap3/4/5 common uarts")
commit fc23beb8a577 ("ARM: debug: Use generic 8250 debug_ll for omap3/4/5")

switched to generic 8250 debug_ll code which seems to be incompatible
with at least OMAP5 boards (OMAP5EVM, Pyra) if CONFIG_DEBUG_LL is
still enabled in some legacy defconfig. Since this is very hard to
relate to these patches and difficult to identify, let's have the
compiler emit a warning.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/include/debug/omap2plus.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/include/debug/omap2plus.S 
b/arch/arm/include/debug/omap2plus.S
index 192a7583999c..3e7ea21cde2a 100644
--- a/arch/arm/include/debug/omap2plus.S
+++ b/arch/arm/include/debug/omap2plus.S
@@ -12,6 +12,10 @@
 
 #include 
 
+#if defined(CONFIG_DEBUG_LL)
+#warning Please disable CONFIG_DEBUG_LL and enable CONFIG_SERIAL_EARLYCON or 
OMAP5 devices will not boot
+#endif
+
 /* External port on Zoom2/3 */
 #define ZOOM_UART_BASE 0x1000
 #define ZOOM_UART_VIRT 0xfa40
-- 
2.12.2

[PATCH] Kernel debugging: omap: print warning if CONFIG_DEBUG_LL is enabled

[H. Nikolaus Schaller]

commit d2b310b0234c ("ARM: debug: Use generic 8250 debug_ll for omap2 and 
omap3/4/5 common uarts")
commit fc23beb8a577 ("ARM: debug: Use generic 8250 debug_ll for omap3/4/5")

switched to generic 8250 debug_ll code which seems to be incompatible
with at least OMAP5 boards (OMAP5EVM, Pyra) if CONFIG_DEBUG_LL is
still enabled in some legacy defconfig. Since this is very hard to
relate to these patches and difficult to identify, let's have the
compiler emit a warning.

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/include/debug/omap2plus.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/include/debug/omap2plus.S 
b/arch/arm/include/debug/omap2plus.S
index 192a7583999c..3e7ea21cde2a 100644
--- a/arch/arm/include/debug/omap2plus.S
+++ b/arch/arm/include/debug/omap2plus.S
@@ -12,6 +12,10 @@
 
 #include 
 
+#if defined(CONFIG_DEBUG_LL)
+#warning Please disable CONFIG_DEBUG_LL and enable CONFIG_SERIAL_EARLYCON or 
OMAP5 devices will not boot
+#endif
+
 /* External port on Zoom2/3 */
 #define ZOOM_UART_BASE 0x1000
 #define ZOOM_UART_VIRT 0xfa40
-- 
2.12.2

[PATCH v12 00/28] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Hi Andrew,

this is an update to address the review comments provided by Michal
Marek on v11.

Changes since v11:
 - drop redundant subdir rule
 - fold *.pyo into existing clean-files rules

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

Jan

CC: Daniel Thompson 
CC: Daniel Wagner 
CC: "David S. Miller" 
CC: Fenghua Yu 
Cc: Jan Kiszka 
CC: Kay Sievers 
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
Cc: Michal Marek 
CC: Michal Marek 
CC: Pantelis Koukousoulas 
CC: Rob Landley 
CC: Rusty Russell 
CC: sparcli...@vger.kernel.org
CC: Tony Luck 

Daniel Thompson (1):
  scripts/gdb: Ignore byte-compiled python files

Daniel Wagner (1):
  scripts/gdb: Use a generator instead of iterator for task list

Jan Kiszka (25):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation
  scripts/gdb: Convert ModuleList to generator function
  scripts/gdb: Convert CpuList to generator function
  scripts/gdb: Define maintainer
  scripts/gdb: Disable pagination while printing from breakpoint handler

Pantelis Koukousoulas (1):
  scripts/gdb: Port to python3 / gdb7.7

 .gitignore |   1 +
 Documentation/gdb-kernel-debugging.txt | 160 +
 MAINTAINERS|   5 +
 Makefile   |   5 +-
 kernel/module.c|   9 +-
 lib/Kconfig.debug  |  11 ++
 scripts/Makefile   |   1 +
 scripts/gdb/Makefile   |   1 +
 scripts/gdb/linux/.gitignore   |   2 +
 scripts/gdb/linux/Makefile |  11 ++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 135 +
 scripts/gdb/linux/dmesg.py |  65 
 scripts/gdb/linux/modules.py   | 103 +++
 scripts/gdb/linux/symbols.py   | 177 +
 scripts/gdb/linux/tasks.py | 100 +++
 scripts/gdb/linux/utils.py | 156 +
 scripts/gdb/vmlinux-gdb.py |  30 ++
 18 files changed, 969 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/.gitignore
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v12 00/28] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Hi Andrew,

this is an update to address the review comments provided by Michal
Marek on v11.

Changes since v11:
 - drop redundant subdir rule
 - fold *.pyo into existing clean-files rules

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

Jan

CC: Daniel Thompson daniel.thomp...@linaro.org
CC: Daniel Wagner daniel.wag...@bmw-carit.de
CC: David S. Miller da...@davemloft.net
CC: Fenghua Yu fenghua...@intel.com
Cc: Jan Kiszka jan.kis...@siemens.com
CC: Kay Sievers k...@vrfy.org
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
Cc: Michal Marek mma...@suse.cz
CC: Michal Marek mma...@suse.cz
CC: Pantelis Koukousoulas pkt...@gmail.com
CC: Rob Landley r...@landley.net
CC: Rusty Russell ru...@rustcorp.com.au
CC: sparcli...@vger.kernel.org
CC: Tony Luck tony.l...@intel.com

Daniel Thompson (1):
  scripts/gdb: Ignore byte-compiled python files

Daniel Wagner (1):
  scripts/gdb: Use a generator instead of iterator for task list

Jan Kiszka (25):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation
  scripts/gdb: Convert ModuleList to generator function
  scripts/gdb: Convert CpuList to generator function
  scripts/gdb: Define maintainer
  scripts/gdb: Disable pagination while printing from breakpoint handler

Pantelis Koukousoulas (1):
  scripts/gdb: Port to python3 / gdb7.7

 .gitignore |   1 +
 Documentation/gdb-kernel-debugging.txt | 160 +
 MAINTAINERS|   5 +
 Makefile   |   5 +-
 kernel/module.c|   9 +-
 lib/Kconfig.debug  |  11 ++
 scripts/Makefile   |   1 +
 scripts/gdb/Makefile   |   1 +
 scripts/gdb/linux/.gitignore   |   2 +
 scripts/gdb/linux/Makefile |  11 ++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 135 +
 scripts/gdb/linux/dmesg.py |  65 
 scripts/gdb/linux/modules.py   | 103 +++
 scripts/gdb/linux/symbols.py   | 177 +
 scripts/gdb/linux/tasks.py | 100 +++
 scripts/gdb/linux/utils.py | 156 +
 scripts/gdb/vmlinux-gdb.py |  30 ++
 18 files changed, 969 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/.gitignore
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 00/28] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Hi Andrew,

here comes the requested update of the series.

Changes since v10:
 - rebase over recent Linus master (rc6+)
 - fix stuck gdb pagination during modprobe related symbol reloading

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

On the gdb upstream front there is good and bad news again. The good
news is that the regression reported in the last round was fixed now
[1]. The bad news is that upcoming 7.9 has a new regression that is even
causing a crash of the target kernel [2]. So the recommendation is still
to stick with gdb 7.7.

Jan

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=17642
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=17837

CC: Daniel Thompson 
CC: Daniel Wagner 
CC: "David S. Miller" 
CC: Fenghua Yu 
Cc: Jan Kiszka 
CC: Kay Sievers 
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
Cc: Michal Marek 
CC: Michal Marek 
CC: Pantelis Koukousoulas 
CC: Rob Landley 
CC: Rusty Russell 
CC: sparcli...@vger.kernel.org
CC: Tony Luck 

Daniel Thompson (1):
  scripts/gdb: Ignore byte-compiled python files

Daniel Wagner (1):
  scripts/gdb: Use a generator instead of iterator for task list

Jan Kiszka (25):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation
  scripts/gdb: Convert ModuleList to generator function
  scripts/gdb: Convert CpuList to generator function
  scripts/gdb: Define maintainer
  scripts/gdb: Disable pagination while printing from breakpoint handler

Pantelis Koukousoulas (1):
  scripts/gdb: Port to python3 / gdb7.7

 .gitignore |   1 +
 Documentation/gdb-kernel-debugging.txt | 160 +
 MAINTAINERS|   5 +
 Makefile   |   6 +-
 kernel/module.c|   9 +-
 lib/Kconfig.debug  |  11 ++
 scripts/Makefile   |   3 +-
 scripts/gdb/Makefile   |   1 +
 scripts/gdb/linux/.gitignore   |   2 +
 scripts/gdb/linux/Makefile |  11 ++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 135 +
 scripts/gdb/linux/dmesg.py |  65 
 scripts/gdb/linux/modules.py   | 103 +++
 scripts/gdb/linux/symbols.py   | 177 +
 scripts/gdb/linux/tasks.py | 100 +++
 scripts/gdb/linux/utils.py | 156 +
 scripts/gdb/vmlinux-gdb.py |  30 ++
 18 files changed, 971 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/.gitignore
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v11 00/28] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Hi Andrew,

here comes the requested update of the series.

Changes since v10:
 - rebase over recent Linus master (rc6+)
 - fix stuck gdb pagination during modprobe related symbol reloading

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

On the gdb upstream front there is good and bad news again. The good
news is that the regression reported in the last round was fixed now
[1]. The bad news is that upcoming 7.9 has a new regression that is even
causing a crash of the target kernel [2]. So the recommendation is still
to stick with gdb 7.7.

Jan

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=17642
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=17837

CC: Daniel Thompson daniel.thomp...@linaro.org
CC: Daniel Wagner daniel.wag...@bmw-carit.de
CC: David S. Miller da...@davemloft.net
CC: Fenghua Yu fenghua...@intel.com
Cc: Jan Kiszka jan.kis...@siemens.com
CC: Kay Sievers k...@vrfy.org
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
Cc: Michal Marek mma...@suse.cz
CC: Michal Marek mma...@suse.cz
CC: Pantelis Koukousoulas pkt...@gmail.com
CC: Rob Landley r...@landley.net
CC: Rusty Russell ru...@rustcorp.com.au
CC: sparcli...@vger.kernel.org
CC: Tony Luck tony.l...@intel.com

Daniel Thompson (1):
  scripts/gdb: Ignore byte-compiled python files

Daniel Wagner (1):
  scripts/gdb: Use a generator instead of iterator for task list

Jan Kiszka (25):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation
  scripts/gdb: Convert ModuleList to generator function
  scripts/gdb: Convert CpuList to generator function
  scripts/gdb: Define maintainer
  scripts/gdb: Disable pagination while printing from breakpoint handler

Pantelis Koukousoulas (1):
  scripts/gdb: Port to python3 / gdb7.7

 .gitignore |   1 +
 Documentation/gdb-kernel-debugging.txt | 160 +
 MAINTAINERS|   5 +
 Makefile   |   6 +-
 kernel/module.c|   9 +-
 lib/Kconfig.debug  |  11 ++
 scripts/Makefile   |   3 +-
 scripts/gdb/Makefile   |   1 +
 scripts/gdb/linux/.gitignore   |   2 +
 scripts/gdb/linux/Makefile |  11 ++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 135 +
 scripts/gdb/linux/dmesg.py |  65 
 scripts/gdb/linux/modules.py   | 103 +++
 scripts/gdb/linux/symbols.py   | 177 +
 scripts/gdb/linux/tasks.py | 100 +++
 scripts/gdb/linux/utils.py | 156 +
 scripts/gdb/vmlinux-gdb.py |  30 ++
 18 files changed, 971 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/.gitignore
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v10 00/27] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Hi Thomas,

as discussed earlier today, I'm sending out a fresh rebase of the gdb
scripts so that you can organize the next steps towards merge. Thanks
for this in advance!

Changes since v9:
 - rebase over recent Linux version
 - use a generator instead of iterator for task list,
   fixes thread-group iteration [Daniel Wagner]
 - apply generator scheme on other iterations
 - propose myself as maintainer

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

There is still some issue with gdb >= 7.8 when parsing symbols of kernel
modules, because I didn't deliver those folks the requested core dump of
gdb so far - done now. So up to version 7.7 remains recommended for the
time being.

Jan

CC: Daniel Thompson 
CC: Daniel Wagner 
CC: "David S. Miller" 
CC: Fenghua Yu 
Cc: Jan Kiszka 
CC: Kay Sievers 
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
Cc: Michal Marek 
CC: Michal Marek 
CC: Pantelis Koukousoulas 
CC: Rob Landley 
CC: Rusty Russell 
CC: sparcli...@vger.kernel.org
CC: Tony Luck 

Daniel Thompson (1):
  scripts/gdb: Ignore byte-compiled python files

Daniel Wagner (1):
  scripts/gdb: Use a generator instead of iterator for task list

Jan Kiszka (24):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation
  scripts/gdb: Convert ModuleList to generator function
  scripts/gdb: Convert CpuList to generator function
  scripts/gdb: Define maintainer

Pantelis Koukousoulas (1):
  scripts/gdb: Port to python3 / gdb7.7

 .gitignore |   1 +
 Documentation/gdb-kernel-debugging.txt | 160 +++
 MAINTAINERS|   5 +
 Makefile   |   6 +-
 kernel/module.c|   9 +-
 lib/Kconfig.debug  |  11 +++
 scripts/Makefile   |   3 +-
 scripts/gdb/Makefile   |   1 +
 scripts/gdb/linux/.gitignore   |   2 +
 scripts/gdb/linux/Makefile |  11 +++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 135 +++
 scripts/gdb/linux/dmesg.py |  65 +
 scripts/gdb/linux/modules.py   | 103 
 scripts/gdb/linux/symbols.py   | 166 +
 scripts/gdb/linux/tasks.py | 100 
 scripts/gdb/linux/utils.py | 156 +++
 scripts/gdb/vmlinux-gdb.py |  30 ++
 18 files changed, 960 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/.gitignore
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
1.8.4.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v10 00/27] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Hi Thomas,

as discussed earlier today, I'm sending out a fresh rebase of the gdb
scripts so that you can organize the next steps towards merge. Thanks
for this in advance!

Changes since v9:
 - rebase over recent Linux version
 - use a generator instead of iterator for task list,
   fixes thread-group iteration [Daniel Wagner]
 - apply generator scheme on other iterations
 - propose myself as maintainer

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

There is still some issue with gdb = 7.8 when parsing symbols of kernel
modules, because I didn't deliver those folks the requested core dump of
gdb so far - done now. So up to version 7.7 remains recommended for the
time being.

Jan

CC: Daniel Thompson daniel.thomp...@linaro.org
CC: Daniel Wagner daniel.wag...@bmw-carit.de
CC: David S. Miller da...@davemloft.net
CC: Fenghua Yu fenghua...@intel.com
Cc: Jan Kiszka jan.kis...@siemens.com
CC: Kay Sievers k...@vrfy.org
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
Cc: Michal Marek mma...@suse.cz
CC: Michal Marek mma...@suse.cz
CC: Pantelis Koukousoulas pkt...@gmail.com
CC: Rob Landley r...@landley.net
CC: Rusty Russell ru...@rustcorp.com.au
CC: sparcli...@vger.kernel.org
CC: Tony Luck tony.l...@intel.com

Daniel Thompson (1):
  scripts/gdb: Ignore byte-compiled python files

Daniel Wagner (1):
  scripts/gdb: Use a generator instead of iterator for task list

Jan Kiszka (24):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation
  scripts/gdb: Convert ModuleList to generator function
  scripts/gdb: Convert CpuList to generator function
  scripts/gdb: Define maintainer

Pantelis Koukousoulas (1):
  scripts/gdb: Port to python3 / gdb7.7

 .gitignore |   1 +
 Documentation/gdb-kernel-debugging.txt | 160 +++
 MAINTAINERS|   5 +
 Makefile   |   6 +-
 kernel/module.c|   9 +-
 lib/Kconfig.debug  |  11 +++
 scripts/Makefile   |   3 +-
 scripts/gdb/Makefile   |   1 +
 scripts/gdb/linux/.gitignore   |   2 +
 scripts/gdb/linux/Makefile |  11 +++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 135 +++
 scripts/gdb/linux/dmesg.py |  65 +
 scripts/gdb/linux/modules.py   | 103 
 scripts/gdb/linux/symbols.py   | 166 +
 scripts/gdb/linux/tasks.py | 100 
 scripts/gdb/linux/utils.py | 156 +++
 scripts/gdb/vmlinux-gdb.py |  30 ++
 18 files changed, 960 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/.gitignore
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
1.8.4.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 00/23] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Another refresh of this feature series. Changes since v8:
 - Ignore byte-compiled python files [Daniel Thompson]
 - rebase over recent Linux version, resolving a trivial conflict

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

Note that there is apparently some issue with gdb 7.8 and newer that
prevents lx-symbols from working here [1]. 7.7 is still fine, though.

Jan

[1] http://thread.gmane.org/gmane.comp.gdb.devel/34898

CC: Daniel Thompson 
CC: "David S. Miller" 
CC: Fenghua Yu 
CC: Kay Sievers 
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
Cc: Michal Marek 
CC: Michal Marek 
CC: Pantelis Koukousoulas 
CC: Rob Landley 
CC: Rusty Russell 
CC: sparcli...@vger.kernel.org
CC: Tony Luck 

Daniel Thompson (1):
  scripts/gdb: Ignore byte-compiled python files

Jan Kiszka (21):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation

Pantelis Koukousoulas (1):
  scripts/gdb: Port to python3 / gdb7.7

 .gitignore |   1 +
 Documentation/gdb-kernel-debugging.txt | 160 +++
 Makefile   |   6 +-
 kernel/module.c|   9 +-
 lib/Kconfig.debug  |  11 +++
 scripts/Makefile   |   3 +-
 scripts/gdb/Makefile   |   1 +
 scripts/gdb/linux/.gitignore   |   2 +
 scripts/gdb/linux/Makefile |  11 +++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 142 
 scripts/gdb/linux/dmesg.py |  65 +
 scripts/gdb/linux/modules.py   | 114 ++
 scripts/gdb/linux/symbols.py   | 166 +
 scripts/gdb/linux/tasks.py | 110 ++
 scripts/gdb/linux/utils.py | 156 +++
 scripts/gdb/vmlinux-gdb.py |  30 ++
 17 files changed, 983 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/.gitignore
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
1.8.1.1.298.ge7eed54

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v9 00/23] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Another refresh of this feature series. Changes since v8:
 - Ignore byte-compiled python files [Daniel Thompson]
 - rebase over recent Linux version, resolving a trivial conflict

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

Note that there is apparently some issue with gdb 7.8 and newer that
prevents lx-symbols from working here [1]. 7.7 is still fine, though.

Jan

[1] http://thread.gmane.org/gmane.comp.gdb.devel/34898

CC: Daniel Thompson daniel.thomp...@linaro.org
CC: David S. Miller da...@davemloft.net
CC: Fenghua Yu fenghua...@intel.com
CC: Kay Sievers k...@vrfy.org
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
Cc: Michal Marek mma...@suse.cz
CC: Michal Marek mma...@suse.cz
CC: Pantelis Koukousoulas pkt...@gmail.com
CC: Rob Landley r...@landley.net
CC: Rusty Russell ru...@rustcorp.com.au
CC: sparcli...@vger.kernel.org
CC: Tony Luck tony.l...@intel.com

Daniel Thompson (1):
  scripts/gdb: Ignore byte-compiled python files

Jan Kiszka (21):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation

Pantelis Koukousoulas (1):
  scripts/gdb: Port to python3 / gdb7.7

 .gitignore |   1 +
 Documentation/gdb-kernel-debugging.txt | 160 +++
 Makefile   |   6 +-
 kernel/module.c|   9 +-
 lib/Kconfig.debug  |  11 +++
 scripts/Makefile   |   3 +-
 scripts/gdb/Makefile   |   1 +
 scripts/gdb/linux/.gitignore   |   2 +
 scripts/gdb/linux/Makefile |  11 +++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 142 
 scripts/gdb/linux/dmesg.py |  65 +
 scripts/gdb/linux/modules.py   | 114 ++
 scripts/gdb/linux/symbols.py   | 166 +
 scripts/gdb/linux/tasks.py | 110 ++
 scripts/gdb/linux/utils.py | 156 +++
 scripts/gdb/vmlinux-gdb.py |  30 ++
 17 files changed, 983 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/.gitignore
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
1.8.1.1.298.ge7eed54

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Nick Krause]

On Mon, Aug 4, 2014 at 11:18 PM, Nick Krause  wrote:
> On Mon, Aug 4, 2014 at 9:33 PM, Nick Krause  wrote:
>> On Mon, Aug 4, 2014 at 8:12 PM, Sarah Sharp
>>  wrote:
>>> On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote:
 On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman
  wrote:
 >> From: Nick Krause [mailto:xerofo...@gmail.com]
>>>
>>> [snip]
>>>
 >> Paul ,
 >> My computer is rather old now as of Sandy Bridge days, so I probably
 >> can't test the patch
 >> on my own machine. However I will look at the code and see if I can
 >> forward port it
 >> against the usb git tree I have a current version of. In addition I
 >> would like the new xhci
 >> maintainers information in  order to send out a patch with the
 >> Maintainer for xhci updated.
 >
 > Sarah already told you who the new maintainer is, and then CCed him
 > on this thread. Hint: There is a file name 'MAINTAINERS' in the root
 > of the kernel tree, which tells you who the maintainers are for all of
 > the subsystems. Please read Documentation/SubmittingPatches, it has a
 > lot of information like this that you need to know.
 >
 > --
 > Paul
 >
 Thanks I will read this file and thanks for the information. I known
 where the file is I will
 add the information then.
>>>
>>> You may be looking at an older version of MAINTAINERS.  Mathias has only
>>> been marked as the maintainer since 3.15.  Which kernel version are you
>>> working on?
>>>
>>> Sarah Sharp
>>
> I am going to send out my work on the project you sent me I hope it's
> Ok if not feel free
> to tell me why. I did this against linus's tree but other then that it
> should work.
> Regards Nick

In addition,
I just sent it a few hours ago. Please let me known tomorrow if it's fine.
I am assuming based off my other work it's not.
Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Nick Krause]

On Mon, Aug 4, 2014 at 9:33 PM, Nick Krause  wrote:
> On Mon, Aug 4, 2014 at 8:12 PM, Sarah Sharp
>  wrote:
>> On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote:
>>> On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman
>>>  wrote:
>>> >> From: Nick Krause [mailto:xerofo...@gmail.com]
>>
>> [snip]
>>
>>> >> Paul ,
>>> >> My computer is rather old now as of Sandy Bridge days, so I probably
>>> >> can't test the patch
>>> >> on my own machine. However I will look at the code and see if I can
>>> >> forward port it
>>> >> against the usb git tree I have a current version of. In addition I
>>> >> would like the new xhci
>>> >> maintainers information in  order to send out a patch with the
>>> >> Maintainer for xhci updated.
>>> >
>>> > Sarah already told you who the new maintainer is, and then CCed him
>>> > on this thread. Hint: There is a file name 'MAINTAINERS' in the root
>>> > of the kernel tree, which tells you who the maintainers are for all of
>>> > the subsystems. Please read Documentation/SubmittingPatches, it has a
>>> > lot of information like this that you need to know.
>>> >
>>> > --
>>> > Paul
>>> >
>>> Thanks I will read this file and thanks for the information. I known
>>> where the file is I will
>>> add the information then.
>>
>> You may be looking at an older version of MAINTAINERS.  Mathias has only
>> been marked as the maintainer since 3.15.  Which kernel version are you
>> working on?
>>
>> Sarah Sharp
>
I am going to send out my work on the project you sent me I hope it's
Ok if not feel free
to tell me why. I did this against linus's tree but other then that it
should work.
Regards Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Nick Krause]

On Mon, Aug 4, 2014 at 8:12 PM, Sarah Sharp
 wrote:
> On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote:
>> On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman
>>  wrote:
>> >> From: Nick Krause [mailto:xerofo...@gmail.com]
>
> [snip]
>
>> >> Paul ,
>> >> My computer is rather old now as of Sandy Bridge days, so I probably
>> >> can't test the patch
>> >> on my own machine. However I will look at the code and see if I can
>> >> forward port it
>> >> against the usb git tree I have a current version of. In addition I
>> >> would like the new xhci
>> >> maintainers information in  order to send out a patch with the
>> >> Maintainer for xhci updated.
>> >
>> > Sarah already told you who the new maintainer is, and then CCed him
>> > on this thread. Hint: There is a file name 'MAINTAINERS' in the root
>> > of the kernel tree, which tells you who the maintainers are for all of
>> > the subsystems. Please read Documentation/SubmittingPatches, it has a
>> > lot of information like this that you need to know.
>> >
>> > --
>> > Paul
>> >
>> Thanks I will read this file and thanks for the information. I known
>> where the file is I will
>> add the information then.
>
> You may be looking at an older version of MAINTAINERS.  Mathias has only
> been marked as the maintainer since 3.15.  Which kernel version are you
> working on?
>
> Sarah Sharp

Hey Sarah,
Sorry about that but I am working on the latest tree from linus using
git and I checked seems he is there,
I didn't known it was updated.
Sorry and Thanks Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Sarah Sharp]

On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote:
> On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman
>  wrote:
> >> From: Nick Krause [mailto:xerofo...@gmail.com]

[snip]

> >> Paul ,
> >> My computer is rather old now as of Sandy Bridge days, so I probably
> >> can't test the patch
> >> on my own machine. However I will look at the code and see if I can
> >> forward port it
> >> against the usb git tree I have a current version of. In addition I
> >> would like the new xhci
> >> maintainers information in  order to send out a patch with the
> >> Maintainer for xhci updated.
> >
> > Sarah already told you who the new maintainer is, and then CCed him
> > on this thread. Hint: There is a file name 'MAINTAINERS' in the root
> > of the kernel tree, which tells you who the maintainers are for all of
> > the subsystems. Please read Documentation/SubmittingPatches, it has a
> > lot of information like this that you need to know.
> >
> > --
> > Paul
> >
> Thanks I will read this file and thanks for the information. I known
> where the file is I will
> add the information then.

You may be looking at an older version of MAINTAINERS.  Mathias has only
been marked as the maintainer since 3.15.  Which kernel version are you
working on?

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Nick Krause]

On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman
 wrote:
>> From: Nick Krause [mailto:xerofo...@gmail.com]
>> Sent: Monday, August 04, 2014 3:50 PM
>>
>> On Mon, Aug 4, 2014 at 5:55 PM, Paul Zimmerman
>>  wrote:
>> >> From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
>> >> Sent: Monday, August 04, 2014 1:28 PM
>> >>
>> >> On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said:
>> >>
>> >> > Ah, you didn't read far enough down the page :)
>> >>
>> >> I'm willing to bet a large pizza with everything but anchovies that
>> >> out in the real world, a lot of implementors didn't read further either. 
>> >> :)
>> >
>> > Nah, I won't take that bet :)
>> >
>> >> > So I have to believe there are a *lot* of systems out there that do 
>> >> > support xHCI debug.
>> >>
>> >> Possibly. But enough to make an actual critical mass to motivate somebody
>> >> to write code? Or do you get more bang-for-buck by fixing kgdb to support
>> >> debugging over Ethernet?
>> >
>> > Well, code to support the xHCI debug capability has been written, see
>> > http://marc.info/?l=linux-usb=135948845511047. But I did not get
>> > approval from my management to spend the time needed to integrate this
>> > into the kernel's kgdb support.
>> >
>> > Nick, if you are still interested in this, you could take a look at the
>> > above code, and see if you can work out how to modify it to make it work
>> > with kgdb. But you will need a PC that has a debug-capable xHCI
>> > controller in order to test it. If you have PC or laptop with USB 3.0
>> > built-in that has the Windows 8 logo, I think there's a good chance you
>> > already have one. Or, according to
>> > http://pete.akeo.ie/2011/08/do-necrenesas-upd720200-based-usb-30.html,
>> > plug-in USB 3.0 host cards that use the newer Renesas uPD720201 chipset
>> > also have the debug capability.
>> >
>> > Note that the above patch is against a pretty old kernel (3.6), so the
>> > first thing you would need to do is forward-port it to work on the
>> > latest kernel. As a plus, that would give you some real experience
>> > working with kernel code, which everyone seems to agree you need ;)
>> >
>> > --
>> > Paul
>> >
>>
>> Paul ,
>> My computer is rather old now as of Sandy Bridge days, so I probably
>> can't test the patch
>> on my own machine. However I will look at the code and see if I can
>> forward port it
>> against the usb git tree I have a current version of. In addition I
>> would like the new xhci
>> maintainers information in  order to send out a patch with the
>> Maintainer for xhci updated.
>
> Sarah already told you who the new maintainer is, and then CCed him
> on this thread. Hint: There is a file name 'MAINTAINERS' in the root
> of the kernel tree, which tells you who the maintainers are for all of
> the subsystems. Please read Documentation/SubmittingPatches, it has a
> lot of information like this that you need to know.
>
> --
> Paul
>
Thanks I will read this file and thanks for the information. I known
where the file is I will
add the information then.
Regards Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Kernel Debugging Support

[Paul Zimmerman]

> From: Nick Krause [mailto:xerofo...@gmail.com]
> Sent: Monday, August 04, 2014 3:50 PM
> 
> On Mon, Aug 4, 2014 at 5:55 PM, Paul Zimmerman
>  wrote:
> >> From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
> >> Sent: Monday, August 04, 2014 1:28 PM
> >>
> >> On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said:
> >>
> >> > Ah, you didn't read far enough down the page :)
> >>
> >> I'm willing to bet a large pizza with everything but anchovies that
> >> out in the real world, a lot of implementors didn't read further either. :)
> >
> > Nah, I won't take that bet :)
> >
> >> > So I have to believe there are a *lot* of systems out there that do 
> >> > support xHCI debug.
> >>
> >> Possibly. But enough to make an actual critical mass to motivate somebody
> >> to write code? Or do you get more bang-for-buck by fixing kgdb to support
> >> debugging over Ethernet?
> >
> > Well, code to support the xHCI debug capability has been written, see
> > http://marc.info/?l=linux-usb=135948845511047. But I did not get
> > approval from my management to spend the time needed to integrate this
> > into the kernel's kgdb support.
> >
> > Nick, if you are still interested in this, you could take a look at the
> > above code, and see if you can work out how to modify it to make it work
> > with kgdb. But you will need a PC that has a debug-capable xHCI
> > controller in order to test it. If you have PC or laptop with USB 3.0
> > built-in that has the Windows 8 logo, I think there's a good chance you
> > already have one. Or, according to
> > http://pete.akeo.ie/2011/08/do-necrenesas-upd720200-based-usb-30.html,
> > plug-in USB 3.0 host cards that use the newer Renesas uPD720201 chipset
> > also have the debug capability.
> >
> > Note that the above patch is against a pretty old kernel (3.6), so the
> > first thing you would need to do is forward-port it to work on the
> > latest kernel. As a plus, that would give you some real experience
> > working with kernel code, which everyone seems to agree you need ;)
> >
> > --
> > Paul
> >
> 
> Paul ,
> My computer is rather old now as of Sandy Bridge days, so I probably
> can't test the patch
> on my own machine. However I will look at the code and see if I can
> forward port it
> against the usb git tree I have a current version of. In addition I
> would like the new xhci
> maintainers information in  order to send out a patch with the
> Maintainer for xhci updated.

Sarah already told you who the new maintainer is, and then CCed him
on this thread. Hint: There is a file name 'MAINTAINERS' in the root
of the kernel tree, which tells you who the maintainers are for all of
the subsystems. Please read Documentation/SubmittingPatches, it has a
lot of information like this that you need to know.

-- 
Paul

Re: Kernel Debugging Support

[Nick Krause]

On Mon, Aug 4, 2014 at 5:55 PM, Paul Zimmerman
 wrote:
>> From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
>> Sent: Monday, August 04, 2014 1:28 PM
>>
>> On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said:
>>
>> > Ah, you didn't read far enough down the page :)
>>
>> I'm willing to bet a large pizza with everything but anchovies that
>> out in the real world, a lot of implementors didn't read further either. :)
>
> Nah, I won't take that bet :)
>
>> > So I have to believe there are a *lot* of systems out there that do 
>> > support xHCI debug.
>>
>> Possibly. But enough to make an actual critical mass to motivate somebody
>> to write code? Or do you get more bang-for-buck by fixing kgdb to support
>> debugging over Ethernet?
>
> Well, code to support the xHCI debug capability has been written, see
> http://marc.info/?l=linux-usb=135948845511047. But I did not get
> approval from my management to spend the time needed to integrate this
> into the kernel's kgdb support.
>
> Nick, if you are still interested in this, you could take a look at the
> above code, and see if you can work out how to modify it to make it work
> with kgdb. But you will need a PC that has a debug-capable xHCI
> controller in order to test it. If you have PC or laptop with USB 3.0
> built-in that has the Windows 8 logo, I think there's a good chance you
> already have one. Or, according to
> http://pete.akeo.ie/2011/08/do-necrenesas-upd720200-based-usb-30.html,
> plug-in USB 3.0 host cards that use the newer Renesas uPD720201 chipset
> also have the debug capability.
>
> Note that the above patch is against a pretty old kernel (3.6), so the
> first thing you would need to do is forward-port it to work on the
> latest kernel. As a plus, that would give you some real experience
> working with kernel code, which everyone seems to agree you need ;)
>
> --
> Paul
>

Paul ,
My computer is rather old now as of Sandy Bridge days, so I probably
can't test the patch
on my own machine. However I will look at the code and see if I can
forward port it
against the usb git tree I have a current version of. In addition I
would like the new xhci
maintainers information in  order to send out a patch with the
Maintainer for xhci updated.
Regards Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Kernel Debugging Support

[Paul Zimmerman]

> From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
> Sent: Monday, August 04, 2014 1:28 PM
> 
> On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said:
> 
> > Ah, you didn't read far enough down the page :)
> 
> I'm willing to bet a large pizza with everything but anchovies that
> out in the real world, a lot of implementors didn't read further either. :)

Nah, I won't take that bet :)

> > So I have to believe there are a *lot* of systems out there that do support 
> > xHCI debug.
> 
> Possibly. But enough to make an actual critical mass to motivate somebody
> to write code? Or do you get more bang-for-buck by fixing kgdb to support
> debugging over Ethernet?

Well, code to support the xHCI debug capability has been written, see
http://marc.info/?l=linux-usb=135948845511047. But I did not get
approval from my management to spend the time needed to integrate this
into the kernel's kgdb support.

Nick, if you are still interested in this, you could take a look at the
above code, and see if you can work out how to modify it to make it work
with kgdb. But you will need a PC that has a debug-capable xHCI
controller in order to test it. If you have PC or laptop with USB 3.0
built-in that has the Windows 8 logo, I think there's a good chance you
already have one. Or, according to
http://pete.akeo.ie/2011/08/do-necrenesas-upd720200-based-usb-30.html, 
plug-in USB 3.0 host cards that use the newer Renesas uPD720201 chipset
also have the debug capability.

Note that the above patch is against a pretty old kernel (3.6), so the
first thing you would need to do is forward-port it to work on the
latest kernel. As a plus, that would give you some real experience
working with kernel code, which everyone seems to agree you need ;)

-- 
Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Valdis . Kletnieks]

On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said:

> Ah, you didn't read far enough down the page :)

I'm willing to bet a large pizza with everything but anchovies that
out in the real world, a lot of implementors didn't read further either. :)

> So I have to believe there are a *lot* of systems out there that do support 
> xHCI debug.

Possibly. But enough to make an actual critical mass to motivate somebody
to write code? Or do you get more bang-for-buck by fixing kgdb to support
debugging over Ethernet?



pgpN0X0cFKmUR.pgp
Description: PGP signature

RE: Kernel Debugging Support

[Paul Zimmerman]

> From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
> Sent: Monday, August 04, 2014 12:23 PM
> 
> On Mon, 04 Aug 2014 19:07:53 -, Paul Zimmerman said:
> 
> > Are you sure about that? Last I heard, xHCI debug support was a logo
> > requirement from Microsoft for Windows 8 and above, so I would have
> > thought that most vendors would have implemented it by now.
> 
> There's a lot of gear out in the real world that was manufactured before
> Windows 8 was released.
> 
> And the actual requirement, as listed at:
> 
> http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256
> 
> doesn't actually require USB debug -it requires a debug port, and xHCI
> is below ethernet on the preference list.  As it says:
> 
> ---
> The next version of Windows will support several different debug transports.
> They are listed below in the preferred order of implementation.
> 
> Hardware Debugging Transports
> 
> Ethernet Network Interface Card from the supported list: 
> http://msdn.microsoft.com/en-
> us/library/windows/hardware/hh830880
> 
> USB 3.0 - xHCI controller compliant to xHCI debug specification.
> 
> 1394 OHCI compliant Firewire controllers.
> 
> USB2 OTG (on supported hardware for Windows, recommend XHCI debug instead).
> 
> USB 2.0 EHCI debug (the debug enabled port must be user accessible). Legacy 
> Serial (16550 compatible
> programming interface).

Ah, you didn't read far enough down the page :)

---
System.Fundamentals.DebugPort.USB.SystemExposesDebugInterfaceUsb
USB 3 system exposes debug interface that complies with Debug Port Specification
 
Target Feature
 System.Fundamentals.DebugPort.USB
 
Applies to
 Windows 8 Client x86, x64, ARM (Windows RT)
 Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
 Windows Server 2012 R2 x64
 Windows Server 2012 x64

Description

Systems that support USB 3 are required to have xHCI controller(s) compliant to 
the xHCI debug specification. The xHCI controller(s) shall be memory mapped.

There must be at least one user accessible USB 3.0 debug port on the machine.

...

Enforcement Date
 Mar. 01, 2012
---

So I have to believe there are a *lot* of systems out there that do support 
xHCI debug.

-- 
Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Valdis . Kletnieks]

On Mon, 04 Aug 2014 19:07:53 -, Paul Zimmerman said:

> Are you sure about that? Last I heard, xHCI debug support was a logo
> requirement from Microsoft for Windows 8 and above, so I would have
> thought that most vendors would have implemented it by now.

There's a lot of gear out in the real world that was manufactured before
Windows 8 was released.

And the actual requirement, as listed at:

http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256

doesn't actually require USB debug -it requires a debug port, and xHCI
is below ethernet on the preference list.  As it says:

---
The next version of Windows will support several different debug transports.
They are listed below in the preferred order of implementation.

Hardware Debugging Transports

Ethernet Network Interface Card from the supported list: 
http://msdn.microsoft.com/en-us/library/windows/hardware/hh830880

USB 3.0 - xHCI controller compliant to xHCI debug specification.

1394 OHCI compliant Firewire controllers.

USB2 OTG (on supported hardware for Windows, recommend XHCI debug instead).

USB 2.0 EHCI debug (the debug enabled port must be user accessible). Legacy 
Serial (16550 compatible programming interface).

 ADDITIONAL REQUIREMENTSFOR ALL OF THE ABOVE IMPLEMENTATIONS THE FOLLOWING MUST 
APPLY:

There must be at least one user accessible debug port on the machine. It is
acceptable on systems which choose to not expose a USB port or any other
acceptable port from the list above to instead require a separate debugging
board or device that provides the ability to debug via one (or more) of the
transports above. That device/board must terminate in the same standard port as
would be used for the transport if it were \u2018onboard\u2019 the machine. If
this device is required it must be documented in the system specifications, be
user serviceable, be user installable on the machine, and available for sale
from the machine\u2019s vendor.



pgpnbM3GZqPlg.pgp
Description: PGP signature

RE: Kernel Debugging Support

[Paul Zimmerman]

> From: linux-usb-ow...@vger.kernel.org 
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Sarah Sharp
> Sent: Monday, August 04, 2014 9:47 AM
> 
> Please Cc the new xHCI driver maintainer, Mathias Nyman.  I'm officially
> retired from USB development and have moved onto other projects. :)
> 
> > After reading around seems people want support for usb debugging in
> > kgdb or other usb based solutions.
> 
> Yes, early boot USB debug over xHCI has been a low-priority feature
> request.
> 
> Unfortunately, USB debug is an optional feature for xHCI host
> controllers, so many of them don't have USB debug ports.  Even if it is
> included, the USB debug ports are often either routed to internal USB
> ports or not exposed on the board altogether.  Since it's not widely
> available, it's not a high priority to implement.

Hi Sarah,

Are you sure about that? Last I heard, xHCI debug support was a logo
requirement from Microsoft for Windows 8 and above, so I would have
thought that most vendors would have implemented it by now. I know
Synopsys put a lot of effort into making sure it works in our IP. Or
did Microsoft relax that requirement at the last minute?

-- 
Paul

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Sarah Sharp]

On Sat, Aug 02, 2014 at 12:47:59AM -0400, Nick Krause wrote:
> Hey Sharp,

Hi Krause,

Please Cc the new xHCI driver maintainer, Mathias Nyman.  I'm officially
retired from USB development and have moved onto other projects. :)

> After reading around seems people want support for usb debugging in
> kgdb or other usb based solutions.

Yes, early boot USB debug over xHCI has been a low-priority feature
request.

Unfortunately, USB debug is an optional feature for xHCI host
controllers, so many of them don't have USB debug ports.  Even if it is
included, the USB debug ports are often either routed to internal USB
ports or not exposed on the board altogether.  Since it's not widely
available, it's not a high priority to implement.

> If you and the other developers are able to help me out a bit as I am
> new I can definitively write this
> area of kgdb support.

The kgdb support is all there.  It's the xHCI host controller driver
debug port support that is needed.

Hmm, I only see one commit from your email address in Greg's tree.  I
think you should work on some smaller clean ups and bug fixes, and get
some more patches into mainline before you go on to tackle a larger
feature like this.  Perhaps Mathias has a smaller task that would be
good for you to tackle?

There's a good tutorial here on how to create a kernel patch, and
respond properly to patch review and rework requests:

http://kernelnewbies.org/OPWfirstpatch

And here's my personal philosophy on how to create a patchset:

http://sarah.thesharps.us/2013/05/08/patchsets-for-dinner/

> Regards Nick
> P.S. If  you want Sharp I can change the commit message on my other
> commit you didn't like if me or you
> talk to Greg in order to remove in from mainline, if no that's OK too.

I don't understand what the above sentence means.  What commit message
are you referencing?  What do you mean by "remove in from mainline"?

Try again?

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Richard Weinberger]

On Mon, Aug 4, 2014 at 4:29 PM, Austin S Hemmelgarn
 wrote:
> On 2014-08-04 10:21, Alan Stern wrote:
>> On Mon, 4 Aug 2014, Austin S Hemmelgarn wrote:
>>
>>> On 2014-08-02 09:48, Alan Stern wrote:
 On Sat, 2 Aug 2014, Nick Krause wrote:

> Hey Sharp,
> After reading around seems people want support for usb debugging in
> kgdb or other usb based solutions.
> If you and the other developers are able to help me out a bit as I am
> new I can definitively write this
> area of kgdb support.

 Doesn't kgdb already support USB for debugging?

 Alan Stern
>>>
>>> AFAICT, on x86 it only supports using either a console capable serial
>>> port (so you could do that over USB if you have USB serial console
>>> support built-in, but most people I know don't compile that in, and in
>>> fact that is the only reason that i compile USB serial support in
>>> instead of making it a module), and an AT compatible keyboard with any
>>> console option.
>>
>> What about with a USB debugging device (CONFIG_EARLY_PRINTK_DBGP)?
>> That's how debugging over USB is _supposed_ to be done.
> Yes, except those are really expensive, and on some it's pretty easy if
> you don't know what you are doing to really screw things up.

All you need is a Computer with an UDC. Linux has a debugport gadget.

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Austin S Hemmelgarn]

On 2014-08-04 10:21, Alan Stern wrote:
> On Mon, 4 Aug 2014, Austin S Hemmelgarn wrote:
> 
>> On 2014-08-02 09:48, Alan Stern wrote:
>>> On Sat, 2 Aug 2014, Nick Krause wrote:
>>>
 Hey Sharp,
 After reading around seems people want support for usb debugging in
 kgdb or other usb based solutions.
 If you and the other developers are able to help me out a bit as I am
 new I can definitively write this
 area of kgdb support.
>>>
>>> Doesn't kgdb already support USB for debugging?
>>>
>>> Alan Stern
>>
>> AFAICT, on x86 it only supports using either a console capable serial
>> port (so you could do that over USB if you have USB serial console
>> support built-in, but most people I know don't compile that in, and in
>> fact that is the only reason that i compile USB serial support in
>> instead of making it a module), and an AT compatible keyboard with any
>> console option.
> 
> What about with a USB debugging device (CONFIG_EARLY_PRINTK_DBGP)?  
> That's how debugging over USB is _supposed_ to be done.
Yes, except those are really expensive, and on some it's pretty easy if
you don't know what you are doing to really screw things up.
> 
>>  It would be really nice to have USB keyboard support in
>> there so that you don't have to reboot with special options and extra
>> hardware plugged in to get to the debugger, although doing something
>> that supports more than just the HID boot protocol will probably be tricky.
> 
> Is there some reason why kgdb doesn't simply use the kernel's input 
> layer?  If there is, that same reason probably prevents it from using 
> USB.
> 
I believe it's to minimize the in-kernel dependencies.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Kernel Debugging Support

[Alan Stern]

On Mon, 4 Aug 2014, Austin S Hemmelgarn wrote:

> On 2014-08-02 09:48, Alan Stern wrote:
> > On Sat, 2 Aug 2014, Nick Krause wrote:
> > 
> >> Hey Sharp,
> >> After reading around seems people want support for usb debugging in
> >> kgdb or other usb based solutions.
> >> If you and the other developers are able to help me out a bit as I am
> >> new I can definitively write this
> >> area of kgdb support.
> > 
> > Doesn't kgdb already support USB for debugging?
> > 
> > Alan Stern
> 
> AFAICT, on x86 it only supports using either a console capable serial
> port (so you could do that over USB if you have USB serial console
> support built-in, but most people I know don't compile that in, and in
> fact that is the only reason that i compile USB serial support in
> instead of making it a module), and an AT compatible keyboard with any
> console option.

What about with a USB debugging device (CONFIG_EARLY_PRINTK_DBGP)?  
That's how debugging over USB is _supposed_ to be done.

>  It would be really nice to have USB keyboard support in
> there so that you don't have to reboot with special options and extra
> hardware plugged in to get to the debugger, although doing something
> that supports more than just the HID boot protocol will probably be tricky.

Is there some reason why kgdb doesn't simply use the kernel's input 
layer?  If there is, that same reason probably prevents it from using 
USB.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Austin S Hemmelgarn]

On 2014-08-02 09:48, Alan Stern wrote:
> On Sat, 2 Aug 2014, Nick Krause wrote:
> 
>> Hey Sharp,
>> After reading around seems people want support for usb debugging in
>> kgdb or other usb based solutions.
>> If you and the other developers are able to help me out a bit as I am
>> new I can definitively write this
>> area of kgdb support.
> 
> Doesn't kgdb already support USB for debugging?
> 
> Alan Stern

AFAICT, on x86 it only supports using either a console capable serial
port (so you could do that over USB if you have USB serial console
support built-in, but most people I know don't compile that in, and in
fact that is the only reason that i compile USB serial support in
instead of making it a module), and an AT compatible keyboard with any
console option.  It would be really nice to have USB keyboard support in
there so that you don't have to reboot with special options and extra
hardware plugged in to get to the debugger, although doing something
that supports more than just the HID boot protocol will probably be tricky.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Kernel Debugging Support

[Austin S Hemmelgarn]

On 2014-08-02 09:48, Alan Stern wrote:
 On Sat, 2 Aug 2014, Nick Krause wrote:
 
 Hey Sharp,
 After reading around seems people want support for usb debugging in
 kgdb or other usb based solutions.
 If you and the other developers are able to help me out a bit as I am
 new I can definitively write this
 area of kgdb support.
 
 Doesn't kgdb already support USB for debugging?
 
 Alan Stern

AFAICT, on x86 it only supports using either a console capable serial
port (so you could do that over USB if you have USB serial console
support built-in, but most people I know don't compile that in, and in
fact that is the only reason that i compile USB serial support in
instead of making it a module), and an AT compatible keyboard with any
console option.  It would be really nice to have USB keyboard support in
there so that you don't have to reboot with special options and extra
hardware plugged in to get to the debugger, although doing something
that supports more than just the HID boot protocol will probably be tricky.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Kernel Debugging Support

[Alan Stern]

On Mon, 4 Aug 2014, Austin S Hemmelgarn wrote:

 On 2014-08-02 09:48, Alan Stern wrote:
  On Sat, 2 Aug 2014, Nick Krause wrote:
  
  Hey Sharp,
  After reading around seems people want support for usb debugging in
  kgdb or other usb based solutions.
  If you and the other developers are able to help me out a bit as I am
  new I can definitively write this
  area of kgdb support.
  
  Doesn't kgdb already support USB for debugging?
  
  Alan Stern
 
 AFAICT, on x86 it only supports using either a console capable serial
 port (so you could do that over USB if you have USB serial console
 support built-in, but most people I know don't compile that in, and in
 fact that is the only reason that i compile USB serial support in
 instead of making it a module), and an AT compatible keyboard with any
 console option.

What about with a USB debugging device (CONFIG_EARLY_PRINTK_DBGP)?  
That's how debugging over USB is _supposed_ to be done.

  It would be really nice to have USB keyboard support in
 there so that you don't have to reboot with special options and extra
 hardware plugged in to get to the debugger, although doing something
 that supports more than just the HID boot protocol will probably be tricky.

Is there some reason why kgdb doesn't simply use the kernel's input 
layer?  If there is, that same reason probably prevents it from using 
USB.

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Austin S Hemmelgarn]

On 2014-08-04 10:21, Alan Stern wrote:
 On Mon, 4 Aug 2014, Austin S Hemmelgarn wrote:
 
 On 2014-08-02 09:48, Alan Stern wrote:
 On Sat, 2 Aug 2014, Nick Krause wrote:

 Hey Sharp,
 After reading around seems people want support for usb debugging in
 kgdb or other usb based solutions.
 If you and the other developers are able to help me out a bit as I am
 new I can definitively write this
 area of kgdb support.

 Doesn't kgdb already support USB for debugging?

 Alan Stern

 AFAICT, on x86 it only supports using either a console capable serial
 port (so you could do that over USB if you have USB serial console
 support built-in, but most people I know don't compile that in, and in
 fact that is the only reason that i compile USB serial support in
 instead of making it a module), and an AT compatible keyboard with any
 console option.
 
 What about with a USB debugging device (CONFIG_EARLY_PRINTK_DBGP)?  
 That's how debugging over USB is _supposed_ to be done.
Yes, except those are really expensive, and on some it's pretty easy if
you don't know what you are doing to really screw things up.
 
  It would be really nice to have USB keyboard support in
 there so that you don't have to reboot with special options and extra
 hardware plugged in to get to the debugger, although doing something
 that supports more than just the HID boot protocol will probably be tricky.
 
 Is there some reason why kgdb doesn't simply use the kernel's input 
 layer?  If there is, that same reason probably prevents it from using 
 USB.
 
I believe it's to minimize the in-kernel dependencies.




smime.p7s
Description: S/MIME Cryptographic Signature

Re: Kernel Debugging Support

[Richard Weinberger]

On Mon, Aug 4, 2014 at 4:29 PM, Austin S Hemmelgarn
ahferro...@gmail.com wrote:
 On 2014-08-04 10:21, Alan Stern wrote:
 On Mon, 4 Aug 2014, Austin S Hemmelgarn wrote:

 On 2014-08-02 09:48, Alan Stern wrote:
 On Sat, 2 Aug 2014, Nick Krause wrote:

 Hey Sharp,
 After reading around seems people want support for usb debugging in
 kgdb or other usb based solutions.
 If you and the other developers are able to help me out a bit as I am
 new I can definitively write this
 area of kgdb support.

 Doesn't kgdb already support USB for debugging?

 Alan Stern

 AFAICT, on x86 it only supports using either a console capable serial
 port (so you could do that over USB if you have USB serial console
 support built-in, but most people I know don't compile that in, and in
 fact that is the only reason that i compile USB serial support in
 instead of making it a module), and an AT compatible keyboard with any
 console option.

 What about with a USB debugging device (CONFIG_EARLY_PRINTK_DBGP)?
 That's how debugging over USB is _supposed_ to be done.
 Yes, except those are really expensive, and on some it's pretty easy if
 you don't know what you are doing to really screw things up.

All you need is a Computer with an UDC. Linux has a debugport gadget.

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Sarah Sharp]

On Sat, Aug 02, 2014 at 12:47:59AM -0400, Nick Krause wrote:
 Hey Sharp,

Hi Krause,

Please Cc the new xHCI driver maintainer, Mathias Nyman.  I'm officially
retired from USB development and have moved onto other projects. :)

 After reading around seems people want support for usb debugging in
 kgdb or other usb based solutions.

Yes, early boot USB debug over xHCI has been a low-priority feature
request.

Unfortunately, USB debug is an optional feature for xHCI host
controllers, so many of them don't have USB debug ports.  Even if it is
included, the USB debug ports are often either routed to internal USB
ports or not exposed on the board altogether.  Since it's not widely
available, it's not a high priority to implement.

 If you and the other developers are able to help me out a bit as I am
 new I can definitively write this
 area of kgdb support.

The kgdb support is all there.  It's the xHCI host controller driver
debug port support that is needed.

Hmm, I only see one commit from your email address in Greg's tree.  I
think you should work on some smaller clean ups and bug fixes, and get
some more patches into mainline before you go on to tackle a larger
feature like this.  Perhaps Mathias has a smaller task that would be
good for you to tackle?

There's a good tutorial here on how to create a kernel patch, and
respond properly to patch review and rework requests:

http://kernelnewbies.org/OPWfirstpatch

And here's my personal philosophy on how to create a patchset:

http://sarah.thesharps.us/2013/05/08/patchsets-for-dinner/

 Regards Nick
 P.S. If  you want Sharp I can change the commit message on my other
 commit you didn't like if me or you
 talk to Greg in order to remove in from mainline, if no that's OK too.

I don't understand what the above sentence means.  What commit message
are you referencing?  What do you mean by remove in from mainline?

Try again?

Sarah Sharp
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Kernel Debugging Support

[Paul Zimmerman]

 From: linux-usb-ow...@vger.kernel.org 
 [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Sarah Sharp
 Sent: Monday, August 04, 2014 9:47 AM
 
 Please Cc the new xHCI driver maintainer, Mathias Nyman.  I'm officially
 retired from USB development and have moved onto other projects. :)
 
  After reading around seems people want support for usb debugging in
  kgdb or other usb based solutions.
 
 Yes, early boot USB debug over xHCI has been a low-priority feature
 request.
 
 Unfortunately, USB debug is an optional feature for xHCI host
 controllers, so many of them don't have USB debug ports.  Even if it is
 included, the USB debug ports are often either routed to internal USB
 ports or not exposed on the board altogether.  Since it's not widely
 available, it's not a high priority to implement.

Hi Sarah,

Are you sure about that? Last I heard, xHCI debug support was a logo
requirement from Microsoft for Windows 8 and above, so I would have
thought that most vendors would have implemented it by now. I know
Synopsys put a lot of effort into making sure it works in our IP. Or
did Microsoft relax that requirement at the last minute?

-- 
Paul

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Valdis . Kletnieks]

On Mon, 04 Aug 2014 19:07:53 -, Paul Zimmerman said:

 Are you sure about that? Last I heard, xHCI debug support was a logo
 requirement from Microsoft for Windows 8 and above, so I would have
 thought that most vendors would have implemented it by now.

There's a lot of gear out in the real world that was manufactured before
Windows 8 was released.

And the actual requirement, as listed at:

http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256

doesn't actually require USB debug -it requires a debug port, and xHCI
is below ethernet on the preference list.  As it says:

---
The next version of Windows will support several different debug transports.
They are listed below in the preferred order of implementation.

Hardware Debugging Transports

Ethernet Network Interface Card from the supported list: 
http://msdn.microsoft.com/en-us/library/windows/hardware/hh830880

USB 3.0 - xHCI controller compliant to xHCI debug specification.

1394 OHCI compliant Firewire controllers.

USB2 OTG (on supported hardware for Windows, recommend XHCI debug instead).

USB 2.0 EHCI debug (the debug enabled port must be user accessible). Legacy 
Serial (16550 compatible programming interface).

 ADDITIONAL REQUIREMENTSFOR ALL OF THE ABOVE IMPLEMENTATIONS THE FOLLOWING MUST 
APPLY:

There must be at least one user accessible debug port on the machine. It is
acceptable on systems which choose to not expose a USB port or any other
acceptable port from the list above to instead require a separate debugging
board or device that provides the ability to debug via one (or more) of the
transports above. That device/board must terminate in the same standard port as
would be used for the transport if it were \u2018onboard\u2019 the machine. If
this device is required it must be documented in the system specifications, be
user serviceable, be user installable on the machine, and available for sale
from the machine\u2019s vendor.



pgpnbM3GZqPlg.pgp
Description: PGP signature

RE: Kernel Debugging Support

[Paul Zimmerman]

 From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
 Sent: Monday, August 04, 2014 12:23 PM
 
 On Mon, 04 Aug 2014 19:07:53 -, Paul Zimmerman said:
 
  Are you sure about that? Last I heard, xHCI debug support was a logo
  requirement from Microsoft for Windows 8 and above, so I would have
  thought that most vendors would have implemented it by now.
 
 There's a lot of gear out in the real world that was manufactured before
 Windows 8 was released.
 
 And the actual requirement, as listed at:
 
 http://msdn.microsoft.com/en-us/library/windows/hardware/jj128256
 
 doesn't actually require USB debug -it requires a debug port, and xHCI
 is below ethernet on the preference list.  As it says:
 
 ---
 The next version of Windows will support several different debug transports.
 They are listed below in the preferred order of implementation.
 
 Hardware Debugging Transports
 
 Ethernet Network Interface Card from the supported list: 
 http://msdn.microsoft.com/en-
 us/library/windows/hardware/hh830880
 
 USB 3.0 - xHCI controller compliant to xHCI debug specification.
 
 1394 OHCI compliant Firewire controllers.
 
 USB2 OTG (on supported hardware for Windows, recommend XHCI debug instead).
 
 USB 2.0 EHCI debug (the debug enabled port must be user accessible). Legacy 
 Serial (16550 compatible
 programming interface).

Ah, you didn't read far enough down the page :)

---
System.Fundamentals.DebugPort.USB.SystemExposesDebugInterfaceUsb
USB 3 system exposes debug interface that complies with Debug Port Specification
 
Target Feature
 System.Fundamentals.DebugPort.USB
 
Applies to
 Windows 8 Client x86, x64, ARM (Windows RT)
 Windows 8.1 Client x86, x64, ARM (Windows RT 8.1)
 Windows Server 2012 R2 x64
 Windows Server 2012 x64

Description

Systems that support USB 3 are required to have xHCI controller(s) compliant to 
the xHCI debug specification. The xHCI controller(s) shall be memory mapped.

There must be at least one user accessible USB 3.0 debug port on the machine.

...

Enforcement Date
 Mar. 01, 2012
---

So I have to believe there are a *lot* of systems out there that do support 
xHCI debug.

-- 
Paul

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Valdis . Kletnieks]

On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said:

 Ah, you didn't read far enough down the page :)

I'm willing to bet a large pizza with everything but anchovies that
out in the real world, a lot of implementors didn't read further either. :)

 So I have to believe there are a *lot* of systems out there that do support 
 xHCI debug.

Possibly. But enough to make an actual critical mass to motivate somebody
to write code? Or do you get more bang-for-buck by fixing kgdb to support
debugging over Ethernet?



pgpN0X0cFKmUR.pgp
Description: PGP signature

RE: Kernel Debugging Support

[Paul Zimmerman]

 From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
 Sent: Monday, August 04, 2014 1:28 PM
 
 On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said:
 
  Ah, you didn't read far enough down the page :)
 
 I'm willing to bet a large pizza with everything but anchovies that
 out in the real world, a lot of implementors didn't read further either. :)

Nah, I won't take that bet :)

  So I have to believe there are a *lot* of systems out there that do support 
  xHCI debug.
 
 Possibly. But enough to make an actual critical mass to motivate somebody
 to write code? Or do you get more bang-for-buck by fixing kgdb to support
 debugging over Ethernet?

Well, code to support the xHCI debug capability has been written, see
http://marc.info/?l=linux-usbm=135948845511047. But I did not get
approval from my management to spend the time needed to integrate this
into the kernel's kgdb support.

Nick, if you are still interested in this, you could take a look at the
above code, and see if you can work out how to modify it to make it work
with kgdb. But you will need a PC that has a debug-capable xHCI
controller in order to test it. If you have PC or laptop with USB 3.0
built-in that has the Windows 8 logo, I think there's a good chance you
already have one. Or, according to
http://pete.akeo.ie/2011/08/do-necrenesas-upd720200-based-usb-30.html, 
plug-in USB 3.0 host cards that use the newer Renesas uPD720201 chipset
also have the debug capability.

Note that the above patch is against a pretty old kernel (3.6), so the
first thing you would need to do is forward-port it to work on the
latest kernel. As a plus, that would give you some real experience
working with kernel code, which everyone seems to agree you need ;)

-- 
Paul

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Nick Krause]

On Mon, Aug 4, 2014 at 5:55 PM, Paul Zimmerman
paul.zimmer...@synopsys.com wrote:
 From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
 Sent: Monday, August 04, 2014 1:28 PM

 On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said:

  Ah, you didn't read far enough down the page :)

 I'm willing to bet a large pizza with everything but anchovies that
 out in the real world, a lot of implementors didn't read further either. :)

 Nah, I won't take that bet :)

  So I have to believe there are a *lot* of systems out there that do 
  support xHCI debug.

 Possibly. But enough to make an actual critical mass to motivate somebody
 to write code? Or do you get more bang-for-buck by fixing kgdb to support
 debugging over Ethernet?

 Well, code to support the xHCI debug capability has been written, see
 http://marc.info/?l=linux-usbm=135948845511047. But I did not get
 approval from my management to spend the time needed to integrate this
 into the kernel's kgdb support.

 Nick, if you are still interested in this, you could take a look at the
 above code, and see if you can work out how to modify it to make it work
 with kgdb. But you will need a PC that has a debug-capable xHCI
 controller in order to test it. If you have PC or laptop with USB 3.0
 built-in that has the Windows 8 logo, I think there's a good chance you
 already have one. Or, according to
 http://pete.akeo.ie/2011/08/do-necrenesas-upd720200-based-usb-30.html,
 plug-in USB 3.0 host cards that use the newer Renesas uPD720201 chipset
 also have the debug capability.

 Note that the above patch is against a pretty old kernel (3.6), so the
 first thing you would need to do is forward-port it to work on the
 latest kernel. As a plus, that would give you some real experience
 working with kernel code, which everyone seems to agree you need ;)

 --
 Paul


Paul ,
My computer is rather old now as of Sandy Bridge days, so I probably
can't test the patch
on my own machine. However I will look at the code and see if I can
forward port it
against the usb git tree I have a current version of. In addition I
would like the new xhci
maintainers information in  order to send out a patch with the
Maintainer for xhci updated.
Regards Nick
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Kernel Debugging Support

[Paul Zimmerman]

 From: Nick Krause [mailto:xerofo...@gmail.com]
 Sent: Monday, August 04, 2014 3:50 PM
 
 On Mon, Aug 4, 2014 at 5:55 PM, Paul Zimmerman
 paul.zimmer...@synopsys.com wrote:
  From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
  Sent: Monday, August 04, 2014 1:28 PM
 
  On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said:
 
   Ah, you didn't read far enough down the page :)
 
  I'm willing to bet a large pizza with everything but anchovies that
  out in the real world, a lot of implementors didn't read further either. :)
 
  Nah, I won't take that bet :)
 
   So I have to believe there are a *lot* of systems out there that do 
   support xHCI debug.
 
  Possibly. But enough to make an actual critical mass to motivate somebody
  to write code? Or do you get more bang-for-buck by fixing kgdb to support
  debugging over Ethernet?
 
  Well, code to support the xHCI debug capability has been written, see
  http://marc.info/?l=linux-usbm=135948845511047. But I did not get
  approval from my management to spend the time needed to integrate this
  into the kernel's kgdb support.
 
  Nick, if you are still interested in this, you could take a look at the
  above code, and see if you can work out how to modify it to make it work
  with kgdb. But you will need a PC that has a debug-capable xHCI
  controller in order to test it. If you have PC or laptop with USB 3.0
  built-in that has the Windows 8 logo, I think there's a good chance you
  already have one. Or, according to
  http://pete.akeo.ie/2011/08/do-necrenesas-upd720200-based-usb-30.html,
  plug-in USB 3.0 host cards that use the newer Renesas uPD720201 chipset
  also have the debug capability.
 
  Note that the above patch is against a pretty old kernel (3.6), so the
  first thing you would need to do is forward-port it to work on the
  latest kernel. As a plus, that would give you some real experience
  working with kernel code, which everyone seems to agree you need ;)
 
  --
  Paul
 
 
 Paul ,
 My computer is rather old now as of Sandy Bridge days, so I probably
 can't test the patch
 on my own machine. However I will look at the code and see if I can
 forward port it
 against the usb git tree I have a current version of. In addition I
 would like the new xhci
 maintainers information in  order to send out a patch with the
 Maintainer for xhci updated.

Sarah already told you who the new maintainer is, and then CCed him
on this thread. Hint: There is a file name 'MAINTAINERS' in the root
of the kernel tree, which tells you who the maintainers are for all of
the subsystems. Please read Documentation/SubmittingPatches, it has a
lot of information like this that you need to know.

-- 
Paul

Re: Kernel Debugging Support

[Nick Krause]

On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman
paul.zimmer...@synopsys.com wrote:
 From: Nick Krause [mailto:xerofo...@gmail.com]
 Sent: Monday, August 04, 2014 3:50 PM

 On Mon, Aug 4, 2014 at 5:55 PM, Paul Zimmerman
 paul.zimmer...@synopsys.com wrote:
  From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu]
  Sent: Monday, August 04, 2014 1:28 PM
 
  On Mon, 04 Aug 2014 19:40:15 -, Paul Zimmerman said:
 
   Ah, you didn't read far enough down the page :)
 
  I'm willing to bet a large pizza with everything but anchovies that
  out in the real world, a lot of implementors didn't read further either. 
  :)
 
  Nah, I won't take that bet :)
 
   So I have to believe there are a *lot* of systems out there that do 
   support xHCI debug.
 
  Possibly. But enough to make an actual critical mass to motivate somebody
  to write code? Or do you get more bang-for-buck by fixing kgdb to support
  debugging over Ethernet?
 
  Well, code to support the xHCI debug capability has been written, see
  http://marc.info/?l=linux-usbm=135948845511047. But I did not get
  approval from my management to spend the time needed to integrate this
  into the kernel's kgdb support.
 
  Nick, if you are still interested in this, you could take a look at the
  above code, and see if you can work out how to modify it to make it work
  with kgdb. But you will need a PC that has a debug-capable xHCI
  controller in order to test it. If you have PC or laptop with USB 3.0
  built-in that has the Windows 8 logo, I think there's a good chance you
  already have one. Or, according to
  http://pete.akeo.ie/2011/08/do-necrenesas-upd720200-based-usb-30.html,
  plug-in USB 3.0 host cards that use the newer Renesas uPD720201 chipset
  also have the debug capability.
 
  Note that the above patch is against a pretty old kernel (3.6), so the
  first thing you would need to do is forward-port it to work on the
  latest kernel. As a plus, that would give you some real experience
  working with kernel code, which everyone seems to agree you need ;)
 
  --
  Paul
 

 Paul ,
 My computer is rather old now as of Sandy Bridge days, so I probably
 can't test the patch
 on my own machine. However I will look at the code and see if I can
 forward port it
 against the usb git tree I have a current version of. In addition I
 would like the new xhci
 maintainers information in  order to send out a patch with the
 Maintainer for xhci updated.

 Sarah already told you who the new maintainer is, and then CCed him
 on this thread. Hint: There is a file name 'MAINTAINERS' in the root
 of the kernel tree, which tells you who the maintainers are for all of
 the subsystems. Please read Documentation/SubmittingPatches, it has a
 lot of information like this that you need to know.

 --
 Paul

Thanks I will read this file and thanks for the information. I known
where the file is I will
add the information then.
Regards Nick
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Sarah Sharp]

On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote:
 On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman
 paul.zimmer...@synopsys.com wrote:
  From: Nick Krause [mailto:xerofo...@gmail.com]

[snip]

  Paul ,
  My computer is rather old now as of Sandy Bridge days, so I probably
  can't test the patch
  on my own machine. However I will look at the code and see if I can
  forward port it
  against the usb git tree I have a current version of. In addition I
  would like the new xhci
  maintainers information in  order to send out a patch with the
  Maintainer for xhci updated.
 
  Sarah already told you who the new maintainer is, and then CCed him
  on this thread. Hint: There is a file name 'MAINTAINERS' in the root
  of the kernel tree, which tells you who the maintainers are for all of
  the subsystems. Please read Documentation/SubmittingPatches, it has a
  lot of information like this that you need to know.
 
  --
  Paul
 
 Thanks I will read this file and thanks for the information. I known
 where the file is I will
 add the information then.

You may be looking at an older version of MAINTAINERS.  Mathias has only
been marked as the maintainer since 3.15.  Which kernel version are you
working on?

Sarah Sharp
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Nick Krause]

On Mon, Aug 4, 2014 at 8:12 PM, Sarah Sharp
sarah.a.sh...@linux.intel.com wrote:
 On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote:
 On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman
 paul.zimmer...@synopsys.com wrote:
  From: Nick Krause [mailto:xerofo...@gmail.com]

 [snip]

  Paul ,
  My computer is rather old now as of Sandy Bridge days, so I probably
  can't test the patch
  on my own machine. However I will look at the code and see if I can
  forward port it
  against the usb git tree I have a current version of. In addition I
  would like the new xhci
  maintainers information in  order to send out a patch with the
  Maintainer for xhci updated.
 
  Sarah already told you who the new maintainer is, and then CCed him
  on this thread. Hint: There is a file name 'MAINTAINERS' in the root
  of the kernel tree, which tells you who the maintainers are for all of
  the subsystems. Please read Documentation/SubmittingPatches, it has a
  lot of information like this that you need to know.
 
  --
  Paul
 
 Thanks I will read this file and thanks for the information. I known
 where the file is I will
 add the information then.

 You may be looking at an older version of MAINTAINERS.  Mathias has only
 been marked as the maintainer since 3.15.  Which kernel version are you
 working on?

 Sarah Sharp

Hey Sarah,
Sorry about that but I am working on the latest tree from linus using
git and I checked seems he is there,
I didn't known it was updated.
Sorry and Thanks Nick
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Nick Krause]

On Mon, Aug 4, 2014 at 9:33 PM, Nick Krause xerofo...@gmail.com wrote:
 On Mon, Aug 4, 2014 at 8:12 PM, Sarah Sharp
 sarah.a.sh...@linux.intel.com wrote:
 On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote:
 On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman
 paul.zimmer...@synopsys.com wrote:
  From: Nick Krause [mailto:xerofo...@gmail.com]

 [snip]

  Paul ,
  My computer is rather old now as of Sandy Bridge days, so I probably
  can't test the patch
  on my own machine. However I will look at the code and see if I can
  forward port it
  against the usb git tree I have a current version of. In addition I
  would like the new xhci
  maintainers information in  order to send out a patch with the
  Maintainer for xhci updated.
 
  Sarah already told you who the new maintainer is, and then CCed him
  on this thread. Hint: There is a file name 'MAINTAINERS' in the root
  of the kernel tree, which tells you who the maintainers are for all of
  the subsystems. Please read Documentation/SubmittingPatches, it has a
  lot of information like this that you need to know.
 
  --
  Paul
 
 Thanks I will read this file and thanks for the information. I known
 where the file is I will
 add the information then.

 You may be looking at an older version of MAINTAINERS.  Mathias has only
 been marked as the maintainer since 3.15.  Which kernel version are you
 working on?

 Sarah Sharp

I am going to send out my work on the project you sent me I hope it's
Ok if not feel free
to tell me why. I did this against linus's tree but other then that it
should work.
Regards Nick
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Nick Krause]

On Mon, Aug 4, 2014 at 11:18 PM, Nick Krause xerofo...@gmail.com wrote:
 On Mon, Aug 4, 2014 at 9:33 PM, Nick Krause xerofo...@gmail.com wrote:
 On Mon, Aug 4, 2014 at 8:12 PM, Sarah Sharp
 sarah.a.sh...@linux.intel.com wrote:
 On Mon, Aug 04, 2014 at 07:11:07PM -0400, Nick Krause wrote:
 On Mon, Aug 4, 2014 at 7:03 PM, Paul Zimmerman
 paul.zimmer...@synopsys.com wrote:
  From: Nick Krause [mailto:xerofo...@gmail.com]

 [snip]

  Paul ,
  My computer is rather old now as of Sandy Bridge days, so I probably
  can't test the patch
  on my own machine. However I will look at the code and see if I can
  forward port it
  against the usb git tree I have a current version of. In addition I
  would like the new xhci
  maintainers information in  order to send out a patch with the
  Maintainer for xhci updated.
 
  Sarah already told you who the new maintainer is, and then CCed him
  on this thread. Hint: There is a file name 'MAINTAINERS' in the root
  of the kernel tree, which tells you who the maintainers are for all of
  the subsystems. Please read Documentation/SubmittingPatches, it has a
  lot of information like this that you need to know.
 
  --
  Paul
 
 Thanks I will read this file and thanks for the information. I known
 where the file is I will
 add the information then.

 You may be looking at an older version of MAINTAINERS.  Mathias has only
 been marked as the maintainer since 3.15.  Which kernel version are you
 working on?

 Sarah Sharp

 I am going to send out my work on the project you sent me I hope it's
 Ok if not feel free
 to tell me why. I did this against linus's tree but other then that it
 should work.
 Regards Nick

In addition,
I just sent it a few hours ago. Please let me known tomorrow if it's fine.
I am assuming based off my other work it's not.
Nick
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Nick Krause]

On Sat, Aug 2, 2014 at 9:48 AM, Alan Stern  wrote:
> On Sat, 2 Aug 2014, Nick Krause wrote:
>
>> Hey Sharp,
>> After reading around seems people want support for usb debugging in
>> kgdb or other usb based solutions.
>> If you and the other developers are able to help me out a bit as I am
>> new I can definitively write this
>> area of kgdb support.
>
> Doesn't kgdb already support USB for debugging?
>
> Alan Stern
>
I am not sure, I can check  the documentation in the kernel first to see,
but from my understanding it seems not.
Regards Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Alan Stern]

On Sat, 2 Aug 2014, Nick Krause wrote:

> Hey Sharp,
> After reading around seems people want support for usb debugging in
> kgdb or other usb based solutions.
> If you and the other developers are able to help me out a bit as I am
> new I can definitively write this
> area of kgdb support.

Doesn't kgdb already support USB for debugging?

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Alan Stern]

On Sat, 2 Aug 2014, Nick Krause wrote:

 Hey Sharp,
 After reading around seems people want support for usb debugging in
 kgdb or other usb based solutions.
 If you and the other developers are able to help me out a bit as I am
 new I can definitively write this
 area of kgdb support.

Doesn't kgdb already support USB for debugging?

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Kernel Debugging Support

[Nick Krause]

On Sat, Aug 2, 2014 at 9:48 AM, Alan Stern st...@rowland.harvard.edu wrote:
 On Sat, 2 Aug 2014, Nick Krause wrote:

 Hey Sharp,
 After reading around seems people want support for usb debugging in
 kgdb or other usb based solutions.
 If you and the other developers are able to help me out a bit as I am
 new I can definitively write this
 area of kgdb support.

 Doesn't kgdb already support USB for debugging?

 Alan Stern

I am not sure, I can check  the documentation in the kernel first to see,
but from my understanding it seems not.
Regards Nick
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Kernel Debugging Support

[Nick Krause]

Hey Sharp,
After reading around seems people want support for usb debugging in
kgdb or other usb based solutions.
If you and the other developers are able to help me out a bit as I am
new I can definitively write this
area of kgdb support.
Regards Nick
P.S. If  you want Sharp I can change the commit message on my other
commit you didn't like if me or you
talk to Greg in order to remove in from mainline, if no that's OK too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Kernel Debugging Support

[Nick Krause]

Hey Sharp,
After reading around seems people want support for usb debugging in
kgdb or other usb based solutions.
If you and the other developers are able to help me out a bit as I am
new I can definitively write this
area of kgdb support.
Regards Nick
P.S. If  you want Sharp I can change the commit message on my other
commit you didn't like if me or you
talk to Greg in order to remove in from mainline, if no that's OK too.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 00/22] Add gdb python scripts as kernel debugging helpers

[Andi Kleen]

I looked through the patches and from a quick look they all look good to
me. I especially like the support for per cpu variables. I had a lot of 
trouble with those in the past with various debugging setups.

Acked-by: Andi Kleen 

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v8 00/22] Add gdb python scripts as kernel debugging helpers

[Andi Kleen]

I looked through the patches and from a quick look they all look good to
me. I especially like the support for per cpu variables. I had a lot of 
trouble with those in the past with various debugging setups.

Acked-by: Andi Kleen a...@linux.intel.com

-Andi
-- 
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v8 00/22] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Some time passed since the last posting. Basically, this round comes
with two changes:
 - make the code Python 3 compatible [Pantelis Koukousoulas]
 - rebase over recent Linux version, resolving a trivial conflict

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

I'm still hoping someone will move this forward via his tree towards
upstream. Please let me know if any changes are required to enable this.

Jan

CC: "David S. Miller" 
CC: Fenghua Yu 
CC: Kay Sievers 
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
CC: Michal Marek 
CC: Pantelis Koukousoulas 
CC: Rob Landley 
CC: Rusty Russell 
CC: sparcli...@vger.kernel.org
CC: Tony Luck 

Jan Kiszka (21):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation

Pantelis Koukousoulas (1):
  scripts/gdb: Port to python3 / gdb7.7

 Documentation/gdb-kernel-debugging.txt | 160 +++
 Makefile   |   6 +-
 kernel/module.c|   9 +-
 lib/Kconfig.debug  |  11 +++
 scripts/Makefile   |   3 +-
 scripts/gdb/Makefile   |  11 +++
 scripts/gdb/linux/Makefile |   9 ++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 142 
 scripts/gdb/linux/dmesg.py |  65 +
 scripts/gdb/linux/modules.py   | 114 ++
 scripts/gdb/linux/symbols.py   | 166 +
 scripts/gdb/linux/tasks.py | 110 ++
 scripts/gdb/linux/utils.py | 156 +++
 scripts/gdb/vmlinux-gdb.py |  30 ++
 15 files changed, 988 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
1.8.1.1.298.ge7eed54

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v8 00/22] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Some time passed since the last posting. Basically, this round comes
with two changes:
 - make the code Python 3 compatible [Pantelis Koukousoulas]
 - rebase over recent Linux version, resolving a trivial conflict

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

I'm still hoping someone will move this forward via his tree towards
upstream. Please let me know if any changes are required to enable this.

Jan

CC: David S. Miller da...@davemloft.net
CC: Fenghua Yu fenghua...@intel.com
CC: Kay Sievers k...@vrfy.org
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
CC: Michal Marek mma...@suse.cz
CC: Pantelis Koukousoulas pkt...@gmail.com
CC: Rob Landley r...@landley.net
CC: Rusty Russell ru...@rustcorp.com.au
CC: sparcli...@vger.kernel.org
CC: Tony Luck tony.l...@intel.com

Jan Kiszka (21):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation

Pantelis Koukousoulas (1):
  scripts/gdb: Port to python3 / gdb7.7

 Documentation/gdb-kernel-debugging.txt | 160 +++
 Makefile   |   6 +-
 kernel/module.c|   9 +-
 lib/Kconfig.debug  |  11 +++
 scripts/Makefile   |   3 +-
 scripts/gdb/Makefile   |  11 +++
 scripts/gdb/linux/Makefile |   9 ++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 142 
 scripts/gdb/linux/dmesg.py |  65 +
 scripts/gdb/linux/modules.py   | 114 ++
 scripts/gdb/linux/symbols.py   | 166 +
 scripts/gdb/linux/tasks.py | 110 ++
 scripts/gdb/linux/utils.py | 156 +++
 scripts/gdb/vmlinux-gdb.py |  30 ++
 15 files changed, 988 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
1.8.1.1.298.ge7eed54

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 00/21] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Another round, addressing the following review comments on v6:
 - introduce CONFIG_GDB_SCRIPTS to enable/disable this feature
 - adjust documentation and fix a minor detail

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

Jan

CC: "David S. Miller" 
CC: Fenghua Yu 
CC: Kay Sievers 
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
CC: Michal Marek 
CC: Rob Landley 
CC: Rusty Russell 
CC: sparcli...@vger.kernel.org
CC: Tony Luck 

Jan Kiszka (21):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation

 Documentation/gdb-kernel-debugging.txt | 160 +++
 Makefile   |   5 +-
 kernel/module.c|   9 +-
 lib/Kconfig.debug  |  11 +++
 scripts/Makefile   |   3 +-
 scripts/gdb/Makefile   |  11 +++
 scripts/gdb/linux/Makefile |   9 ++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 139 +++
 scripts/gdb/linux/dmesg.py |  64 +
 scripts/gdb/linux/modules.py   | 111 ++
 scripts/gdb/linux/symbols.py   | 166 +
 scripts/gdb/linux/tasks.py | 108 +
 scripts/gdb/linux/utils.py | 156 +++
 scripts/gdb/vmlinux-gdb.py |  30 ++
 15 files changed, 978 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
1.8.1.1.298.ge7eed54

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v7 00/21] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Another round, addressing the following review comments on v6:
 - introduce CONFIG_GDB_SCRIPTS to enable/disable this feature
 - adjust documentation and fix a minor detail

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

Jan

CC: David S. Miller da...@davemloft.net
CC: Fenghua Yu fenghua...@intel.com
CC: Kay Sievers k...@vrfy.org
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
CC: Michal Marek mma...@suse.cz
CC: Rob Landley r...@landley.net
CC: Rusty Russell ru...@rustcorp.com.au
CC: sparcli...@vger.kernel.org
CC: Tony Luck tony.l...@intel.com

Jan Kiszka (21):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation

 Documentation/gdb-kernel-debugging.txt | 160 +++
 Makefile   |   5 +-
 kernel/module.c|   9 +-
 lib/Kconfig.debug  |  11 +++
 scripts/Makefile   |   3 +-
 scripts/gdb/Makefile   |  11 +++
 scripts/gdb/linux/Makefile |   9 ++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 139 +++
 scripts/gdb/linux/dmesg.py |  64 +
 scripts/gdb/linux/modules.py   | 111 ++
 scripts/gdb/linux/symbols.py   | 166 +
 scripts/gdb/linux/tasks.py | 108 +
 scripts/gdb/linux/utils.py | 156 +++
 scripts/gdb/vmlinux-gdb.py |  30 ++
 15 files changed, 978 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
1.8.1.1.298.ge7eed54

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 00/21] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

It's been a while since my last update of these patches. This one is
mostly about cleaning up and making some details more convenient:
 - proper registration of module data segments to access module
   variables - this obsoletes lx_modvar again
 - stable breakpoint target on do_init_module in order to track module
   loading more reliably from the debugger
 - internal refactoring with the aim to "pythonize" the scripts (credits
   for all valuable suggestions belong to Tatiana, many thanks, for
   improper implementations to me)

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

Jan

CC: "David S. Miller" 
CC: Fenghua Yu 
CC: Kay Sievers 
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
CC: Michal Marek 
CC: Rob Landley 
CC: sparcli...@vger.kernel.org
CC: Tony Luck 

Jan Kiszka (21):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation

 Documentation/gdb-kernel-debugging.txt | 159 +++
 Makefile   |   5 +-
 kernel/module.c|   9 +-
 scripts/Makefile   |   3 +-
 scripts/gdb/Makefile   |  11 +++
 scripts/gdb/linux/Makefile |   9 ++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 139 +++
 scripts/gdb/linux/dmesg.py |  64 +
 scripts/gdb/linux/modules.py   | 111 ++
 scripts/gdb/linux/symbols.py   | 166 +
 scripts/gdb/linux/tasks.py | 108 +
 scripts/gdb/linux/utils.py | 156 +++
 scripts/gdb/vmlinux-gdb.py |  30 ++
 14 files changed, 966 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
1.8.1.1.298.ge7eed54

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 00/21] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

It's been a while since my last update of these patches. This one is
mostly about cleaning up and making some details more convenient:
 - proper registration of module data segments to access module
   variables - this obsoletes lx_modvar again
 - stable breakpoint target on do_init_module in order to track module
   loading more reliably from the debugger
 - internal refactoring with the aim to pythonize the scripts (credits
   for all valuable suggestions belong to Tatiana, many thanks, for
   improper implementations to me)

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

Jan

CC: David S. Miller da...@davemloft.net
CC: Fenghua Yu fenghua...@intel.com
CC: Kay Sievers k...@vrfy.org
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
CC: Michal Marek mma...@suse.cz
CC: Rob Landley r...@landley.net
CC: sparcli...@vger.kernel.org
CC: Tony Luck tony.l...@intel.com

Jan Kiszka (21):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration class
  scripts/gdb: Add lx-symbols command
  module: Do not inline do_init_module
  scripts/gdb: Add automatic symbol reloading on module insertion
  scripts/gdb: Add internal helper and convenience function to look up a
module
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration class
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add class to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation

 Documentation/gdb-kernel-debugging.txt | 159 +++
 Makefile   |   5 +-
 kernel/module.c|   9 +-
 scripts/Makefile   |   3 +-
 scripts/gdb/Makefile   |  11 +++
 scripts/gdb/linux/Makefile |   9 ++
 scripts/gdb/linux/__init__.py  |   0
 scripts/gdb/linux/cpus.py  | 139 +++
 scripts/gdb/linux/dmesg.py |  64 +
 scripts/gdb/linux/modules.py   | 111 ++
 scripts/gdb/linux/symbols.py   | 166 +
 scripts/gdb/linux/tasks.py | 108 +
 scripts/gdb/linux/utils.py | 156 +++
 scripts/gdb/vmlinux-gdb.py |  30 ++
 14 files changed, 966 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/linux/Makefile
 create mode 100644 scripts/gdb/linux/__init__.py
 create mode 100644 scripts/gdb/linux/cpus.py
 create mode 100644 scripts/gdb/linux/dmesg.py
 create mode 100644 scripts/gdb/linux/modules.py
 create mode 100644 scripts/gdb/linux/symbols.py
 create mode 100644 scripts/gdb/linux/tasks.py
 create mode 100644 scripts/gdb/linux/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
1.8.1.1.298.ge7eed54

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 00/20] Add gdb python scripts as kernel debugging helpers

[Borislav Petkov]

On Tue, Jan 29, 2013 at 01:37:43PM +0100, Jan Kiszka wrote:
> Version 5 comes with the following changes:
>  - moved tutorial into Documentation/gdb-kernel-debugging.txt
>  - improved caching of gdb.Type objects, ensure they are in sync with
>currently loaded symbols
>  - added new functions and commands
> - lx_module -- Find module by name and return the module variable
> - lx_modvar -- Return global variable of a module
> - lx-lsmod -- List currently loaded modules
> 
> See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
> the original description and
> 
> git://git.kiszka.org/linux.git queues/gdb-scripts
> 
> for the latest version.

Ok, I've seldomly shown any feelings when acking a patch{,set} besides
maybe "hm, ok, fine" but this patchset is very very cool and it is an
enormous fun playing with it.

So maybe this is the most enthusiasm I've shown sofar:

Emphatically-acked-by: Borislav Petkov 

Thanks Jan, very good work!

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 00/20] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Version 5 comes with the following changes:
 - moved tutorial into Documentation/gdb-kernel-debugging.txt
 - improved caching of gdb.Type objects, ensure they are in sync with
   currently loaded symbols
 - added new functions and commands
- lx_module -- Find module by name and return the module variable
- lx_modvar -- Return global variable of a module
- lx-lsmod -- List currently loaded modules

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

Jan

CC: "David S. Miller" 
CC: Fenghua Yu 
CC: Kay Sievers 
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
CC: Michal Marek 
CC: Rob Landley 
CC: sparcli...@vger.kernel.org
CC: Tony Luck 

Jan Kiszka (20):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration helper
  scripts/gdb: Add lx-symbols command
  scripts/gdb: Add internal helper and convenience function to look up
a module
  scripts/gdb: Add lx_modvar convenience function
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration helper
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add helper to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation

 Documentation/gdb-kernel-debugging.txt |  155 +++
 Makefile   |5 +-
 scripts/Makefile   |3 +-
 scripts/gdb/Makefile   |9 ++
 scripts/gdb/dmesg.py   |   63 +
 scripts/gdb/module.py  |  149 ++
 scripts/gdb/percpu.py  |  110 ++
 scripts/gdb/symbols.py |  147 +
 scripts/gdb/task.py|   99 
 scripts/gdb/utils.py   |  158 
 scripts/gdb/vmlinux-gdb.py |   29 ++
 11 files changed, 925 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/dmesg.py
 create mode 100644 scripts/gdb/module.py
 create mode 100644 scripts/gdb/percpu.py
 create mode 100644 scripts/gdb/symbols.py
 create mode 100644 scripts/gdb/task.py
 create mode 100644 scripts/gdb/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
1.7.3.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5 00/20] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Version 5 comes with the following changes:
 - moved tutorial into Documentation/gdb-kernel-debugging.txt
 - improved caching of gdb.Type objects, ensure they are in sync with
   currently loaded symbols
 - added new functions and commands
- lx_module -- Find module by name and return the module variable
- lx_modvar -- Return global variable of a module
- lx-lsmod -- List currently loaded modules

See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
the original description and

git://git.kiszka.org/linux.git queues/gdb-scripts

for the latest version.

Jan

CC: David S. Miller da...@davemloft.net
CC: Fenghua Yu fenghua...@intel.com
CC: Kay Sievers k...@vrfy.org
CC: linux-...@vger.kernel.org
CC: linux-i...@vger.kernel.org
CC: linux-kbu...@vger.kernel.org
CC: Michal Marek mma...@suse.cz
CC: Rob Landley r...@landley.net
CC: sparcli...@vger.kernel.org
CC: Tony Luck tony.l...@intel.com

Jan Kiszka (20):
  scripts/gdb: Add infrastructure
  scripts/gdb: Add cache for type objects
  scripts/gdb: Add container_of helper and convenience function
  scripts/gdb: Add module iteration helper
  scripts/gdb: Add lx-symbols command
  scripts/gdb: Add internal helper and convenience function to look up
a module
  scripts/gdb: Add lx_modvar convenience function
  scripts/gdb: Add get_target_endianness helper
  scripts/gdb: Add read_u16/32/64 helpers
  scripts/gdb: Add lx-dmesg command
  scripts/gdb: Add task iteration helper
  scripts/gdb: Add helper and convenience function to look up tasks
  scripts/gdb: Add is_target_arch helper
  scripts/gdb: Add internal helper and convenience function to retrieve
thread_info
  scripts/gdb: Add get_gdbserver_type helper
  scripts/gdb: Add internal helper and convenience function for per-cpu
lookup
  scripts/gdb: Add lx_current convenience function
  scripts/gdb: Add helper to iterate over CPU masks
  scripts/gdb: Add lx-lsmod command
  scripts/gdb: Add basic documentation

 Documentation/gdb-kernel-debugging.txt |  155 +++
 Makefile   |5 +-
 scripts/Makefile   |3 +-
 scripts/gdb/Makefile   |9 ++
 scripts/gdb/dmesg.py   |   63 +
 scripts/gdb/module.py  |  149 ++
 scripts/gdb/percpu.py  |  110 ++
 scripts/gdb/symbols.py |  147 +
 scripts/gdb/task.py|   99 
 scripts/gdb/utils.py   |  158 
 scripts/gdb/vmlinux-gdb.py |   29 ++
 11 files changed, 925 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/gdb-kernel-debugging.txt
 create mode 100644 scripts/gdb/Makefile
 create mode 100644 scripts/gdb/dmesg.py
 create mode 100644 scripts/gdb/module.py
 create mode 100644 scripts/gdb/percpu.py
 create mode 100644 scripts/gdb/symbols.py
 create mode 100644 scripts/gdb/task.py
 create mode 100644 scripts/gdb/utils.py
 create mode 100644 scripts/gdb/vmlinux-gdb.py

-- 
1.7.3.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 00/20] Add gdb python scripts as kernel debugging helpers

[Borislav Petkov]

On Tue, Jan 29, 2013 at 01:37:43PM +0100, Jan Kiszka wrote:
 Version 5 comes with the following changes:
  - moved tutorial into Documentation/gdb-kernel-debugging.txt
  - improved caching of gdb.Type objects, ensure they are in sync with
currently loaded symbols
  - added new functions and commands
 - lx_module -- Find module by name and return the module variable
 - lx_modvar -- Return global variable of a module
 - lx-lsmod -- List currently loaded modules
 
 See http://lkml.indiana.edu/hypermail/linux/kernel/1210.0/01598.html for
 the original description and
 
 git://git.kiszka.org/linux.git queues/gdb-scripts
 
 for the latest version.

Ok, I've seldomly shown any feelings when acking a patch{,set} besides
maybe hm, ok, fine but this patchset is very very cool and it is an
enormous fun playing with it.

So maybe this is the most enthusiasm I've shown sofar:

Emphatically-acked-by: Borislav Petkov b...@suse.de

Thanks Jan, very good work!

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

On 2013-01-23 12:32, Borislav Petkov wrote:
> Ok, first of all, I gotta say, this is very cool stuff, thanks for doing
> this. I'm playing with your tutorial and I'm having some trouble, see
> below:
> 
> On Mon, Jan 21, 2013 at 06:06:07PM +0100, Jan Kiszka wrote:
>>  o Let's examine the current task a bit:
>> (gdb) p ().pid
> 
> when I do that, it says:
> 
> (gdb) p ().pid
> A syntax error in expression, near `).pid'

Ouch, my git-send script ate all the "$foo" in the cover letter :(. It
has to be $lx_current, $lx_per_cpu and $container_of. Will write an
add-on patch that adds the tutorial as a text file later on.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Borislav Petkov]

Ok, first of all, I gotta say, this is very cool stuff, thanks for doing
this. I'm playing with your tutorial and I'm having some trouble, see
below:

On Mon, Jan 21, 2013 at 06:06:07PM +0100, Jan Kiszka wrote:
>  o Let's examine the current task a bit:
> (gdb) p ().pid

when I do that, it says:

(gdb) p ().pid
A syntax error in expression, near `).pid'

Here's what I do:

$ gdb --data-directory $(pwd)/scripts/gdb/ ./vmlinux
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /w/kernel/linux-2.6/vmlinux...done.
(gdb) target remote :1234
Remote debugging using :1234
[New Thread 2]
[Switching to Thread 2]
default_idle () at arch/x86/kernel/process.c:391
391 current_thread_info()->status |= TS_POLLING;
(gdb) p ().pid
A syntax error in expression, near `).pid'.
(gdb) show data-directory
GDB's data directory is "/w/kernel/linux-2.6/scripts/gdb/".
(gdb) lx-symbols
loading vmlinux
no modules found
(gdb) p ().pid
A syntax error in expression, near `).pid'.
(gdb)

So, I thought I should point it explicitly to the python scripts with
--data-directory but it still doesn't fly. And gdb is 7.4.1 so it should
be recent enough.

lx-dmesg works, for example:

(gdb) lx-dmesg
[ 0.00] Linux version 3.8.0-rc4+ (boris@pd) (gcc version 4.7.2 (Debian 
4.7.2-5) ) #2 SMP PREEMPT Wed Jan 23 11:59:58 CET 2013
[ 0.00] Command line: vga=0 root=/dev/sda1 debug ignore_loglevel 
console=ttyS0,115200 console=tty0
[ 0.00] e820: BIOS-provided physical RAM map:
[ 0.00] BIOS-e820: [mem 0x-0x0009f3ff] usable
[ 0.00] BIOS-e820: [mem 0x0009f400-0x0009] reserved
[ 0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[ 0.00] BIOS-e820: [mem 0x0010-0x7fffdfff] usable
...

So what am I missing?

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Borislav Petkov]

Ok, first of all, I gotta say, this is very cool stuff, thanks for doing
this. I'm playing with your tutorial and I'm having some trouble, see
below:

On Mon, Jan 21, 2013 at 06:06:07PM +0100, Jan Kiszka wrote:
  o Let's examine the current task a bit:
 (gdb) p ().pid

when I do that, it says:

(gdb) p ().pid
A syntax error in expression, near `).pid'

Here's what I do:

$ gdb --data-directory $(pwd)/scripts/gdb/ ./vmlinux
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /w/kernel/linux-2.6/vmlinux...done.
(gdb) target remote :1234
Remote debugging using :1234
[New Thread 2]
[Switching to Thread 2]
default_idle () at arch/x86/kernel/process.c:391
391 current_thread_info()-status |= TS_POLLING;
(gdb) p ().pid
A syntax error in expression, near `).pid'.
(gdb) show data-directory
GDB's data directory is /w/kernel/linux-2.6/scripts/gdb/.
(gdb) lx-symbols
loading vmlinux
no modules found
(gdb) p ().pid
A syntax error in expression, near `).pid'.
(gdb)

So, I thought I should point it explicitly to the python scripts with
--data-directory but it still doesn't fly. And gdb is 7.4.1 so it should
be recent enough.

lx-dmesg works, for example:

(gdb) lx-dmesg
[ 0.00] Linux version 3.8.0-rc4+ (boris@pd) (gcc version 4.7.2 (Debian 
4.7.2-5) ) #2 SMP PREEMPT Wed Jan 23 11:59:58 CET 2013
[ 0.00] Command line: vga=0 root=/dev/sda1 debug ignore_loglevel 
console=ttyS0,115200 console=tty0
[ 0.00] e820: BIOS-provided physical RAM map:
[ 0.00] BIOS-e820: [mem 0x-0x0009f3ff] usable
[ 0.00] BIOS-e820: [mem 0x0009f400-0x0009] reserved
[ 0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[ 0.00] BIOS-e820: [mem 0x0010-0x7fffdfff] usable
...

So what am I missing?

Thanks.

-- 
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

On 2013-01-23 12:32, Borislav Petkov wrote:
 Ok, first of all, I gotta say, this is very cool stuff, thanks for doing
 this. I'm playing with your tutorial and I'm having some trouble, see
 below:
 
 On Mon, Jan 21, 2013 at 06:06:07PM +0100, Jan Kiszka wrote:
  o Let's examine the current task a bit:
 (gdb) p ().pid
 
 when I do that, it says:
 
 (gdb) p ().pid
 A syntax error in expression, near `).pid'

Ouch, my git-send script ate all the $foo in the cover letter :(. It
has to be $lx_current, $lx_per_cpu and $container_of. Will write an
add-on patch that adds the tutorial as a text file later on.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

On 2013-01-21 23:15, Andi Kleen wrote:
>>
>>  o Install that kernel on the guest
> 
> If you use a static kernel you can also do 
> 
> - copy the initrd out of the guest once
> 
> qemu...  -bzImage kernel -initrd initrd

-kernel/append/initrd, of course.

> 
> This saves the step of getting the kernel into the kernel.
> Doesn't work with modules unfortunately.

True. An alternative can be nfsroot. Or root on virtfs.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

On 2013-01-21 22:21, Andi Kleen wrote:
>>
>> And this is a tutorial for the gdb extension using QEMU/KVM as target
>> platform:
> 
> Can you add the tutorial as a file in Documentation? 

Sure, will do.

> Other than that everything looks good to me.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

On 2013-01-21 22:21, Andi Kleen wrote:

 And this is a tutorial for the gdb extension using QEMU/KVM as target
 platform:
 
 Can you add the tutorial as a file in Documentation? 

Sure, will do.

 Other than that everything looks good to me.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

On 2013-01-21 23:15, Andi Kleen wrote:

  o Install that kernel on the guest
 
 If you use a static kernel you can also do 
 
 - copy the initrd out of the guest once
 
 qemu...  -bzImage kernel -initrd initrd

-kernel/append/initrd, of course.

 
 This saves the step of getting the kernel into the kernel.
 Doesn't work with modules unfortunately.

True. An alternative can be nfsroot. Or root on virtfs.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Andi Kleen]

> 
>  o Install that kernel on the guest

If you use a static kernel you can also do 

- copy the initrd out of the guest once

qemu...  -bzImage kernel -initrd initrd

This saves the step of getting the kernel into the kernel.
Doesn't work with modules unfortunately.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Ben Widawsky]

On Mon, 21 Jan 2013 18:06:07 +0100
Jan Kiszka  wrote:

> Version 4 of this series is a rebase over latest 3.8-rc4+. Moreover, I
> updated the mechanism that implements automatic symbol loading for new
> modules. It was affected by the refactorings around finit_module.
> 
> While waiting for feedback who could imagine picking this up for merge,
> I wrote a tiny tutorial, see below.
> 
> 
> Here is the original series intro again:
> 
> This adds the infrastructure and first tools that make kernel debugging
> through gdb more comfortable. Since 7.0, gdb supports python scripting.
> And this opens the doors to automate steps like the tedious loading of
> module symbols at the right address, resolving per-cpu variables or even
> retrieving the current kernel log without resuming an stopped target.
> 
> Many of the helpers naturally depend on the layout of structures or
> internal mechanics of the kernel. So the best place to maintain such
> things, keeping them consistent with the corresponding kernel is, well,
> the kernel itself.
> 
> While these scripts have been originally developed for debugging via
> QEMU/KVM, I've now also added the required bits for KGDB. Works fine,
> but as QEMU/KVM tends to outperform KGDB it remains the recommendation
> - when available.
> 
> There are two architecture dependencies so far, one regarding per-cpu,
> the other regarding thread_info calculation. None of them I was able to
> test on a target, so I'm counting on review/testing by the corresponding
> communities.
> 
> This series should be considered the foundation of much more kernel
> state exploration helpers, e.g. around tasks, timers, locks, sockets -
> I guess people will have even more ideas.
> 
> 
> And this is a tutorial for the gdb extension using QEMU/KVM as target
> platform:
> 
>  o Set up a virtual Linux machine for KVM (see www.linux-kvm.org and
>www.qemu.org for more details)
> 
>  o Build the kernel with this series applied, enabling CONFIG_DEBUG_INFO
>(but leave CONFIG_DEBUG_INFO_REDUCED off)
> 
>  o Install that kernel on the guest
> 
>  o Enable the gdb stub of QEMU/KVM, either
> - at VM startup time by appending "-s" to the QEMU command line
>or
> - during runtime by issuing "gdbserver" from the QEMU monitor
>   console
> 
>  o cd /path/to/linux-build
> 
>  o Start gdb: gdb vmlinux
> 
>  o Attach to the booted guest:
> (gdb) target remote :1234
> 
>  o Load module (and main kernel) symbols:
> (gdb) lx-symbols
> loading vmlinux
> scanning for modules in /home/user/linux/build
> loading @0xa002: 
> /home/user/linux/build/net/netfilter/xt_tcpudp.ko
> loading @0xa0016000: 
> /home/user/linux/build/net/netfilter/xt_pkttype.ko
> loading @0xa0002000: 
> /home/user/linux/build/net/netfilter/xt_limit.ko
> loading @0xa00ca000: 
> /home/user/linux/build/net/packet/af_packet.ko
> loading @0xa003c000: /home/user/linux/build/fs/fuse/fuse.ko
> ...
> loading @0xa000: 
> /home/user/linux/build/drivers/ata/ata_generic.ko
> 
>  o Set a breakpoint on some not yet loaded module function, e.g.:
> (gdb) b btrfs_init_sysfs
> Function "btrfs_init_sysfs" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) y
> Breakpoint 1 (btrfs_init_sysfs) pending.
> 
>  o Continue the target
> 
>  o Load the module on the target and watch what happens:
> loading @0xa0034000: /home/user/linux/build/lib/libcrc32c.ko
> loading @0xa005: 
> /home/user/linux/build/lib/lzo/lzo_compress.ko
> loading @0xa006e000: 
> /home/user/linux/build/lib/zlib_deflate/zlib_deflate.ko
> loading @0xa01b1000: /home/user/linux/build/fs/btrfs/btrfs.ko
> 
> Breakpoint 1, btrfs_init_sysfs () at /home/user/linux/fs/btrfs/sysfs.c:36
> 36  btrfs_kset = kset_create_and_add("btrfs", NULL, fs_kobj);
> 
>  o Let's examine the current task a bit:
> (gdb) p ().pid
>  = 4998
> (gdb) p ().comm
>  = "modprobe\000\000\000\000\000\000\000"
> 
>  o Dump the log buffer of target kernel:
> (gdb) lx-dmesg
> [ 0.00] Initializing cgroup subsys cpuset
> [ 0.00] Initializing cgroup subsys cpu
> [ 0.00] Linux version 3.8.0-rc4-dbg+ (...
> [ 0.00] Command line: root=/dev/sda2 resume=/dev/sda1 vga=0x314
> [ 0.00] e820: BIOS-provided physical RAM map:
> [ 0.00] BIOS-e820: [mem 0x-0x0009fbff] 
> usable
> [ 0.00] BIOS-e820: [mem 0x0009fc00-0x000

Re: [PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Andi Kleen]

> 
> And this is a tutorial for the gdb extension using QEMU/KVM as target
> platform:

Can you add the tutorial as a file in Documentation? 
Other than that everything looks good to me.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Version 4 of this series is a rebase over latest 3.8-rc4+. Moreover, I
updated the mechanism that implements automatic symbol loading for new
modules. It was affected by the refactorings around finit_module.

While waiting for feedback who could imagine picking this up for merge,
I wrote a tiny tutorial, see below.


Here is the original series intro again:

This adds the infrastructure and first tools that make kernel debugging
through gdb more comfortable. Since 7.0, gdb supports python scripting.
And this opens the doors to automate steps like the tedious loading of
module symbols at the right address, resolving per-cpu variables or even
retrieving the current kernel log without resuming an stopped target.

Many of the helpers naturally depend on the layout of structures or
internal mechanics of the kernel. So the best place to maintain such
things, keeping them consistent with the corresponding kernel is, well,
the kernel itself.

While these scripts have been originally developed for debugging via
QEMU/KVM, I've now also added the required bits for KGDB. Works fine,
but as QEMU/KVM tends to outperform KGDB it remains the recommendation
- when available.

There are two architecture dependencies so far, one regarding per-cpu,
the other regarding thread_info calculation. None of them I was able to
test on a target, so I'm counting on review/testing by the corresponding
communities.

This series should be considered the foundation of much more kernel
state exploration helpers, e.g. around tasks, timers, locks, sockets -
I guess people will have even more ideas.


And this is a tutorial for the gdb extension using QEMU/KVM as target
platform:

 o Set up a virtual Linux machine for KVM (see www.linux-kvm.org and
   www.qemu.org for more details)

 o Build the kernel with this series applied, enabling CONFIG_DEBUG_INFO
   (but leave CONFIG_DEBUG_INFO_REDUCED off)

 o Install that kernel on the guest

 o Enable the gdb stub of QEMU/KVM, either
- at VM startup time by appending "-s" to the QEMU command line
   or
- during runtime by issuing "gdbserver" from the QEMU monitor
  console

 o cd /path/to/linux-build

 o Start gdb: gdb vmlinux

 o Attach to the booted guest:
(gdb) target remote :1234

 o Load module (and main kernel) symbols:
(gdb) lx-symbols
loading vmlinux
scanning for modules in /home/user/linux/build
loading @0xa002: 
/home/user/linux/build/net/netfilter/xt_tcpudp.ko
loading @0xa0016000: 
/home/user/linux/build/net/netfilter/xt_pkttype.ko
loading @0xa0002000: 
/home/user/linux/build/net/netfilter/xt_limit.ko
loading @0xa00ca000: /home/user/linux/build/net/packet/af_packet.ko
loading @0xa003c000: /home/user/linux/build/fs/fuse/fuse.ko
...
loading @0xa000: 
/home/user/linux/build/drivers/ata/ata_generic.ko

 o Set a breakpoint on some not yet loaded module function, e.g.:
(gdb) b btrfs_init_sysfs
Function "btrfs_init_sysfs" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (btrfs_init_sysfs) pending.

 o Continue the target

 o Load the module on the target and watch what happens:
loading @0xa0034000: /home/user/linux/build/lib/libcrc32c.ko
loading @0xa005: /home/user/linux/build/lib/lzo/lzo_compress.ko
loading @0xa006e000: 
/home/user/linux/build/lib/zlib_deflate/zlib_deflate.ko
loading @0xa01b1000: /home/user/linux/build/fs/btrfs/btrfs.ko

Breakpoint 1, btrfs_init_sysfs () at /home/user/linux/fs/btrfs/sysfs.c:36
36  btrfs_kset = kset_create_and_add("btrfs", NULL, fs_kobj);

 o Let's examine the current task a bit:
(gdb) p ().pid
 = 4998
(gdb) p ().comm
 = "modprobe\000\000\000\000\000\000\000"

 o Dump the log buffer of target kernel:
(gdb) lx-dmesg
[ 0.00] Initializing cgroup subsys cpuset
[ 0.00] Initializing cgroup subsys cpu
[ 0.00] Linux version 3.8.0-rc4-dbg+ (...
[ 0.00] Command line: root=/dev/sda2 resume=/dev/sda1 vga=0x314
[ 0.00] e820: BIOS-provided physical RAM map:
[ 0.00] BIOS-e820: [mem 0x-0x0009fbff] 
usable
[ 0.00] BIOS-e820: [mem 0x0009fc00-0x0009] 
reserved


 o Make use of the per-cpu helper for the current or a specified CPU:
(gdb) p ("runqueues").nr_running
 = 1
(gdb) p ("runqueues", 2).nr_running
 = 0

 o And now we are digging deep into hrtimers using the container_of
   helper:
(gdb) set  = ("hrtimer_bases").clock_base[0].active.next
(gdb) p *(, "struct hrtimer", "node")
 = {
  node = {
node = {
  __rb_parent_color = 18446612133355256072,
  rb_right = 0x0 ,
  rb_left = 0x0 
},
expires = {
 

[PATCH v4 00/13] Add gdb python scripts as kernel debugging helpers

[Jan Kiszka]

Version 4 of this series is a rebase over latest 3.8-rc4+. Moreover, I
updated the mechanism that implements automatic symbol loading for new
modules. It was affected by the refactorings around finit_module.

While waiting for feedback who could imagine picking this up for merge,
I wrote a tiny tutorial, see below.


Here is the original series intro again:

This adds the infrastructure and first tools that make kernel debugging
through gdb more comfortable. Since 7.0, gdb supports python scripting.
And this opens the doors to automate steps like the tedious loading of
module symbols at the right address, resolving per-cpu variables or even
retrieving the current kernel log without resuming an stopped target.

Many of the helpers naturally depend on the layout of structures or
internal mechanics of the kernel. So the best place to maintain such
things, keeping them consistent with the corresponding kernel is, well,
the kernel itself.

While these scripts have been originally developed for debugging via
QEMU/KVM, I've now also added the required bits for KGDB. Works fine,
but as QEMU/KVM tends to outperform KGDB it remains the recommendation
- when available.

There are two architecture dependencies so far, one regarding per-cpu,
the other regarding thread_info calculation. None of them I was able to
test on a target, so I'm counting on review/testing by the corresponding
communities.

This series should be considered the foundation of much more kernel
state exploration helpers, e.g. around tasks, timers, locks, sockets -
I guess people will have even more ideas.


And this is a tutorial for the gdb extension using QEMU/KVM as target
platform:

 o Set up a virtual Linux machine for KVM (see www.linux-kvm.org and
   www.qemu.org for more details)

 o Build the kernel with this series applied, enabling CONFIG_DEBUG_INFO
   (but leave CONFIG_DEBUG_INFO_REDUCED off)

 o Install that kernel on the guest

 o Enable the gdb stub of QEMU/KVM, either
- at VM startup time by appending -s to the QEMU command line
   or
- during runtime by issuing gdbserver from the QEMU monitor
  console

 o cd /path/to/linux-build

 o Start gdb: gdb vmlinux

 o Attach to the booted guest:
(gdb) target remote :1234

 o Load module (and main kernel) symbols:
(gdb) lx-symbols
loading vmlinux
scanning for modules in /home/user/linux/build
loading @0xa002: 
/home/user/linux/build/net/netfilter/xt_tcpudp.ko
loading @0xa0016000: 
/home/user/linux/build/net/netfilter/xt_pkttype.ko
loading @0xa0002000: 
/home/user/linux/build/net/netfilter/xt_limit.ko
loading @0xa00ca000: /home/user/linux/build/net/packet/af_packet.ko
loading @0xa003c000: /home/user/linux/build/fs/fuse/fuse.ko
...
loading @0xa000: 
/home/user/linux/build/drivers/ata/ata_generic.ko

 o Set a breakpoint on some not yet loaded module function, e.g.:
(gdb) b btrfs_init_sysfs
Function btrfs_init_sysfs not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (btrfs_init_sysfs) pending.

 o Continue the target

 o Load the module on the target and watch what happens:
loading @0xa0034000: /home/user/linux/build/lib/libcrc32c.ko
loading @0xa005: /home/user/linux/build/lib/lzo/lzo_compress.ko
loading @0xa006e000: 
/home/user/linux/build/lib/zlib_deflate/zlib_deflate.ko
loading @0xa01b1000: /home/user/linux/build/fs/btrfs/btrfs.ko

Breakpoint 1, btrfs_init_sysfs () at /home/user/linux/fs/btrfs/sysfs.c:36
36  btrfs_kset = kset_create_and_add(btrfs, NULL, fs_kobj);

 o Let's examine the current task a bit:
(gdb) p ().pid
 = 4998
(gdb) p ().comm
 = modprobe\000\000\000\000\000\000\000

 o Dump the log buffer of target kernel:
(gdb) lx-dmesg
[ 0.00] Initializing cgroup subsys cpuset
[ 0.00] Initializing cgroup subsys cpu
[ 0.00] Linux version 3.8.0-rc4-dbg+ (...
[ 0.00] Command line: root=/dev/sda2 resume=/dev/sda1 vga=0x314
[ 0.00] e820: BIOS-provided physical RAM map:
[ 0.00] BIOS-e820: [mem 0x-0x0009fbff] 
usable
[ 0.00] BIOS-e820: [mem 0x0009fc00-0x0009] 
reserved


 o Make use of the per-cpu helper for the current or a specified CPU:
(gdb) p (runqueues).nr_running
 = 1
(gdb) p (runqueues, 2).nr_running
 = 0

 o And now we are digging deep into hrtimers using the container_of
   helper:
(gdb) set  = (hrtimer_bases).clock_base[0].active.next
(gdb) p *(, struct hrtimer, node)
 = {
  node = {
node = {
  __rb_parent_color = 18446612133355256072,
  rb_right = 0x0 irq_stack_union,
  rb_left = 0x0 irq_stack_union
},
expires = {
  tv64 = 183526800
}
  },
  _softexpires = {
tv64 = 183526800