Re: inner block not inside outer block

Re: inner block not inside outer block

[David Anderson]

|
|> Date: Sun, 28 Dec 2003 13:46:56 -0500
|> From: Daniel Jacobowitz <drow@mvista.com>
|> 
|> You can't use readelf but I assume you can get one of
|> the other DWARF debugging tools to work - maybe dwarfdump - and figure
|> out what the actual bounds of the blocks in question are?

From:"Eli Zaretskii" <eliz@elta.co.il>
|I tried dwarfdump (the version from 29-Aug-2001), but couldn't build
|it, not even on Debian GNU/Linux: it chokes on the missing definition
|of the `Elf' data type.  How did you manage to build it?  Is there

There was one release with a botch in the #include stuff, which
lead to a build error on linux.
The current version is libdwarf20031006.tar.gz

|perhaps a newer version that is better?  (I tried to google for it and
|found a pointer to Dave Anderson's page where there's supposed to be a
|version from this year, but that page seems to be unreachable.)

reality.sgiweb.org went down Monday at 6:30 or so Pacific Time. 
As of 10AM Pacific Time it seems to be back up.

If you still have problems building, let me know the details
as I do want it to build correctly!
David Anderson

Re: inner block not inside outer block

[Eli Zaretskii]

> Date: Tue, 30 Dec 2003 09:57:22 -0800 (PST)
> From: David Anderson <davea@quasar.engr.sgi.com>
> 
> |perhaps a newer version that is better?  (I tried to google for it and
> |found a pointer to Dave Anderson's page where there's supposed to be a
> |version from this year, but that page seems to be unreachable.)
> 
> reality.sgiweb.org went down Monday at 6:30 or so Pacific Time. 
> As of 10AM Pacific Time it seems to be back up.

Thanks, it was down when I tried earlier today.

inner block not inside outer block

[Eli Zaretskii]

I've just compiled GDB 6.0 with DJGPP (patches to fix what was broken
to follow shortly) using GCC 3.3.2, and while trying the classic
"break main; run" test in GDB debugging itself, I see several messages
like this:

   During symbol reading, inner block not inside outer block in internal_vproblem 
   During symbol reading, inner block (0x1-0xffe289b8) not inside outer block (0x11b09a-0x11b2e0)
   During symbol reading, block at 0x1 out of order

I've read the description of these messages in the manual, which seems
to say that, as a user, I shouldn't worry about them.  What I'm not
sure about is what should I do as a _GDB_maintainer_.  Is this a GDB
bug? a GCC bug? something specific to the DJGPP port of either or both
of them? something else?  Should I report that somewhere or is it a
known problem?

(In case it matters, this GDB was compiled with DWARF-2 debug info.)

TIA

Re: inner block not inside outer block

[Daniel Jacobowitz]

On Sun, Dec 28, 2003 at 01:25:53PM +0200, Eli Zaretskii wrote:
> I've just compiled GDB 6.0 with DJGPP (patches to fix what was broken
> to follow shortly) using GCC 3.3.2, and while trying the classic
> "break main; run" test in GDB debugging itself, I see several messages
> like this:
> 
>    During symbol reading, inner block not inside outer block in internal_vproblem 
>    During symbol reading, inner block (0x1-0xffe289b8) not inside outer block (0x11b09a-0x11b2e0)
>    During symbol reading, block at 0x1 out of order
> 
> I've read the description of these messages in the manual, which seems
> to say that, as a user, I shouldn't worry about them.  What I'm not
> sure about is what should I do as a _GDB_maintainer_.  Is this a GDB
> bug? a GCC bug? something specific to the DJGPP port of either or both
> of them? something else?  Should I report that somewhere or is it a
> known problem?
> 
> (In case it matters, this GDB was compiled with DWARF-2 debug info.)

This means that the address range of either the psymtab or symtab is
incorrect.  It could be either incorrect debug information (probably in
the linker relocation handling) or it could be a GDB bug (probably in
dwarf2read.c).  You can't use readelf but I assume you can get one of
the other DWARF debugging tools to work - maybe dwarfdump - and figure
out what the actual bounds of the blocks in question are?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: inner block not inside outer block

[Eli Zaretskii]

> Date: Sun, 28 Dec 2003 13:46:56 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> You can't use readelf but I assume you can get one of
> the other DWARF debugging tools to work - maybe dwarfdump - and figure
> out what the actual bounds of the blocks in question are?

I tried dwarfdump (the version from 29-Aug-2001), but couldn't build
it, not even on Debian GNU/Linux: it chokes on the missing definition
of the `Elf' data type.  How did you manage to build it?  Is there
perhaps a newer version that is better?  (I tried to google for it and
found a pointer to Dave Anderson's page where there's supposed to be a
version from this year, but that page seems to be unreachable.)

Or maybe there are alternative tools--what are they?

TIA

Re: inner block not inside outer block

[Daniel Jacobowitz]

On Tue, Dec 30, 2003 at 04:39:20PM +0200, Eli Zaretskii wrote:
> > Date: Sun, 28 Dec 2003 13:46:56 -0500
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > You can't use readelf but I assume you can get one of
> > the other DWARF debugging tools to work - maybe dwarfdump - and figure
> > out what the actual bounds of the blocks in question are?
> 
> I tried dwarfdump (the version from 29-Aug-2001), but couldn't build
> it, not even on Debian GNU/Linux: it chokes on the missing definition
> of the `Elf' data type.  How did you manage to build it?  Is there
> perhaps a newer version that is better?  (I tried to google for it and
> found a pointer to Dave Anderson's page where there's supposed to be a
> version from this year, but that page seems to be unreachable.)
> 
> Or maybe there are alternative tools--what are they?

Well, the last time that I needed to use it it built OK on Debian
GNU/Linux; I was also using a 2001 version.  You may need to debug
GDB's dwarf2read instead and figure out what the debugging information
says that way :(

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: inner block not inside outer block

[Daniel Berlin]

>
> Well, the last time that I needed to use it it built OK on Debian
> GNU/Linux; I was also using a 2001 version.  You may need to debug
> GDB's dwarf2read instead and figure out what the debugging information
> says that way :(

There is a newer version than the 2001 version, but honestly, i can't
remember where i got it.
It started to add suppotr for DWARF3 stuff.
To compile libdwarf, you need libelf installed.
That is probably the whole "Elf" problem you are experiencing.

Re: inner block not inside outer block

[Paul Koning]

>>>>> "Eli" == Eli Zaretskii <eliz@elta.co.il> writes:

 Eli> I've just compiled GDB 6.0 with DJGPP (patches to fix what was
 Eli> broken to follow shortly) using GCC 3.3.2, and while trying the
 Eli> classic "break main; run" test in GDB debugging itself, I see
 Eli> several messages like this:

 Eli> During symbol reading, inner block not inside outer block in
 Eli> internal_vproblem During symbol reading, inner block
 Eli> (0x1-0xffe289b8) not inside outer block (0x11b09a-0x11b2e0)
 Eli> During symbol reading, block at 0x1 out of order

 Eli> I've read the description of these messages in the manual, which
 Eli> seems to say that, as a user, I shouldn't worry about them.
 Eli> What I'm not sure about is what should I do as a
 Eli> _GDB_maintainer_.  Is this a GDB bug? a GCC bug? something
 Eli> specific to the DJGPP port of either or both of them? something
 Eli> else?  Should I report that somewhere or is it a known problem?

 Eli> (In case it matters, this GDB was compiled with DWARF-2 debug
 Eli> info.)

I recently had a battle with GDB 5.3 on the same issue -- which was
hidden because that message was turned off by default.

It turned out that the recovery code (in 5.3 anyway) for this
condition makes matters worse by fiddling with the start/end values of
the offending blocks.  This is a bad idea because the blocks in
question are in fact completely unrelated (it's anyone's guess why the
compiler is putting out such nonsense).  In one case, I was ending up
with a block whose start address was larger than its end address.  A
consequence of this was backtrace problems, caused by gdb
misidentifying which function a particular PC value belongs to.

I fixed this by inserting "continue;" immediately after the complain
message, i.e., not changing the start or end of either block and not
setting the superblock pointer when the other block clearly can't be
the superblock.

By the way, that was GDB for mips, which I think is ecoff, fed by gcc
3.0.1 or thereabouts.

    paul

Re: inner block not inside outer block

[Eli Zaretskii]

> Date: Mon, 29 Dec 2003 09:54:55 -0500
> From: Paul Koning <pkoning@equallogic.com>
> 
> It turned out that the recovery code (in 5.3 anyway) for this
> condition makes matters worse by fiddling with the start/end values of
> the offending blocks.  This is a bad idea because the blocks in
> question are in fact completely unrelated (it's anyone's guess why the
> compiler is putting out such nonsense).

Could you please elaborate on the ``blocks in question are in fact
completely unrelated'' issue?  Are you saying that the ``inner'' block
is unrelated to the ``outer'' block?

Also, do I understand correctly that you consider this a compiler bug?
I tend to think that as well, so I googled for similar messages, in
the hope that I will hit a discussion on some GCC forum that would
shed some light on this, but came up with nothing useful.

> I fixed this by inserting "continue;" immediately after the complain
> message, i.e., not changing the start or end of either block and not
> setting the superblock pointer when the other block clearly can't be
> the superblock.

Perhaps we should commit such a change; it's not in the CVS AFAICS.

> By the way, that was GDB for mips, which I think is ecoff, fed by gcc
> 3.0.1 or thereabouts.

What was the format of the debug info?  Was it DWARF2, by any chance,
and if so, did you try stabs?  In my case, the object format is COFF
and the debug info is DWARF2.

Anyway, thanks for the feedback.

Re: inner block not inside outer block

[Daniel Jacobowitz]

On Mon, Dec 29, 2003 at 05:36:17PM +0200, Eli Zaretskii wrote:
> > Date: Mon, 29 Dec 2003 09:54:55 -0500
> > From: Paul Koning <pkoning@equallogic.com>
> > 
> > It turned out that the recovery code (in 5.3 anyway) for this
> > condition makes matters worse by fiddling with the start/end values of
> > the offending blocks.  This is a bad idea because the blocks in
> > question are in fact completely unrelated (it's anyone's guess why the
> > compiler is putting out such nonsense).
> 
> Could you please elaborate on the ``blocks in question are in fact
> completely unrelated'' issue?  Are you saying that the ``inner'' block
> is unrelated to the ``outer'' block?
> 
> Also, do I understand correctly that you consider this a compiler bug?
> I tend to think that as well, so I googled for similar messages, in
> the hope that I will hit a discussion on some GCC forum that would
> shed some light on this, but came up with nothing useful.
> 
> > I fixed this by inserting "continue;" immediately after the complain
> > message, i.e., not changing the start or end of either block and not
> > setting the superblock pointer when the other block clearly can't be
> > the superblock.
> 
> Perhaps we should commit such a change; it's not in the CVS AFAICS.

Hmm.... maybe.  I've learned that the business of trying to guess what
inconsistent debug information means is a pretty bad one.  There's
probably another broken version of GCC where the existing fixup is
better.

> > By the way, that was GDB for mips, which I think is ecoff, fed by gcc
> > 3.0.1 or thereabouts.
> 
> What was the format of the debug info?  Was it DWARF2, by any chance,
> and if so, did you try stabs?  In my case, the object format is COFF
> and the debug info is DWARF2.

No, it would probably have been stabs-in-mdebug.  GCC 3.0.1 didn't
support DWARF2 for MIPS targets.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: inner block not inside outer block

[Eli Zaretskii]

> Date: Mon, 29 Dec 2003 11:05:57 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > What was the format of the debug info?  Was it DWARF2, by any chance,
> > and if so, did you try stabs?  In my case, the object format is COFF
> > and the debug info is DWARF2.
> 
> No, it would probably have been stabs-in-mdebug.  GCC 3.0.1 didn't
> support DWARF2 for MIPS targets.

For the record, I used GCC 3.3.2 for the build in question.

Re: inner block not inside outer block

[Paul Koning]

>>>>> "Eli" == Eli Zaretskii <eliz@elta.co.il> writes:

 >> Date: Mon, 29 Dec 2003 09:54:55 -0500 From: Paul Koning
 >> <pkoning@equallogic.com>
 >> 
 >> It turned out that the recovery code (in 5.3 anyway) for this
 >> condition makes matters worse by fiddling with the start/end
 >> values of the offending blocks.  This is a bad idea because the
 >> blocks in question are in fact completely unrelated (it's anyone's
 >> guess why the compiler is putting out such nonsense).

 Eli> Could you please elaborate on the ``blocks in question are in
 Eli> fact completely unrelated'' issue?  Are you saying that the
 Eli> ``inner'' block is unrelated to the ``outer'' block?

What I meant is that the address ranges weren't anywhere near each
other, but they did look like valid ranges for blocks somewhere in the
program.  So I concluded that the problem was that unrelated blocks
were being tied together by mistake.

 Eli> Also, do I understand correctly that you consider this a
 Eli> compiler bug?  I tend to think that as well, so I googled for
 Eli> similar messages, in the hope that I will hit a discussion on
 Eli> some GCC forum that would shed some light on this, but came up
 Eli> with nothing useful.

After thinking about it some more I realize that this is an
unsupported assumption.  As one of the other messages just now points
out, it could be a gdb but (in reading the data), a compiler bug, or a
linker bug.

I have no data to narrow it down better than that, and my skills in
this area aren't really adequate to do so.

 >> I fixed this by inserting "continue;" immediately after the
 >> complain message, i.e., not changing the start or end of either
 >> block and not setting the superblock pointer when the other block
 >> clearly can't be the superblock.

 Eli> Perhaps we should commit such a change; it's not in the CVS
 Eli> AFAICS.

 >> By the way, that was GDB for mips, which I think is ecoff, fed by
 >> gcc 3.0.1 or thereabouts.

 Eli> What was the format of the debug info?  Was it DWARF2, by any
 Eli> chance, and if so, did you try stabs?  In my case, the object
 Eli> format is COFF and the debug info is DWARF2.

Sorry, I'm still learning this stuff...  Stabs, I believe -- the
default MIPS format for GCC 3.0.1.  I don't think Dwarf-2 is even
supported in that target/version.

	  paul