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/Kcon
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 e0
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
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
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..09e8
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
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..09e8
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
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
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 +
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
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 +,
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 probabl
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
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 w
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")
> >
>
* 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
>
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 CONFI
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
g
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
g
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-g
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.ki
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:
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]
>>
>> [sni
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 Sa
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
> >> o
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,
> 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:1
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
> 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
> ou
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 s
> 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,
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
> 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. :)
>
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
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 peo
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 s
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 develop
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 definit
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
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'
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 commi
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
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 origina
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.o
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
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 an
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 modul
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 ta
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
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 ker
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 Technolo
>
> 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
ile 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 s
>
> 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 ma
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
Jan Kiszka siemens.com> writes:
>
> Version 2 of this series is a rebase over 3.7-rc4 to resolve some minor
> collision in the top-level makefile. Moreover, this implements automatic
> symbol loading for kernel modules using silent breakpoints. See patch 3
> for details.
>
> Unless someone comp
patches through your hands.
Could you take them?
Here is the original intro for reference:
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
workflow,
I'm planning to send a pull to Linus during the next merge window.
Here is the original intro for reference:
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 aut
I'm sitting too long on this stuff, time to finally role it out:
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 symbo
Finally, I was able to spend some time to clean up logdev for the latest
kernels (2.6.23.1, 2.6.24-rc1"x86 merged" and 2.6.23.1-rt5 "Real-Time").
http://rostedt.homelinux.com/logdev/
What is logdev?
It is an internal ring buffered log trace system, to help debug those
really hard to debug area
Hi All,
I'm following instructions at
http://kgdb.linsyssoft.com/quickstart.htm to get into kernel
debugging. Since it doesn't ask me to do a 'make modules;make
modules_install' on the test machine, I think I can't build a good
initrd image on the test machine (since m
On Mon, 2005-07-25 at 15:23 -0400, [EMAIL PROTECTED] wrote:
> I am using Red Hat sources, which has function open_kcore() hardcoded to
> return -EPERM always.
>
> Changing this function to the way it is defined in the public sources (as
> shown below) did the trick.
All these Red Hat / RHEL threa
I am using Red Hat sources, which has function open_kcore() hardcoded to
return -EPERM always.
Changing this function to the way it is defined in the public sources (as
shown below) did the trick.
open_kcore(struct inode * inode, struct file * filp)
{
return capable(CAP_SYS_RAWIO) ? 0 : -EPER
ou want to use gdb to debug the kernel you should probably
> investigate UML (User Mode Linux). Take a look at this link :
> http://user-mode-linux.sourceforge.net/debugging.html
>
> Alternatives include kgdb - http://kgdb.sourceforge.net/
> and kdb - http://oss.sgi.com/projects/kdb/
&g
e.net/debugging.html
Alternatives include kgdb - http://kgdb.sourceforge.net/
and kdb - http://oss.sgi.com/projects/kdb/
You can also find many documents on Linux Kernel debugging aids and
techniques via google.
--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post http://www.catb.org/~esr/ja
Andrea Arcangeli wrote:
>
> Back in May I wrote a quite estensive documentation about all the
> possible/best ways to debug the Linux Kernel for a talk/tranining that I
> did in San Jose in May. I find now the time to clean it up and to upload
> since I think it could result useful to everybody d
Andrea,
You're a stud. This is great.
:-)
Jeff
Andrea Arcangeli wrote:
>
> Back in May I wrote a quite estensive documentation about all the
> possible/best ways to debug the Linux Kernel for a talk/tranining that I
> did in San Jose in May. I find now the time to clean it up and to upload
Back in May I wrote a quite estensive documentation about all the
possible/best ways to debug the Linux Kernel for a talk/tranining that I
did in San Jose in May. I find now the time to clean it up and to upload
since I think it could result useful to everybody dealing with kernel
developement.
I've debugged quiet a few operating systems on a very wide range of hardware
over 25 years using a very wide range of tools and techniques, sometimes
even having to use logic analysers. I've also watched this discussion for a
while. IMHO, y'all have conflated two quiet different processes (possib
Elmer Joandi wrote:
>
> > understanding the
> > > underlying principles and the code.
>
> Speaking about that, I have been long time dreaming
> about following strict standard template for linux kernel functions:
> (macroplay intended)
> --
> INLINE(context,level,for_speed,
> understanding the
> > underlying principles and the code.
Speaking about that, I have been long time dreaming
about following strict standard template for linux kernel functions:
(macroplay intended)
--
INLINE(context,level,for_speed, fixed) returntype functionname
(PARM(p
"Amit S. Kale" wrote:
>
> George Anzinger wrote:
> > I took a look at this and it looks very messy. The whole notion is that
> > the stack is available to put the call on and then proceed. The
> > question then is what does the stack look like after the call to the
> > inferior function which,
73 matches
Mail list logo
