Conference turris::decladebug

922.0. "Unable to recognize binary with magic number -120" by RDGENG::HAQUE (Shaheed R. Haque, 830-3531, reo2-f/b3) Thu Apr 10 1997 08:20

ladebug V4.0-30
Digital UNIX V4.0B

This version of ladebug does not understand loadable drivers. The error messages
are:

================================================================================
# ladebug -k vmunix.0 vmcore.0
Welcome to the Ladebug Debugger Version 4.0-30
------------------
object file name: vmunix.0
core file name: vmcore.0
Reading symbolic information ...Unable to recognize binary with magic number -10
Unable to recognize binary with magic number -120
Unable to recognize binary with magic number -120
done
(ladebug) listobj
ObjectName                        Start Addr           Size        Symbols
                                                    (bytes)         Loaded
----------------------------------------------------------------------------
vmunix.0                   0xfffffc0000230000        2950048          Yes
/subsys/cbfc.mod           0xffffffff87cfc000          24576           No
/subsys/tlink.mod          0xffffffff87d0a000          32768           No
/subsys/tmux.mod           0xffffffff87d16000          40960           No
================================================================================

Note that there are three occurances of the error message, once for each of my
three drivers. The drivers were built in the normal way, using the objZ utility.
Thus:

# file /subsys/*.mod
/subsys/cbfc.mod:       alpha compressed COFF executable or object module not st
ripped - version 3.11-10
/subsys/tlink.mod:      alpha compressed COFF executable or object module not st
ripped - version 3.11-10
/subsys/tmux.mod:       alpha compressed COFF executable or object module not st
ripped - version 3.11-10

This is a major problem for me, as ladebug cannot even decode the stack trace
through ones of these modules:

(ladebug) t
>0  0xfffffc00004160b8 in boot() ../../../../src/kernel/arch/alpha/machdep.c
#1  0xfffffc000027a36c in panic(s=0xffffffff87d02a30="cbfc.c[2840]:Assertion fai
led: 1 == 2\n") ../../../../src/kernel/bsd/subr_prf.c:791
#2  0xffffffff87cffde8

even though kdbx can:

(kdbx) t
>  0 boot(0x0, 0xfffffc0007f83b80, 0x2100000021, 0x6700000021, 0xfffffc000000000
8) ["../../../../src/kernel/arch/alpha/machdep.c":2466, 0xfffffc00004160b8]
   1 panic(s = 0xffffffff87d02a30 = "cbfc.c[2840]:Assertion failed: 1 == 2\n") [
"../../../../src/kernel/bsd/subr_prf.c":791, 0xfffffc000027a36c]
   2 cbfc_unitdata_ind(mp = 0xfffffc0006f98700, unitdata = 0xfffffc00072fe800, c
bfc = 0xfffffc00057f9928) ["cbfc.c":2840, 0xffffffff87cffde8]
   3 cbfc_l_rput(q = 0xfffffc000741b200, mp = 0xfffffc0006f98700) ["cbfc.c":1466
, 0xffffffff87cfd838]
   4 csq_lateral(sqh = 0xfffffc000741b288, sq = 0xfffffc0006f98740) ["../../../.
./src/kernel/streams/str_synch.c":992, 0xfffffc000037d3a8]
   5 puthere(0xfffffc0006f98700, 0xfffffc0000533c60, 0x102d, 0xfffffc000741a0b8,
 0xfffffc0000383648) ["../../../../src/kernel/streams/str_util.c":1119, 0xfffffc
000037ff60]
   6 dlb_rsrv(q = 0xfffffc000741a000) ["../../../../src/kernel/streamsm/dlb.c":1
119, 0xfffffc0000383644]
   7 sq_wrapper(q = 0xfffffc000741a000) ["../../../../src/kernel/streams/str_run
q.c":137, 0xfffffc00003760c0]
   8 csq_lateral(sqh = 0xfffffc000741a088, sq = 0xfffffc0001e97680) ["../../../.
./src/kernel/streams/str_synch.c":992, 0xfffffc000037d3a8]
   9 runq_run() ["../../../../src/kernel/streams/str_runq.c":108, 0xfffffc000037
5ff0]
  10 netisr_thread() ["../../../../src/kernel/net/netisr.c":841, 0xfffffc00002b5
c60]

Shaheed,

>> # file /subsys/*.mod
>> /subsys/cbfc.mod:       alpha compressed COFF executable or object module not
>> stripped - version 3.11-10
>> /subsys/tlink.mod:      alpha compressed COFF executable or object module not 
>> stripped - version 3.11-10
>> /subsys/tmux.mod:       alpha compressed COFF executable or object module not
>> stripped - version 3.11-10

Doesn't this mean that the .mod files are actually in compressed format. 
And hence their magic number is something that we don't recognize. I
don't believe we support compressed files yet - so ladebug is not going
to read the symbols for your drivers and hence not able to give you any
stack trace information.


hope this helps.
shamim

We don't support compressed binaries.  In fact, Ladebug
now detects this magic number and prints out a better
message.  (Vicki Hassett made these changes a while back 
now.)

The new message looks something like:

Debugging of compressed images is not supported.
If you need symbolic debugging capability for "<image>", 
uncompress prior to running ladebug.

Dbx does support compressed binaries, as evidenced by the fact that
that kdbx understands the stack.  I don't mean to keep heaping things
on your plate guys, but this went into V4.0 I believe.

PeterT

Given that compressed binaries are not supported, can I make a formal request
that they are, ASAP? It is going to be a bit of a pain if not becuase the
documented way to build drivers uses objZ - it is not even documented AFAIK that
the kernel supports loading of uncompressed binaries.

	Thanks, Shaheed

There are a couple of ways to make compressed binaries work.

In every other modern operating system that I know of that uses
compression, it's done at the file level or below, so that none
of the tools ever know that a file is compressed.  The file is
expanded before any tool ever sees it.

Since Digital Unix chose not to do it this way, I wonder how many
other tools are "broken" because they can't handle compressed
binaries.

I would suggest that the better fix would be to remove any 
knowledge of compression from *all* the tools and put it in one 
place in the operating system.

Talk to Andrew Duane, for one.  He's the one that requested the support
in the first place, I believe.

PeterT