Re: symbolic debug of loadable modules with kgdb light

[Joel Brobecker <brobecker@adacore.com>]

> About 25 lines come from
> http://kgdb.cvs.sourceforge.net/viewvc/kgdb/gdb/. These are an
> essential part. I could not delete it. From your comments, I have 3
> options in the order of most aggressive to conservative, 1) re-write
> the code which come from kgdb, 2) ask the author of the code for his
> permission and 3) don't submit the patch to gdb. I am wondering what
> is right choice.

It's hard to tell without knowing what the code is doing.  If you can
easily track down the author (all the authors, actually), then you
can ask them to contribute this code. I think the safest for everyone
would be if they have a copyright assignment on file with the FSF.
On the other hand, if it's easy for you to rewrite the code in
a different way, doing so allows you do remove a dependency on
external factors.

The other alternative is if we can determine that the change is not
a "legally significant change", as our guidelines call it:

  http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant

> Regarding testsuite,
> - gdb-6.8
> # of expected passes            11844
> # of unexpected failures        82
> # of unexpected successes       2
> # of expected failures          43
> # of known failures             39
> # of untested testcases         10
> # of unsupported tests          47
> - Modified gdb-6.8, 
> # of expected passes            11841
> # of unexpected failures        83
> # of unexpected successes       2
> # of expected failures          43
> # of known failures             39
> # of untested testcases         10
> # of unsupported tests          47
> So I believe the modification does not break anything. 

Looking at pure numbers can be misleading sometimes (which is why
I diff the .sum files before and after applying my patch), but
the numbers you published show that you have 3 less PASSes and
one more FAIL. Sometimes, this does not indicate any regression,
but often it does... Did you check were the difference come from?

> All modifications are clear to me. I can write explanation for each
> modifications and files. Also making a patch against cvd HEAD is not a
> issue.

Great! My recommendation is to first bring your patches up to date
with CVS HEAD and, once done, to break them down into individual pieces.
Then send each piece for review to the gdb-patches mailing list,
explaining what the problem is and how you're solving it. The more
information you provide, the easier it is for us to review the patches.

-- 
Joel