This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [PATCH RFC] Make lin-lwp.c functions use target vectors,part 1


Hi Mark,

>As you've noticed, the code in lin-lwp.c does some very low-level
>things.  In fact it is so closely tied to the "child_ops" layer, that
>I don't feel comfortable applying your patch, even though in the long
....

I will talk about this in my next message.

>That said, there are two obstacles when contributing code to GDB.  The
>first is a copyright assignment: copyrights for any significant
>changes need to be assigned to the FSF before we can include them in
>the GDB sources.  This can take a bit of time, so if you're serious in
>contributing to GDB, make sure the paperwork gets done.

Copyright assignment sent in to FSF in May of 1999 for GCC, GDB,
GAS, and BINUTILS.  Copy of assignment papers received back from 
the FSF in June of 1999.  My employer's disclaimer runs until 2002
April.  Likely no problem with an extention of the employer's 
disclaimer, as long as it helps with my current work.

I read someplace that maintainers had access to a name list 
for those who had provided assignment papers.  I assumed that
my name was on such a list.

I send the patches from my home linux computer.  My development 
computer at work does not have Internet access.  At work, I can 
only download files or do WWW viewing from a computer that is 
isolated from my companie's internal network.  This creates a 
delay in my responses and make sending patches time-taking.

However, if I take to much of my working time to get my changes 
into the development gdb sources I may be instructed to stop 
creating patches and only create something from the current gdb 
snapshot.  Under such limited time conditions, good coding and 
proper formating just do not get done.

For a future company project, threaded program debugging on an 
embedded linux system will be needed.  I think having most of 
my changes go into the next version of gdb may be helpful over 
the long run for this project.  Even if all the changes I need 
do not get installed into GDB having most of my changes would 
reduce the size of patching on a future released or snapshot 
gdb versions.  

>The second point is that code has to conform to the GNU/GDB coding
>standards.  Your code currently doesn't, so I'd suggest you look at
>the GNU coding standards and the suggestions on the GDB web pages.

I will send a upated patch.  

If this updated patch has formating errors, can you be more detailed 
about where I am not meeting the coding standards?  Is it in the 
changelog entry? Is it in the diff output of the change to the source 
code?  Reformating the changed lin-lwp.c file with indent before making 
the patch, caused a much larger patch and mixed many other changes 
into diff's output.  The current snapshot version of lin-lwp.c does 
not seem to be fully following GNU formating.  I was told NOT to mix 
code clean-ups and code changes together.  However, my patches for 
only code clean-up seem to be just ignored even after many weeks.  
For example, see the patch I made when reviewing the gdbserver code at:

http://sources.redhat.com/ml/gdb-patches/2001-04/msg00256.html


John S. Kallal


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]