This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: gdb under solaris7
- To: Nick Duffek <nsd at redhat dot com>
- Subject: Re: gdb under solaris7
- From: Andrei Petrov <and at genesyslab dot com>
- Date: Tue, 7 Nov 2000 12:14:50 -0800 (PST)
- cc: gdb-patches at sourceware dot cygnus dot com, cagney at redhat dot com
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