Re: remote XOpenDisplay in Solaris (SunOS 5.6)

["Jerry Miller" <gmiller at cs dot sunysb dot edu>]

That did it!  Thank you!

I hadn't experimented enough with gdb to realize that the
"up" command was virtually equivalent to the PL/I tracebacks
I used to rely on.  When I discovered that my function
putmsg was being called by a shared-library routine, I did a
"man putmsg," and sure enough, there was a conflict there!

Making it a static local function and renaming it for good
measure has solved this mysterious problem.

----- Original Message -----
From: David Korn <dkorn@pixelpower.com>
To: 'Jerry Miller' <gmiller@cs.sunysb.edu>; <help-gcc@gnu.org>
Sent: Wednesday, February 28, 2001 5:29 AM
Subject: RE: remote XOpenDisplay in Solaris (SunOS 5.6)


> >-----Original Message-----
> >From: Jerry Miller [mailto:gmiller@cs.sunysb.edu]
> >Sent: 27 February 2001 19:17
>
> >Here's a dump of the first few values in big-endian
> >shortword format (patterned after od -x).  Does
> >anyone know enough assembler for the UltraSparc 5
> >(68XXX???) to be able to tell me where the address
> >starts (and whether it is an actual address or a further
> >indirection)?
> >
> >0300 099c 30bf fd98 0100 0000 0100 0000
> >001f cb28 0000 0040 0000 0000 001f 802c
> >
> >A simple test program, which does nothing but call
> >the dump function, instead yields:
> >
> >0300 0084 30bf ffde 0100 0000 0100 0000
> >0002 0a88 0000 0000 0000 0000 0002 09b4
>
>   Is this the actual linked code from memory, or are you dumping the
> object file here?  All those zeroes don't look right to me, so if this
> is what's in memory, it looks like it hasn't been linked correctly.
>
> >(Where's a disassembler when I need one?!?!)
>
>   Right, let me think about this.  We know that the first few instructions
> are the function prologue, so I'd reckon that those negative numbers
> $fd98 and $ffde are the stack frame adjustments, so that would mean that
> $30bf $xxxx is link #xxxx,a6.  $0a88 is one I vaguely recognize as well,
> I think that's a load to a register....  All those zeroes just can't be
> right though.
>
>   I think your best bet is to run your program under gdb.  That will trap
> on the segv and you can have a look at the stack frame and see which
> functions have been called by which other functions in which order.
>
>        DaveK
> --
>  All your base are belong to us!
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
>