Re: Moving Linux-specific stuff out of i386-tdep.c

[Andrew Cagney <ac131313@cygnus.com>]

Mark Kettenis wrote:

> 1. Do we still care about the filename limits of older System V
>    systems?  i386-linux-nat.c is longer than 14 characters which is a
>    no-no according to the GNU conding standards.

Per other e-mail: no but (8.3 :-)

> 2. Should I postpone creating the new -tdep.c file until after the
>    release or not.  Andrew has been telling us to avoid gratuitous
>    changes to make it easier to apply outstanding patches.  But on the
>    other hand, after 5.0 is released, I hope to see a lot new patches
>    generated against 5.0.  So creating the new file before 5.0 would
>    make applying those new patches a lot easier.

I guess its the sigtramp stuff.

If the checkin was a straight cut/paste (without edits) I won't notice
:-)
Down the track, there will need to be ``i386-linux-tdep.h'' so that
i386-linux-nat.c can include it.  (Hmm, with i386-linux-tdep.c, no
wonder Eli raised a concern).

	Andrew
From ac131313@cygnus.com Sat Apr 01 00:00:00 2000
From: Andrew Cagney <ac131313@cygnus.com>
To: Benjamin Kosnik <bkoz@cygnus.com.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: --target=powerpc-elf broken in current sources?
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <38A8A385.24864EC4@cygnus.com>
References: <200002150036.QAA14529@haight.constant.com>
X-SW-Source: 2000-q1/msg00273.html
Content-length: 346

Benjamin Kosnik wrote:
> 
> configuring a cross compiler on x86-linux for powerpc-elf, I get this:
> 

> ../../../src.gdb_binutils_orig/sim/ppc/mon.c:273: `RUSAGE_SELF' undeclared (first use in this function)

> ??

That sounds like a problem specific to a particular version of linux. 
Have you tried a build on an older linux release?

	Andrew
From ezannoni@cygnus.com Sat Apr 01 00:00:00 2000
From: Elena Zannoni <ezannoni@cygnus.com>
To: Kevin Buettner <kevinb@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb@sourceware.cygnus.com
Subject: Re: arguments to add-symbol-file
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <14554.48522.187490.733204@kwikemart.cygnus.com>
References: <14554.41686.732151.870885@kwikemart.cygnus.com> <1000324000053.ZM31438@ocotillo.lan>
X-SW-Source: 2000-q1/msg00785.html
Content-length: 1371

Kevin Buettner writes:
 > On Mar 23,  6:03pm, Elena Zannoni wrote:
 > 
 > > Why when we use 
 > > 
 > > add-symbol-file <file> 0x1000 0x2000 0x3000
 > > 
 > > gdb ends up with the following addrs structure, which includes explicit
 > > entries for .text, .data, and .bss section, plus the same 3 entries
 > > repeated in the 'other' array?
 > > 
 > > Would it make sense to have only the 'other' part, or not include
 > > those three in 'other'?
 > 
 > I think it'd make sense to only have the `other' part.
 > 
 > BTW, did you notice the following comment from symfile.h?
 > 
 >                 /* Add the section to the others even if it is a
 >                    text data or bss section. This is redundent but
 >                    eventually, none will be given special treatment */
 > 

And this one in symfile.c:
      /* FIXME: These sections will not need special treatment because ALL
	 sections are in the other sections table */

All the relevant code is structured like this:

 if ( this is .text )
	do something
 if ( this is .data )
	do something
 if ( this is .bss )
	do something
 for ( all in others )
        do something

Where 'something' is pretty much the same set of instructions. 

 > I think you should ask Fred about it.  (There's probably some reason
 > why it'll be non-trivial to fix.)
 > 

Yes, that's why I was puzzled. 

 > Kevin

Elena
From guo@cup.hp.com Sat Apr 01 00:00:00 2000
From: Jimmy Guo <guo@cup.hp.com>
To: "Daniel Berlin+list.gdb-patches" <dan@cgsoftware.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: C++ Overload testsuite fixes, need someone to verify
Date: Sat, 01 Apr 2000 00:00:00 -0000
Message-id: <Pine.LNX.4.10.10003232042220.12024-100000@hpcll168.cup.hp.com>
References: <hfdx6o2m.fsf@dan.resnet.rochester.edu>
X-SW-Source: 2000-q1/msg00787.html
Content-length: 681

>Can someone verify, that i am correct in thinking you get unexpected
>failures in gdb.c++/ovldbreak.exp due to "breakpoint info" failures?
>I have a patch, i just want to make sure it's not me.
>It appears the source line the test suite expects main to appear on
>in that file is 49, and main really appears at 48, so the regex to
>match doesn't work.  I diffed the ovldbreak.cc file, and i get no
>differences.

I think it should report 49, not 48.  Line 49 is the first executable
statement of main.  I'm using the HP WDB source, in case you cannot see
such behavior with sourceware's (in that case I will spend some time
digging up the fix to submit as a patch).

- Jimmy Guo