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: gdb under solaris7



uh, I didn't think it might get into.
Glad because it might help somebody.

On Tue, 7 Nov 2000, Nick Duffek wrote:

> On 30-Aug-2000, Andrei Petrov wrote:
> 
> >The patch below lets to build gdb with SUNWspro cc compiler.
> 
> Thanks.  Speaking as a Solaris/x86 maintainer, I approve of the
> sol-thread.c part for Solaris/x86.  I have some comments on the rest,
> which you can feel free to ignore since I can't approve or disapprove
> it. :-)
> 
> In various files:
> >!   char raw_buffer[MAX_REGISTER_RAW_SIZE];
> [...]
> >!   char *raw_buffer = alloca(MAX_REGISTER_RAW_SIZE);
> 
> All of those changes look right to me.
> 
> remote.c:
> >!   scan = (char *) ref;
> [...]
> >!   scan = (unsigned char *) ref;
> 
> Looks right.
> 
> remote.c:
> >!       pkt = unpack_int (pkt, &tag);	/* tag */
> [...]
> >!       pkt = unpack_int (pkt, (int *)&tag);	/* tag */
> 
> How about declaring tag as an int instead?  Better not to use typecasts
> when easily avoidable, I think.  Andrew?
> 
> remote.c:
> >!       p = (unsigned char *) bfd_get_section_name (abfd, sect);
> [...]
> >!       p = (char *) bfd_get_section_name (abfd, sect);
> 
> Yup.
> 
> sparc-tdep.c:
> >! sparc_software_single_step (enum target_signal ignore,	/* pid, but we don't need it */
> [...]
> >! sparc_software_single_step (/*enum target_signal*/ uint ignore,	/* pid, but we don't need it */
> 
> What's the reason for this change?

I couldn't get it compiled without this change as far as I remember,
I don't think I tried to get proper thing for this one.
It hard to get motivited when you see argument named ignore:-).

> 
> sparc-tdep.c:
> >!   static LONGEST call_dummy_64[] = 
> [...]
> >!   static unsigned LONGEST call_dummy_64[] = 
> 
> Is the compiler complaining about the values being too big for signed long
> long?  I suggest ULONGEST instead of unsigned LONGEST along with a comment
> explaining the reason for the change.
Yes, I just didn't understand the reason for compiler's complain.
I didn't find ULONGEST so the change.

> 
> Nick Duffek
> nsd@redhat.com
> 
Regards,
	Andrey


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