From xemacs-m  Wed Jul 30 02:00:07 1997
Received: from altair.xemacs.org (steve@xemacs.miranova.com [206.190.83.19])
	by xemacs.org (8.8.5/8.8.5) with ESMTP id CAA06276
	for <xemacs-beta@xemacs.org>; Wed, 30 Jul 1997 02:00:06 -0500 (CDT)
Received: (from steve@localhost)
	by altair.xemacs.org (8.8.6/8.8.6) id AAA25158;
	Wed, 30 Jul 1997 00:04:10 -0700
Mail-Copies-To: never
To: xemacs-beta@xemacs.org
Subject: Re: why does the debugger print byte-codes?
References: <199707300459.NAA17842@orion.kurims.kyoto-u.ac.jp> 	<m2pvs1t7mj.fsf@altair.xemacs.org> <199707300620.PAA22795@orion.kurims.kyoto-u.ac.jp>
X-Face: `'%\i;ySOu]g?NlziJSk_$&@]KP`}~PEQPjZ5;nxSaDW_o$4+4%Ab]%Ifw3ZR;7TIT3,O,'
 @2{L;]ox6kc;$_5kU'n**9vFg-]eV~GbxSVCx|(s%uR[],*:^WKmC`B}(;|k9/m]gwt?&`t;^rfCJg
 khHH>pP1W\)xM0U@!FNDD72{3fDP$PkBhx^7Z?-WxH6DbFN:QOnT`llzW}VGdYv;n9lzljQvKTIBhQ
 YuV
X-Attribution: sb
From: SL Baur <steve@xemacs.org>
In-Reply-To: Jens-Ulrik Holger Petersen's message of "Wed, 30 Jul 1997 15:20:42 +0900"
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: 30 Jul 1997 00:04:09 -0700
Message-ID: <m2k9i9t40m.fsf@altair.xemacs.org>
Lines: 86
X-Mailer: Gnus v5.4.64/XEmacs 20.3(beta16) - "Budapest"

As it turns out, the question in the Subject is an excellent
question.  I don't know.

Jens-Ulrik Holger Petersen <petersen@kurims.kyoto-u.ac.jp> writes:

> Hope Steve doesn't mind me quoting this bit of a private mail to
> the list.

Nope.

>>>>>> "sb" == SL Baur <steve@xemacs.org> writes:

sb> I have no idea what the use is of printing raw byte code
sb> out (I can't read it), maybe that part of XEmacs should
sb> be changed.

I took a look through the backtrace code after writing that.  It turns 
out there already exists special logic to avoid printing raw byte code 
in lisp stack bactraces.

There are 6 portions of a bytecompiled object (quoted from comments in 
print.c where this gets printed out):

  /* COMPILED_ARGLIST = 0 */
  /* COMPILED_BYTECODE = 1 */
  /* COMPILED_CONSTANTS = 2 */
  /* COMPILED_STACK_DEPTH = 3 */
  /* COMPILED_DOC_STRING = 4 */
  /* COMPILED_INTERACTIVE = 5 */

The logic that prints out the bytecode specifically avoids throwing
raw binary data out.  Instead it prints it as "...(%d)" where %d gets
filled in with the number of bytes of bytecode.

The code that prints out the constants isn't clean.  (quoting from
Furutakasan's backtrace):

#<compiled-function (from "mew-draft.elc") nil "...(366)" [this-command-keys key lookup-key current-global-map command 0 i nil len func mew-subsequence universal-argument digit-argument keyswitch (byte-code 

I've cut off the listing where the fuckage starts.


  call-interactively(kill-region)
  #<compiled-function (from "mew-draft.elc")
                      ^^^^^^^^^^^^^^^^^^^^^^

This is the COMPILED_FUNCTION_ANNOTATION_HACK at work.  Byte compiled
code from external .elcs gets this field set correctly from the file
name containing the bytecode.  Byte compiled code anywhere else (as in 
interactive calls to the bytecompiler) do not.

  nil

The arglist.

  "...(366)"

There's the bytecode.  So that part *is* working.

  [this-command-keys key lookup-key current-global-map command 0
  i nil len func mew-subsequence universal-argument digit-argument
  keyswitch (byte-code ...

This is the compiled constants vector.  I have no idea why byte code
is in it.

There are also two other occurrences of 'byte-code("<extreme fuckage>...")
in the backtrace.

I haven't found the routine printing out these other instances of byte 
code yet.

> That was my suspicion!  Yes, I think eliminating byte-code output
> from the debugger sounds very sensible.  If gdb can point to the
> source then emacs' debugger should be able to too!

Gdb can't do it alone.  It also requires `-g' support from the
compiler for line numbers.

> Yes, it would be very cool having the backtrace via the ".el" file
> instead.  How hard would that be to implement?

I would guess it would not be very easy.  We would have to solve the
line number problem, also as noted above the
COMPILED_FUNCTION_ANNOTATION_HACK does not keep reliable information
about where byte code came from.

