kallsyms 2.6.8 address ordering

kallsyms 2.6.8 address ordering

[jmerkey]

I've noticed that LKML of late is unresponsive to a lot bug posts and that email is being blocked for a lot of folks.  It smells like partisan politics based on economic motivations and its not really "open" any more when people stoop to this level of behavior.  That aside:

kallsyms in 2.6.8 is presenting module symbol tables with out of order addresses in 2.6.X.  This makes maintaining a commercial kernel debugger for Linux 2.6 kernels nighmareish.  Also, the need to kmalloc name strings (like kdb does) from kallsyms in kdbsupport.c while IN THE DEBUGGER makes it impossible to debug large portions of the kernel code with kdb, so I have rewritten large sections of kallsyms.c to handle all these broken, brain-dead cases in mdb and I am not relying much on kdb hooks anymore.  Why on earth does Linux need to have shifting tables of test strings for module names requiring all this complexity in the symbol tables and kallsyms.

I don't expect a response so I'll keep coding around the broken Linux 2.6 code but I wanted to post a record of this so perhaps someone will think about over-engineering systems which should be left alone.

Jeff
  

Re: kallsyms 2.6.8 address ordering

[Christoph Hellwig]

On Thu, Aug 19, 2004 at 06:10:25PM +0000, jmerkey@comcast.net wrote:
> kallsyms in 2.6.8 is presenting module symbol tables with out of order
> addresses in 2.6.X.  This makes maintaining a commercial kernel debugger
> for Linux 2.6 kernels nighmareish.

Can you prove this debugger doesn't violate SGI's copyrights on KDB?

Re: kallsyms 2.6.8 address ordering

[Rik van Riel]

On Thu, 19 Aug 2004 jmerkey@comcast.net wrote:

> kallsyms in 2.6.8 is presenting module symbol tables with out of order
> addresses in 2.6.X.  This makes maintaining a commercial kernel debugger
> for Linux 2.6 kernels nighmareish. 

How hard could it be to sort the table in your debugger ?

> Also, the need to kmalloc name strings (like kdb does) from kallsyms in
> kdbsupport.c while IN THE DEBUGGER makes it impossible to debug large
> portions of the kernel code with kdb, so I have rewritten large sections
> of kallsyms.c to handle all these broken, brain-dead cases in mdb and I
> am not relying much on kdb hooks anymore.
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Sounds like your commercial debugger might just be violating
the GPL ;)

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: kallsyms 2.6.8 address ordering

[Richard B. Johnson]

On Thu, 19 Aug 2004 jmerkey@comcast.net wrote:

> I've noticed that LKML of late is unresponsive to a lot bug posts
> and that email is being blocked for a lot of folks.  It smells like
> partisan politics based on economic motivations and its not really
>"open" any more when people stoop to this level of behavior.  That aside:
>

Huh? Nobody is getting blocked. Sometimes certain repetitious
"you are screwed up..." messages get deleted by the list owner,
but usually the first one-hundred or so get through.

Many bug posts don't get handled because it's expected that
you should be able to fix the bug and send a patch. That's what
the Linux-kernel list was started for. The rest of the
complaints, bitches, and noise are just the icing on the cake.
Wake up and smell the flowers --and send your patches!

Also, a lot of bug fixes get handled off-line. Only yesterday
I reported a problem with a motherboard. I have over 20 off-line
(mostly helpful) responses. Even the designer is going to try to
find the problem.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
            Note 96.31% of all statistics are fiction.

Re: kallsyms 2.6.8 address ordering

[Robin Holt]

On Thu, Aug 19, 2004 at 06:10:25PM +0000, jmerkey@comcast.net wrote:
> I've noticed that LKML of late is unresponsive to a lot bug posts and
> that email is being blocked for a lot of folks.  It smells like partisan
> politics based on economic motivations and its not really "open" any
> more when people stoop to this level of behavior.  That aside:

I attribute this to people being over busy right now.

> kallsyms in 2.6.8 is presenting module symbol tables with out of order
> addresses in 2.6.X.  This makes maintaining a commercial kernel debugger
> for Linux 2.6 kernels nighmareish.  Also, the need to kmalloc name strings
> (like kdb does) from kallsyms in kdbsupport.c while IN THE DEBUGGER makes
> it impossible to debug large portions of the kernel code with kdb, so I
> have rewritten large sections of kallsyms.c to handle all these broken,
> brain-dead cases in mdb and I am not relying much on kdb hooks anymore.
> Why on earth does Linux need to have shifting tables of test strings
> for module names requiring all this complexity in the symbol tables
> and kallsyms.

It must be useful for people using small memory footprint machines.
Check with the folks doing embedded stuff.

I remember a discussion about kallsyms and scaling problems with
top reading some /proc/<pid> file.

Look at this:
http://marc.theaimsgroup.com/?l=linux-kernel&m=108758995727517&w=2

> I don't expect a response so I'll keep coding around the broken Linux
> 2.6 code but I wanted to post a record of this so perhaps someone will
> think about over-engineering systems which should be left alone.
> 
> Jeff

Good Luck,
Robin Holt

Re: kallsyms 2.6.8 address ordering

[Horst von Brand]

jmerkey@comcast.net said:

> I've noticed that LKML of late is unresponsive to a lot bug posts

This is a community of _volunteers_, if you want your particular itch
scratched ASAP, shop for a maintenance contract.

>                                                                   and
> that email is being blocked for a lot of folks.

I've been on this list for quite some time, and this is the very first time
I hear anything about such a thing. Care to elaborate?

[Yes, there are people who are almost universally on killfiles of the lead
 hackers, but that is their own fault... and the list managers don't need
 to bann anybody that way ;-]

>                                                  It smells like partisan
> politics based on economic motivations and its not really "open" any more
> when people stoop to this level of behavior.

Proof, please.

>                                               That aside:

> kallsyms in 2.6.8 is presenting module symbol tables with out of order
> addresses in 2.6.X.  This makes maintaining a commercial kernel debugger
> for Linux 2.6 kernels nighmareish.

If you want that fixed so you can make money off Linux, you'd better well
pay for the privilege of having your particular desires taken care of.
Probably off this list, as kernel debuggers in general are persona non
grata here, commercial software meddling with the inards of the kernel even
less wellcome.

[...]

> I don't expect a response so I'll keep coding around the broken Linux 2.6
> code but I wanted to post a record of this so perhaps someone will think
> about over-engineering systems which should be left alone.

This is probably just working to get the most out of the kernel, and the
constraint of "making kernel debuggers easy to write" just isn't in the
requirements. The kernel hackers (rightly so, IMVHO) reserve the right to
change interfases at the drop of a hat. If third parties get burned, just
too bad.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: kallsyms 2.6.8 address ordering

[Paulo Marques]

Robin Holt wrote:
>....
> 
> It must be useful for people using small memory footprint machines.
> Check with the folks doing embedded stuff.
> 
> I remember a discussion about kallsyms and scaling problems with
> top reading some /proc/<pid> file.
> 
> Look at this:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=108758995727517&w=2
> 

I posted recently (exactly one week ago) a different approach to this 
problem that increased kallsyms_lookup performance about 100 times, 
without a cache and without locking.

The patch is currently in Ingo Molnar's tree (I think). It works by 
doing binary search on tha address table and then using pre-calculated 
markers on the stem stream to search closer to the target. After that it 
copies only the stems before the searched symbol that actually 
contribute to the final result.

You can check the thread here:

http://marc.theaimsgroup.com/?l=linux-kernel&m=109245918613781&w=2

(Please note that the original patch broke handling of aliased symbols 
which was corrected later in the thread)

I'm working on an even better approach right now and I should have a 
patch ready this weekend.

This however has nothing to do with _module_ symbol names, which is a 
different problem altogether.

-- 
Paulo Marques - www.grupopie.com

Re: kallsyms 2.6.8 address ordering

[Horst von Brand]

jmerkey@comcast.net said:
> Horst von Brand <vonbrand@inf.utfsm.cl> said:
> > This is probably just working to get the most out of the kernel, and the
> > constraint of "making kernel debuggers easy to write" just isn't in the
> > requirements. The kernel hackers (rightly so, IMVHO) reserve the right to
> > change interfases at the drop of a hat. If third parties get burned, just
> > too bad.

> Makes a lot of unnecessary work for others to keep up.

Tough luck.

>                                                         Some of the
> interfaces being changed are broken as a result.

If it isn't an official interface, there is nothing to complain about...

>                                                   It's not progress to
> break something that shouldn't need changing.

Who are you to say they don't need changing?

>                                                Just IMHO....

Just mine.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: kallsyms 2.6.8 address ordering

[Francois Romieu]

jmerkey@comcast.net <jmerkey@comcast.net> :
> This seems to be the case.  It's just happening silently.  lkml needs to
> return a message to help folks detemrine the problem if possible.

Have you considered the use of the mxverify tool which is available
online at http://vger.kernel.org ?

drdos.com does not have a backup mx and postmaster can not be reached.

No wonder it is not reliable.

--
Ueimor

Re: kallsyms 2.6.8 address ordering

[jmerkey]

>
> This is probably just working to get the most out of the kernel, and the
> constraint of "making kernel debuggers easy to write" just isn't in the
> requirements. The kernel hackers (rightly so, IMVHO) reserve the right to
> change interfases at the drop of a hat. If third parties get burned, just
> too bad.

Makes a lot of unnecessary work for others to keep up.  Some of the interfaces being 
changed are broken as a result.  It's not progress to break something that shouldn't 
need changing.  Just IMHO....

Jeff

> -- 
> Dr. Horst H. von Brand                   User #22616 counter.li.org
> Departamento de Informatica                     Fono: +56 32 654431
> Universidad Tecnica Federico Santa Maria              +56 32 654239
> Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: kallsyms 2.6.8 address ordering

[jmerkey]

This seems to be the case.  It's just happening silently.  lkml needs to return a message to 
help folks detemrine the problem if possible.

Jeff


> "David S. Miller" <davem@redhat.com> writes:
> 
> Hello David,
> 
> >> jmerkey@drdos.com is blocked from posting to this list.  I have
> >> verified it though smtp, so I use my comcast.net account instead.
> >> David Miller **WONT** respond to emails or the other list
> >> maintainers.
> 
> > Well, you're not in the by-hand SPAM filter, so it must be something else.
> 
> > ? egrep drdos /opt/mail/db/smtp-policy.spam.manual
> > ? egrep jmerkey /opt/mail/db/smtp-policy.spam.manual
> 
> > What message do you get back from direct smtp tests?
> 
> My messages also won't get through if I send them directly using
> postfix from my workstation (with dynamic IP). I switched to using a
> smarthost and now everything seems ok.
> 
> I thought it might be spam prevention. However, the SMTP server lkml
> is attached to accepted the messages perfectly and just dropped it
> silentily. It really should give an error when it's preventing spam,
> otherwise you might not even notice that your message got dropped.
> 
> At least one message really didn't get anywhere while the SMTP server
> said that everything is fine. Or maybe it's a bug somewhere that drops
> messages unintendedly? Drop me a line if you need the log entry.
> 
> However, I never suspected that I was dropped on purpose, and I still
> don't think so right now.
> 
> Regards,
> Julien

Re: kallsyms 2.6.8 address ordering

[Julien Oster]

"David S. Miller" <davem@redhat.com> writes:

Hello David,

>> jmerkey@drdos.com is blocked from posting to this list.  I have
>> verified it though smtp, so I use my comcast.net account instead.
>> David Miller **WONT** respond to emails or the other list
>> maintainers.

> Well, you're not in the by-hand SPAM filter, so it must be something else.

> ? egrep drdos /opt/mail/db/smtp-policy.spam.manual
> ? egrep jmerkey /opt/mail/db/smtp-policy.spam.manual

> What message do you get back from direct smtp tests?

My messages also won't get through if I send them directly using
postfix from my workstation (with dynamic IP). I switched to using a
smarthost and now everything seems ok.

I thought it might be spam prevention. However, the SMTP server lkml
is attached to accepted the messages perfectly and just dropped it
silentily. It really should give an error when it's preventing spam,
otherwise you might not even notice that your message got dropped.

At least one message really didn't get anywhere while the SMTP server
said that everything is fine. Or maybe it's a bug somewhere that drops
messages unintendedly? Drop me a line if you need the log entry.

However, I never suspected that I was dropped on purpose, and I still
don't think so right now.

Regards,
Julien

Re: kallsyms 2.6.8 address ordering

[David S. Miller]

On Thu, 19 Aug 2004 19:27:23 +0000
jmerkey@comcast.net wrote:

> jmerkey@drdos.com is blocked from posting to this list.  I have verified it though smtp, so I use 
> my comcast.net account instead.  David Miller **WONT** respond to emails or the other list 
> maintainers.  

Well, you're not in the by-hand SPAM filter, so it must be something else.

? egrep drdos /opt/mail/db/smtp-policy.spam.manual
? egrep jmerkey /opt/mail/db/smtp-policy.spam.manual

What message do you get back from direct smtp tests?

Re: kallsyms 2.6.8 address ordering

[jmerkey]

jmerkey@drdos.com is blocked from posting to this list.  I have verified it though smtp, so I use 
my comcast.net account instead.  David Miller **WONT** respond to emails or the other list 
maintainers.  

Jeff


> On Thu, 19 Aug 2004 jmerkey@comcast.net wrote:
> 
> > I've noticed that LKML of late is unresponsive to a lot bug posts
> > and that email is being blocked for a lot of folks.  It smells like
> > partisan politics based on economic motivations and its not really
> >"open" any more when people stoop to this level of behavior.  That aside:
> >
> 
> Huh? Nobody is getting blocked. Sometimes certain repetitious
> "you are screwed up..." messages get deleted by the list owner,
> but usually the first one-hundred or so get through.
> 
> Many bug posts don't get handled because it's expected that
> you should be able to fix the bug and send a patch. That's what
> the Linux-kernel list was started for. The rest of the
> complaints, bitches, and noise are just the icing on the cake.
> Wake up and smell the flowers --and send your patches!
> 
> Also, a lot of bug fixes get handled off-line. Only yesterday
> I reported a problem with a motherboard. I have over 20 off-line
> (mostly helpful) responses. Even the designer is going to try to
> find the problem.
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
>             Note 96.31% of all statistics are fiction.
> 
> 

Re: kallsyms 2.6.8 address ordering

[jmerkey]

Robin,

I am looking over the link.  I can get around this (and already have) with 2.6.7 and 2.6.8 by instrumenting a search routine that deals with the out of order conditions.  I appreciate the 
helpful and informative response.

Jeff


> On Thu, Aug 19, 2004 at 06:10:25PM +0000, jmerkey@comcast.net wrote:
> > I've noticed that LKML of late is unresponsive to a lot bug posts and
> > that email is being blocked for a lot of folks.  It smells like partisan
> > politics based on economic motivations and its not really "open" any
> > more when people stoop to this level of behavior.  That aside:
> 
> I attribute this to people being over busy right now.
> 
> > kallsyms in 2.6.8 is presenting module symbol tables with out of order
> > addresses in 2.6.X.  This makes maintaining a commercial kernel debugger
> > for Linux 2.6 kernels nighmareish.  Also, the need to kmalloc name strings
> > (like kdb does) from kallsyms in kdbsupport.c while IN THE DEBUGGER makes
> > it impossible to debug large portions of the kernel code with kdb, so I
> > have rewritten large sections of kallsyms.c to handle all these broken,
> > brain-dead cases in mdb and I am not relying much on kdb hooks anymore.
> > Why on earth does Linux need to have shifting tables of test strings
> > for module names requiring all this complexity in the symbol tables
> > and kallsyms.
> 
> It must be useful for people using small memory footprint machines.
> Check with the folks doing embedded stuff.
> 
> I remember a discussion about kallsyms and scaling problems with
> top reading some /proc/<pid> file.
> 
> Look at this:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=108758995727517&w=2
> 
> > I don't expect a response so I'll keep coding around the broken Linux
> > 2.6 code but I wanted to post a record of this so perhaps someone will
> > think about over-engineering systems which should be left alone.
> > 
> > Jeff
> 
> Good Luck,
> Robin Holt

Re: kallsyms 2.6.8 address ordering

[jmerkey]

> On Thu, Aug 19, 2004 at 06:26:31PM +0000, jmerkey@comcast.net wrote:
> > Yes.
> > 
> > What would be required?   Source code disclosure to a reviewer.  MDB is 
> platform independent.  and patches in an alternate debugger interface in 
> kdb_main.  In includes **NONE** of SGI's source code or Linux kernel source in 
> the MDB core.  There is an open source section of the debugger with **ALL** 
> modifications to kdb core files disclosed with the debugger modules.  The fact 
> is, I don't even need kdb, but inlcuded it in a mode where folks who wanted to 
> switch between the two debuggers could do so, since a lot of folks wanted to.  I 
> do use the serial interface in kdb, which is the only portion.  I wrote MANOS 
> with this debugger, and all the low level GDT, IDT, etc. hardware stuff is my 
> own, is vastly superior to what's in kdb.   
> > 
> > DRDOS owns the MDB debugger for Linux now and I maintain it for them -- that's 
> it.  I am certain DRDOS would provide any counter-claims with **FACTS** to 
> assertions we are using any of the kdb code improperly.
> 
> So it works with unpatched kernels?

Hmmm.  Linux has no trap interface to register hooks into the IDT table.  No screen output 
manager to allow screen drivers to be debugged (which is why kdb has to call all the 
console drivers in a chain and output text on all of them at the same time). No interface 
to restore keyboard hardware state after being taken over in a polling loop by a debugger 
keyboard handler.    

Sounds like it's not possible to support a commercial debugger without patching the kernel.  
If the patches to the kernel are open sourced (which they are) and use a call layer to a binary 
module, it does not appear this violates the GPL.  Will Linux ever support a true alternate 
debugger interface?  Let's see what Linus had to say about this.

On Wed, 6 Sep 2000, Tigran Aivazian wrote:
>
> very nice monologue, thanks. It would be great to know Linus' opinion. I
> mean, I knew Linus' opinion of some years' ago but perhaps it changed? He
> is a living being and not some set of rules written in stone so perhaps
> current stability/highquality of kdb suggests to Linus that it may be
> (just maybe) acceptable into official tree?

I don't like debuggers. Never have, probably never will. I use gdb all the
time, but I tend to use it not as a debugger, but as a disassembler on
steroids that you can program.

None of the arguments for a kernel debugger has touched me in the least.
And trust me, over the years I've heard quite a lot of them. In the end,
they tend to boil down to basically:

 - it would be so much easier to do development, and we'd be able to add
   new things faster.

And quite frankly, I don't care. I don't think kernel development should
be "easy". I do not condone single-stepping through code to find the bug.
I do not think that extra visibility into the system is necessarily a good
thing.

Apparently, if you follow the arguments, not having a kernel debugger
leads to various maladies:
 - you crash when something goes wrong, and you fsck and it takes forever
   and you get frustrated.
 - people have given up on Linux kernel programming because it's too hard
   and too time-consuming
 - it takes longer to create new features.

And nobody has explained to me why these are _bad_ things.

To me, it's not a bug, it's a feature. Not only is it documented, but it's
_good_, so it obviously cannot be a bug.

"Takes longer to create new features" - this one in particular is not a
very strong argument for having a debugger. It's not as if lack of
features or new code would be a problem for Linux, or, in fact, for the
software industry as a whole. Quite the reverse. My biggest job is to say
"no" to new features, not trying to find them.

Oh. And sure, when things crash and you fsck and you didn't even get a
clue about what went wrong, you get frustrated. Tough. There are two kinds
of reactions to that: you start being careful, or you start whining about
a kernel debugger.

Quite frankly, I'd rather weed out the people who don't start being
careful early rather than late. That sounds callous, and by God, it _is_
callous. But it's not the kind of "if you can't stand the heat, get out
the the kitchen" kind of remark that some people take it for. No, it's
something much more deeper: I'd rather not work with people who aren't
careful. It's darwinism in software development.

It's a cold, callous argument that says that there are two kinds of
people, and I'd rather not work with the second kind. Live with it.

I'm a bastard. I have absolutely no clue why people can ever think
otherwise. Yet they do. People think I'm a nice guy, and the fact is that
I'm a scheming, conniving bastard who doesn't care for any hurt feelings
or lost hours of work if it just results in what I consider to be a better
system.

And I'm not just saying that. I'm really not a very nice person. I can say
"I don't care" with a straight face, and really mean it.

I happen to believe that not having a kernel debugger forces people to
think about their problem on a different level than with a debugger. I
think that without a debugger, you don't get into that mindset where you
know how it behaves, and then you fix it from there. Without a debugger,
you tend to think about problems another way. You want to understand
things on a different _level_.

It's partly "source vs binary", but it's more than that. It's not that you
have to look at the sources (of course you have to - and any good debugger
will make that _easy_). It's that you have to look at the level _above_
sources. At the meaning of things. Without a debugger, you basically have
to go the next step: understand what the program does. Not just that
particular line.

And quite frankly, for most of the real problems (as opposed to the stupid
bugs - of which there are many, as the latest crap with "truncate()" has
shown us) a debugger doesn't much help. And the real problems are what I
worry about. The rest is just details. It will get fixed eventually.

I do realize that others disagree. And I'm not your Mom. You can use a
kernel debugger if you want to, and I won't give you the cold shoulder
because you have "sullied" yourself. But I'm not going to help you use
one, and I wuld frankly prefer people not to use kernel debuggers that
much. So I don't make it part of the standard distribution, and if the
existing debuggers aren't very well known I won't shed a tear over it.

Because I'm a bastard, and proud of it!

                        Linus

Based upon the comments above, they leave little doubt there will **EVER** be an interface 
into Linux to support a commercial debugger.   Perhaps Linus would change his mind and 
include an open debugger interface.  It would require very little for KDebug and kdb to work. 

Jeff


- 


> 

Re: kallsyms 2.6.8 address ordering

[jmerkey]

> On Thu, 19 Aug 2004 jmerkey@comcast.net wrote:
> 
> > kallsyms in 2.6.8 is presenting module symbol tables with out of order
> > addresses in 2.6.X.  This makes maintaining a commercial kernel debugger
> > for Linux 2.6 kernels nighmareish. 
> 
> How hard could it be to sort the table in your debugger ?
> 

How about not sorting it at all and not being required to increase memory consumption for 
debugging purposes?  



> > Also, the need to kmalloc name strings (like kdb does) from kallsyms in
> > kdbsupport.c while IN THE DEBUGGER makes it impossible to debug large
> > portions of the kernel code with kdb, so I have rewritten large sections
> > of kallsyms.c to handle all these broken, brain-dead cases in mdb and I
> > am not relying much on kdb hooks anymore.
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Sounds like your commercial debugger might just be violating
> the GPL ;)

No.  it's not.  Chris makes a suggestion I should make it work on unpatched kernels.  
I will address on his thread.

Jeff

> 
> -- 
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." - Brian W. Kernighan
> 

Re: kallsyms 2.6.8 address ordering

[Christoph Hellwig]

On Thu, Aug 19, 2004 at 06:26:31PM +0000, jmerkey@comcast.net wrote:
> Yes.
> 
> What would be required?   Source code disclosure to a reviewer.  MDB is platform independent.  and patches in an alternate debugger interface in kdb_main.  In includes **NONE** of SGI's source code or Linux kernel source in the MDB core.  There is an open source section of the debugger with **ALL** modifications to kdb core files disclosed with the debugger modules.  The fact is, I don't even need kdb, but inlcuded it in a mode where folks who wanted to switch between the two debuggers could do so, since a lot of folks wanted to.  I do use the serial interface in kdb, which is the only portion.  I wrote MANOS with this debugger, and all the low level GDT, IDT, etc. hardware stuff is my own, is vastly superior to what's in kdb.   
> 
> DRDOS owns the MDB debugger for Linux now and I maintain it for them -- that's it.  I am certain DRDOS would provide any counter-claims with **FACTS** to assertions we are using any of the kdb code improperly.

So it works with unpatched kernels?

Re: kallsyms 2.6.8 address ordering

[jmerkey]

Yes.

What would be required?   Source code disclosure to a reviewer.  MDB is platform independent.  and patches in an alternate debugger interface in kdb_main.  In includes **NONE** of SGI's source code or Linux kernel source in the MDB core.  There is an open source section of the debugger with **ALL** modifications to kdb core files disclosed with the debugger modules.  The fact is, I don't even need kdb, but inlcuded it in a mode where folks who wanted to switch between the two debuggers could do so, since a lot of folks wanted to.  I do use the serial interface in kdb, which is the only portion.  I wrote MANOS with this debugger, and all the low level GDT, IDT, etc. hardware stuff is my own, is vastly superior to what's in kdb.   

DRDOS owns the MDB debugger for Linux now and I maintain it for them -- that's it.  I am certain DRDOS would provide any counter-claims with **FACTS** to assertions we are using any of the kdb code improperly.

Jeff


> On Thu, Aug 19, 2004 at 06:10:25PM +0000, jmerkey@comcast.net wrote:
> > kallsyms in 2.6.8 is presenting module symbol tables with out of order
> > addresses in 2.6.X.  This makes maintaining a commercial kernel debugger
> > for Linux 2.6 kernels nighmareish.
> 
> Can you prove this debugger doesn't violate SGI's copyrights on KDB?