File name convention ARCH-OSABI-tdep.c

File name convention ARCH-OSABI-tdep.c

[Yao Qi]

Hi,
I want to extend the *-tdep.c file name convention.  The current
convention is ARCH-OSABI-tdep.c, and I want to extend it to
ARCH-OSABI-tdep-FUNC.c, in which FUNC is about a certain functionality
or feature about this target.

The sparc64 adi patch
(https://sourceware.org/ml/gdb-patches/2017-06/msg00472.html) adds a new
file sparc64-adi-tdep.c which should be merged to sparc64-tdep.c
according to the current naming convention.  However, I think it is good
to put different things in different files.  So with the new convention
proposed here, the new file can be sparc64-tdep-adi.c.

Secondly, some *-tdep.c files are already quite large, arm-tdep.c is of
399434 bytes, 13318 lines.  It is the 5th largest file.  arm-tdep.c
includes many things which are not related to each, like displaced
stepping and process record.  I am thinking that we should allow people
moving them out of *-tdep.c to *-tdep-displaced.c and *-tdep-precord.c.

-- 
Yao (齐尧)

Re: File name convention ARCH-OSABI-tdep.c

[John Baldwin]

On 6/21/17 6:09 AM, Yao Qi wrote:
> 
> Hi,
> I want to extend the *-tdep.c file name convention.  The current
> convention is ARCH-OSABI-tdep.c, and I want to extend it to
> ARCH-OSABI-tdep-FUNC.c, in which FUNC is about a certain functionality
> or feature about this target.
> 
> The sparc64 adi patch
> (https://sourceware.org/ml/gdb-patches/2017-06/msg00472.html) adds a new
> file sparc64-adi-tdep.c which should be merged to sparc64-tdep.c
> according to the current naming convention.  However, I think it is good
> to put different things in different files.  So with the new convention
> proposed here, the new file can be sparc64-tdep-adi.c.
> 
> Secondly, some *-tdep.c files are already quite large, arm-tdep.c is of
> 399434 bytes, 13318 lines.  It is the 5th largest file.  arm-tdep.c
> includes many things which are not related to each, like displaced
> stepping and process record.  I am thinking that we should allow people
> moving them out of *-tdep.c to *-tdep-displaced.c and *-tdep-precord.c.

I like this idea.  In my FreeBSD kgdb patches I have been putting the
kernel-specific bits (custom frame unwinders, etc.) in files named
ARCH-OSABI-kern.c.  I would be happy to place those in ARCH-OSABI-tdep-kern.c
instead.

-- 
John Baldwin

Re: File name convention ARCH-OSABI-tdep.c

[Ivo Raisr]

On 21.6.2017 12:09, Yao Qi wrote:
> 
> Hi,
> I want to extend the *-tdep.c file name convention.  The current
> convention is ARCH-OSABI-tdep.c, and I want to extend it to
> ARCH-OSABI-tdep-FUNC.c, in which FUNC is about a certain functionality
> or feature about this target.
> 
> The sparc64 adi patch
> (https://sourceware.org/ml/gdb-patches/2017-06/msg00472.html) adds a new
> file sparc64-adi-tdep.c which should be merged to sparc64-tdep.c
> according to the current naming convention.  However, I think it is good
> to put different things in different files.  So with the new convention
> proposed here, the new file can be sparc64-tdep-adi.c.
> 
> Secondly, some *-tdep.c files are already quite large, arm-tdep.c is of
> 399434 bytes, 13318 lines.  It is the 5th largest file.  arm-tdep.c
> includes many things which are not related to each, like displaced
> stepping and process record.  I am thinking that we should allow people
> moving them out of *-tdep.c to *-tdep-displaced.c and *-tdep-precord.c.
> 

I support this idea as well.
There were already discussions about how big a file can get to become
largely unmaintainable. See for example
https://softwareengineering.stackexchange.com/questions/176999/at-what-point-range-is-a-code-file-too-big
http://swreflections.blogspot.co.uk/2012/12/rule-of-30-when-is-method-class-or.html

So lifting the current file name convention will allow the files to
become manageable again.

I.

Re: File name convention ARCH-OSABI-tdep.c

[Pedro Alves]

On 06/21/2017 11:09 AM, Yao Qi wrote:
> 
> Hi,
> I want to extend the *-tdep.c file name convention.  The current
> convention is ARCH-OSABI-tdep.c, and I want to extend it to
> ARCH-OSABI-tdep-FUNC.c, in which FUNC is about a certain functionality
> or feature about this target.
> 
> The sparc64 adi patch
> (https://sourceware.org/ml/gdb-patches/2017-06/msg00472.html) adds a new
> file sparc64-adi-tdep.c which should be merged to sparc64-tdep.c
> according to the current naming convention.  However, I think it is good
> to put different things in different files.  So with the new convention
> proposed here, the new file can be sparc64-tdep-adi.c.
> 
> Secondly, some *-tdep.c files are already quite large, arm-tdep.c is of
> 399434 bytes, 13318 lines.  It is the 5th largest file.  arm-tdep.c
> includes many things which are not related to each, like displaced
> stepping and process record.  I am thinking that we should allow people
> moving them out of *-tdep.c to *-tdep-displaced.c and *-tdep-precord.c.
> 

This is fine with me.  I definitely agree with splitting big files in
smaller pieces.

Thanks,
Pedro Alves

Re: File name convention ARCH-OSABI-tdep.c

[Jose E. Marchesi]

    > I want to extend the *-tdep.c file name convention.  The current
    > convention is ARCH-OSABI-tdep.c, and I want to extend it to
    > ARCH-OSABI-tdep-FUNC.c, in which FUNC is about a certain functionality
    > or feature about this target.
    > 
    > The sparc64 adi patch
    > (https://sourceware.org/ml/gdb-patches/2017-06/msg00472.html) adds a new
    > file sparc64-adi-tdep.c which should be merged to sparc64-tdep.c
    > according to the current naming convention.  However, I think it is good
    > to put different things in different files.  So with the new convention
    > proposed here, the new file can be sparc64-tdep-adi.c.
    > 
    > Secondly, some *-tdep.c files are already quite large, arm-tdep.c is of
    > 399434 bytes, 13318 lines.  It is the 5th largest file.  arm-tdep.c
    > includes many things which are not related to each, like displaced
    > stepping and process record.  I am thinking that we should allow people
    > moving them out of *-tdep.c to *-tdep-displaced.c and *-tdep-precord.c.
    > 
    
    This is fine with me.  I definitely agree with splitting big files in
    smaller pieces.

Since no one objected... do we have consensus on this one? :)