Re: bug report

[Zack Weinberg <zack@wolery.cumb.org>]

On Tue, Jun 27, 2000 at 03:17:47PM -0300, Alexandre Oliva wrote:
> On Jun 27, 2000, Zack Weinberg <zack@wolery.cumb.org> wrote:
> 
> > And it should be more enthusiastic about the alternative of posting a
> > URL.
> 
> Nope.  Downloading large files is not a reasonable option for me, for
> example.  I'd much rather have them dropped interactively in my
> mailbox.

Not quite what I meant.  First choice should still be to include the
.i file in the bug report.  But what happens nowadays is that someone
sees their .i file is too big for the mailing list, so they say "mail
me privately".  I'd much rather get an URL than that.

zw
>From espie@schutzenberger.liafa.jussieu.fr Tue Jun 27 12:02:00 2000
From: Marc Espie <espie@schutzenberger.liafa.jussieu.fr>
To: gcc-patches@gcc.gnu.org
Cc: gcc-bugs@gcc.gnu.org
Subject: [PATCH] dwarf2out.c breakage on ss2000-06-26
Date: Tue, 27 Jun 2000 12:02:00 -0000
Message-id: <20000627210226.A18770@schutzenberger.liafa.jussieu.fr>
X-SW-Source: 2000-06/msg00665.html
Content-length: 948

Recent changes to dwarf2out.c broke OpenBSD, and probably a lot of other
platforms as well (most platforms that define DWARF2_UNWIND_INFO 0).

If UNALIGNED_INT_ASM_OP is unavailable, dwarf2out.c does not provide a
suitable definition for ASM_OUTPUT_DWARF_DATA2, even though it uses it.

The following patch restores OpenBSD to sanity.


Tue Jun 27 20:59:01 CEST 2000	Marc Espie <espie@openbsd.org>
	* dwarf2out.c (ASM_OUTPUT_DWARF_DATA2): provide in the
	case where UNALIGNED_INT_ASM_OP is unavailable.

--- gcc/dwarf2out.c.orig	Tue Jun 27 20:41:23 2000
+++ gcc/dwarf2out.c	Tue Jun 27 20:45:26 2000
@@ -494,6 +494,9 @@ static void def_cfa_1		 	PARAMS ((const 
 #define ASM_OUTPUT_DWARF_DELTA(FILE,LABEL1,LABEL2) \
   ASM_OUTPUT_DWARF_DELTA4 (FILE,LABEL1,LABEL2)
 
+#define ASM_OUTPUT_DWARF_DATA2(FILE,VALUE) \
+  assemble_integer (GEN_INT (VALUE), 2, 1)
+
 #define ASM_OUTPUT_DWARF_DATA4(FILE,VALUE) \
   assemble_integer (GEN_INT (VALUE), 4, 1)
 
>From lucier@math.purdue.edu Tue Jun 27 12:13:00 2000
From: Brad Lucier <lucier@math.purdue.edu>
To: gcc-help@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Cc: lucier@math.purdue.edu
Subject: difficulties debugging code
Date: Tue, 27 Jun 2000 12:13:00 -0000
Message-id: <200006271913.OAA05805@polya.math.purdue.edu>
X-SW-Source: 2000-06/msg00666.html
Content-length: 2479

I don't know if this is a bug or whether I need help, so I'm asking both
lists.

I'm trying to debug some code compiled with gcc-2.96-20000624 on
alphaev6-unknown-linux-gnu with options

gcc -fno-math-errno -mieee -mcpu=ev6  -Wall -W -O1 -save-temps -g -c ...

and linked with

gcc -g -mieee -rdynamic ...

I'm using gdb 4.17.0.11.  Everything is fine until I try to step through the
following code:

void ___setup
   (___setup_params_struct *setup_params)
{
  ___processor_state ___ps;
  ___mod_or_lnk mol;
  int i;
  if (setup_params == 0 ||
      setup_params->version_major != 21)
    return;
  if (setup_state != 0)
    return;
  setup_state = 2;  
 ___setup_params = *setup_params; // <<<<<<<<<<<<<<<<<<<<<<<<<
...

Then I get a segmentation fault with the following message:

(gdb) s

Program received signal SIGSEGV, Segmentation fault.
warning: Hit beginning of text section without finding
warning: enclosing function for address 0xc39fff54
This warning occurs if you are debugging a function without any symbols
(for example, in a stripped executable).  In that case, you may wish to
increase the size of the search with the `set heuristic-fence-post' command.

Otherwise, you told GDB there was a function where there isn't one, or
(more likely) you have encountered a bug in GDB.
0xc39fff54 in ?? ()
(gdb)  up
#1  0x120043b00 in ___setup (setup_params=0x11ffff720) at setup.c:1415
1415      ___setup_params = *setup_params;
(gdb) print *setup_params
$1 = {version_major = 21, version_minor = 0, argc = 1, argv = 0x11ffff868, min_heap = 0, max_heap = 0, live_percent = 0, gc_hook = 0, fatal_error = 0, 
  standard = 0, debug_level = 0, default_io_encoding = 1, force_tty = 0, force_unbuffered_io = 0, linker = 0x120041410 <____20_gsi__>, event_get = 0, 
  event_handler = 0, dummy1 = 0, dummy2 = 0, dummy3 = 0, dummy4 = 0, dummy5 = 0, dummy6 = 0, dummy7 = 0, dummy8 = 0}

So *setup_params seems perfectly fine.

The assembly code at this point is

$LM658:
	.stabn 68,0,1415,$LM658
	lda $16,___setup_params
	lda $18,176
	jsr $26,memcpy
	ldgp $29,0($26)

The real bug I'm trying to track down is a little farther along in
the execution path, so I'm just getting frustrated playing with this
part of the code.

So, do any of you have any ideas?  If I set a breakpoint after this
point in the code and start stepping from there, it just segfaults
in some other place (where there really isn't a problem, either).
I haven't seen this type of behavior before.

Brad Lucier
>From dave@hiauly1.hia.nrc.ca Tue Jun 27 12:51:00 2000
From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
To: dave@hiauly1.hia.nrc.ca (John David Anglin)
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: Miscellaneous testsuitsuite failures under hpux 10.20
Date: Tue, 27 Jun 2000 12:51:00 -0000
Message-id: <200006271951.PAA04221@hiauly1.hia.nrc.ca>
References: <200006232114.RAA13066@hiauly1.hia.nrc.ca>
X-SW-Source: 2000-06/msg00667.html
Content-length: 665

> struct foo {
>   void *entry[40];
> } __attribute__ ((aligned(32)));
> 
> This gives a value of 256 for rli->offset_align.  The bit field for

The value of 256 for rli->offset_align doesn't seem to make sense.  It
looks like the compiler is applying __attribute__ to entry as well as foo.

The current design limits the alignment of field declarations to values
that can be contained in 8 bits.  Is this big enough for all reasonable
purposes?  Obviously, larger alignments may be needed for other types.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)
>From vonbrand@inf.utfsm.cl Tue Jun 27 12:53:00 2000
From: Horst von Brand <vonbrand@inf.utfsm.cl>
To: Philipp Thomas <pthomas@suse.de>, gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: Re: bootstrap fails: msgfmt: Not found 
Date: Tue, 27 Jun 2000 12:53:00 -0000
Message-id: <200006271954.e5RJs2J18693@pincoya.inf.utfsm.cl>
References: <20000627171632.N13023@Jeffreys.suse.de>
X-SW-Source: 2000-06/msg00668.html
Content-length: 586

Here (Alpha, Red Hat 6.1, CVS from earlier today) I'm getting:

make[3]: Entering directory `/h/redhat/BUILD/GCC/build-gcc-20000627/gcc/po'
file=`echo en_GB | sed 's,.*/,,'`.gmo \
  && rm -f $file && PATH=../src:$PATH no -o $file /mnt/pincoya/build/GCC/gcc/gcc/po/en_GB.po
/bin/sh: no: command not found
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
>From aoliva@redhat.com Tue Jun 27 12:57:00 2000
From: Alexandre Oliva <aoliva@redhat.com>
To: Zack Weinberg <zack@wolery.cumb.org>
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: bug report
Date: Tue, 27 Jun 2000 12:57:00 -0000
Message-id: <oru2eerj82.fsf@guarana.lsd.ic.unicamp.br>
References: <XFMail.000627112335.gregory.hosler@eno.ericsson.se> <20000627054811.G23854@Jeffreys.suse.de> <20000626205156.R279@wolery.cumb.org> <orpup3rnsk.fsf@guarana.lsd.ic.unicamp.br> <20000627112505.W279@wolery.cumb.org>
X-SW-Source: 2000-06/msg00669.html
Content-length: 684

On Jun 27, 2000, Zack Weinberg <zack@wolery.cumb.org> wrote:

> First choice should still be to include the .i file in the bug
> report.  But what happens nowadays is that someone sees their .i
> file is too big for the mailing list, so they say "mail me
> privately".  I'd much rather get an URL than that.

I see.  I agree.  A patch for the bug reporting instructions will be
appreciated :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me