> Date: Wed, 30 Sep 2015 19:33:44 +0200 (CEST)
> From: "Ulrich Weigand"
>
> Hello,
>
> I've been looking into supporting __float128 in the debugger, since we're
> now introducing this type on PowerPC. Initially, I simply wanted to do
> whatever GDB does on Intel, but it turns out debugging __fl
Execution of the test randomly fails for me on OpenBSD/amd64. Looking
at the code, it seems it is doing an out-of-bounds array access. For
refernce I've copied the code of the testcase below. As you can see
there's a foo(0) call in main(). Therefore
struct foo **upper = &as->x[rank * 8 - 1];
> Date: Wed, 21 Jan 2009 15:08:47 +0400
>
> Hello,
>
> Eric and I discovered a discrepancy in the DWARF register numbering
> on SPARC for floating point registers. The problem is more visible
> on SPARC 64-bit because they are used for parameter passing, whether
> i0 is used on 32-bit SPARC. Co
> Date: Wed, 6 Aug 2008 11:27:36 -0400
> From: Daniel Jacobowitz <[EMAIL PROTECTED]>
>
> On Wed, Aug 06, 2008 at 07:19:26PM +0400, Sergei Poselenov wrote:
> > (gdb) bt
> > #0 0x4004ec0c in raise () from /lib/libc.so.6
> > #1 0x40050234 in abort () from /lib/libc.so.6
> > Backtrace stopped: frame
Vaclav Haisman wrote:
> Gerald Pfeifer wrote:
> [...]
> > openSUSE 10.2 now comes with flex 2.5.33, but FreeBSD, for example, still
> > is at flex 2.5.4. Just some additional data pointes...
> FreeBSD has version 2.5.33 as textproc/flex port.
But that will not replace the system flex, so it will
> Ian Lance Taylor writes:
> > Andrew Haley <[EMAIL PROTECTED]> writes:
> >
> > > In practice, %ebp either points to a call frame -- not necessarily
> the
> > > most recent one -- or is null. I don't think that having an optional
> > > frame pointer mees you can use %ebp for anything r
> Jan Kratochvil writes:
>
> > currently (on x86_64) the gdb backtrace does not properly stop at
> > the outermost frame:
> >
> > #3 0x0036ddb0610a in start_thread () from
> /lib64/tls/libpthread.so.0
> > #4 0x0036dd0c68c3 in clone () from /lib64/tls/libc.so.6
> > #5 0x
> Date: Thu, 27 Jul 2006 09:46:36 +1200
> From: Danny Smith <[EMAIL PROTECTED]>
>
> From: Mark Kettenis [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 27, 2006 9:34 AM
>
> > The best thing to do is probably to define
> > DWARF2_FRAME_REG_OUT to always us
> Date: Mon, 24 Jul 2006 11:00:55 +1200
> From: Danny Smith <[EMAIL PROTECTED]>
>
> Any other ideas? What is likely GDB fallout?
GDB by default uses the SVR4 register numbering for DWARF & DWARF 2,
and the old dbx register numbering scheme for other debugging formats
(most notably stabs). Mixin
> Date: Sun, 18 Dec 2005 11:49:37 -0500
> From: Daniel Jacobowitz <[EMAIL PROTECTED]>
>
> On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote:
> > Looks like the new toplevel bootstrap infrastructure broke
> > bootstrapping on OpenBSD. I get a bootstrap
Looks like the new toplevel bootstrap infrastructure broke
bootstrapping on OpenBSD. I get a bootstrap comparison which is
caused by differences in the compilation directory encoded in the
object files from different stages.
Forcing the coplevel configure to use "mv" instead of "ln -s" by setting
From: Dale Johannesen <[EMAIL PROTECTED]>
Date: Thu, 21 Jul 2005 16:56:01 -0700
On x86 currently the alignments of double and long long are linked:
they are either 4 or 8 depending on whether -malign-double is set.
This follows the documentation of -malign-double. But it's wrong fo
From: Ben Elliston <[EMAIL PROTECTED]>
Date: Fri, 24 Jun 2005 23:50:58 +1000
For the second year in a row, about 30 people discussed removing the
replicated copies of the DejaGnu and Expect sources from the src
repository at the GCC Summit testing BOF.
The version of Expect in t
From: Ian Lance Taylor
Date: 15 May 2005 23:20:14 -0400
Well, we require an ISO C90 compiler; do we require ISO C90 libraries?
If we require the libraries, then we can remove a number of files from
libiberty, at least atexit.c, memchr.c, memcmp.c, memcpy.c, memmove.c,
memset.c,
14 matches
Mail list logo
