public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/9144] gdb assumes 4 byte separation between 64 bit "long long" and "unsigned long long" stack allocated (not pointers) data member types within a C++ class
       [not found] <20051129155801.9144.mstraub@gmail.com>
@ 2010-01-19  2:08 ` tromey at redhat dot com
  2010-01-19 12:28 ` mstraub at gmail dot com
  1 sibling, 0 replies; 2+ messages in thread
From: tromey at redhat dot com @ 2010-01-19  2:08 UTC (permalink / raw)
  To: gdb-prs


------- Additional Comments From tromey at redhat dot com  2010-01-19 02:08 -------
Waiting for feedback for 4 years.
Also, I tried this with recent gcc+gdb, and it worked fine.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |WORKSFORME


http://sourceware.org/bugzilla/show_bug.cgi?id=9144

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug c++/9144] gdb assumes 4 byte separation between 64 bit "long long" and "unsigned long long" stack allocated (not pointers) data member types within a C++ class
       [not found] <20051129155801.9144.mstraub@gmail.com>
  2010-01-19  2:08 ` [Bug c++/9144] gdb assumes 4 byte separation between 64 bit "long long" and "unsigned long long" stack allocated (not pointers) data member types within a C++ class tromey at redhat dot com
@ 2010-01-19 12:28 ` mstraub at gmail dot com
  1 sibling, 0 replies; 2+ messages in thread
From: mstraub at gmail dot com @ 2010-01-19 12:28 UTC (permalink / raw)
  To: gdb-prs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1503 bytes --]


------- Additional Comments From mstraub at gmail dot com  2010-01-19 12:28 -------
Subject: Re:  gdb assumes 4 byte separation between 64 bit "long 
	long" and "unsigned long long" stack allocated (not pointers) data member 
	types within a C++ class

We as an org upgraded to a more recent version of redhat as well as
SuSE a while back.  The problem disappeared at that time.
So its definitely not an issue on more recent versions of gdb.

If you haven't already, you can consider this bug unverifiable/fixed/closed.

Thanks
Michael Straub

On Mon, Jan 18, 2010 at 9:08 PM, tromey at redhat dot com
<sourceware-bugzilla@sourceware.org> wrote:
>
> ------- Additional Comments From tromey at redhat dot com  2010-01-19 02:08 -------
> Waiting for feedback for 4 years.
> Also, I tried this with recent gcc+gdb, and it worked fine.
>
>
> --
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>             Status|ASSIGNED                    |RESOLVED
>         Resolution|                            |WORKSFORME
>
>
> http://sourceware.org/bugzilla/show_bug.cgi?id=9144
>
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.
>


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=9144

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-01-19 12:28 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <20051129155801.9144.mstraub@gmail.com>
2010-01-19  2:08 ` [Bug c++/9144] gdb assumes 4 byte separation between 64 bit "long long" and "unsigned long long" stack allocated (not pointers) data member types within a C++ class tromey at redhat dot com
2010-01-19 12:28 ` mstraub at gmail dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).