Questions on cross-gdb

Questions on cross-gdb

[Danny Backx]

Hi,

I have a cross-gdb working relatively well between my linux PC and a
i386-mingw32ce (Windows CE Embedded with a x86 clone processor) target.

My questions relate to gdb, not gdbserver. First, the output of "info share".
After setting e.g. solib-search-path, we want it to behave as follows :

(gdb) info share
From        To          Syms Read   Shared Object Library
                        No          \Windows\iphlpapi.dll
                        No          \Windows\ws2.dll
0x41ee1000  0x41eec1fc
Yes         /opt/x86mingw32ce/bin/libgcc_s_sjlj-1.dll
0x42a11000  0x42ae2990
Yes         /opt/x86mingw32ce/i386-mingw32ce/lib/libstdc++-6.dll
0x41f21000  0x420d9744  Yes         libace.dll
                        No          \Windows\coredll.dll
(gdb)

meaning that the paths with backslashes get treated well. Previous
situation (=bad) was :
(gdb) info share
From        To          Syms Read   Shared Object Library
                        No          \Windows\iphlpapi.dll
                        No          \Windows\ws2.dll
                        No          \network\x86\ace\libgcc_s_sjlj-1.dll
                        No          \network\x86\ace\libstdc++-6.dll
0x41f21000  0x420d9744  Yes         libace.dll
                        No          \Windows\coredll.dll
(gdb) 

There's support in the code for that (HAVE_DOS_BASED_FILE_SYSTEM), but
it doesn't get enabled in my cross-environment. gdb gets compiled by the
host gcc, which doesn't set stuff like _WIN32. So the
HAVE_DOS_BASED_FILE_SYSTEM never gets defined. This happens both in
gdb/* and in libiberty/* .

Question 1 : where should I hack this ? I would like it to come from
somewhere in the configuration scripts (and I'm now asking where would
be the best place). Another thing to edit is then include/filenames.h
which needs to grab this and do the right thing, instead of just
reacting to _WIN32 and such. But that's a trivial fix.

Question 2 : I occasionally have a problem - see below - setting
breakpoints. A pointer to what might be causing this would be
appreciated so I can chase the bug.

(gdb) break 65
warning: (Internal error: pc 0xd4720040 in read in psymtab, but not in
symtab.)

warning: (Internal error: pc 0xd4720040 in read in psymtab, but not in
symtab.)

warning: (Internal error: pc 0xd4720040 in read in psymtab, but not in
symtab.)

warning: (Internal error: pc 0xd4720040 in read in psymtab, but not in
symtab.)

warning: (Internal error: pc 0xd4720040 in read in psymtab, but not in
symtab.)

warning: (Internal error: pc 0xd4720040 in read in psymtab, but not in
symtab.)

Note: breakpoint 2 also set at pc 0xd4720040.
warning: (Internal error: pc 0xd4720040 in read in psymtab, but not in
symtab.)

Note: breakpoint 2 also set at pc 0xd4720040.
warning: (Internal error: pc 0xd4720040 in read in psymtab, but not in
symtab.)

Breakpoint 2 at 0x408078:
file /home/danny/src/ace/svn.dre.vanderbilt.edu/ACE_wrappers/ace/Singleton.cpp, line 65. (7 locations)
(gdb) c
Continuing.
Warning:
Cannot insert breakpoint 2.
Error accessing memory address 0xd4720040: Input/output error.

(gdb) q
The program is running.  Quit anyway (and kill it)? (y or n) n
Not confirmed.
(gdb) c
Continuing.
Warning:
Cannot insert breakpoint 2.
Error accessing memory address 0xd4720040: Input/output error.

(gdb) del 2
(gdb) where
#0  ACE_Singleton<ACE_Based_Pointer_Repository,
ACE_RW_Thread_Mutex>::instance ()

at /home/danny/src/ace/svn.dre.vanderbilt.edu/ACE_wrappers/ace/Singleton.cpp:62
#1  0x42e8109b in get_based_pointer_repository_instance () at
Based_Pointer_Test_Lib.cpp:36
#2  0x004013c5 in singleton_test () at Based_Pointer_Test.cpp:132
#3  0x0040272e in run_main () at Based_Pointer_Test.cpp:425
#4  0x00401153 in ace_tmain_i (argc=1, argv=0x16023230) at Main.cpp:30
#5  0x004086cc in ACE_Main::run_i (this=0x1601fb50, argc=1,
argv=0x16023230) at Main.cpp:27
#6  0x41f93efd in ACE_Main_Base::run (this=0x1601fb50,
lpCmdLine=0x1601fc70 L"") at OS_main.cpp:146
#7  0x004010c5 in WinMain (hInstance=0x4410022, hPrevInstance=0x0,
lpCmdLine=0x1601fc70 L"", 
    nCmdShow=5) at Main.cpp:27
#8  0x0040103b in WinMainCRTStartup (hInst=0x4410022, hPrevInst=0x0,
lpCmdLine=0x1601fc70 L"", 
    nCmdShow=5)
at /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/mingw/crt3.c:62
(gdb) c
Continuing.

Program exited with code 01.
(gdb) 

Thanks,

	Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

Re: Questions on cross-gdb

[Pedro Alves]

On Wednesday 19 August 2009 05:35:40, Danny Backx wrote:

> Question 2 : I occasionally have a problem - see below - setting
> breakpoints. 
> 
> (gdb) break 65
> warning: (Internal error: pc 0xd4720040 in read in psymtab, but not in
> symtab.)

This is a bug in GDB, see below.  But, it may be some corner case
triggered by bad debug info.  Note that 0xd4720040 is over 0x80000000, so
it's itself suspicious.  I suggest checking if this PC itself is
bogus or not.  If not bogus another possibility could be a sign
extending problem somewhere in GDB.

> A pointer to what might be causing this would be appreciated so I
> can chase the bug. 

GDB builds partial symbol tables (psymtab) and full symbol
tables (symtab) out of the same debug info, in different phases.  It starts
by doing a "light" scan of the debug info, and building the
lighter psymtabs with just enough information to be able to locate and
read in the more expensive full symbol tables, when required, on demand.
What you're seeing is that GDB found the symbol for line 65 in the partial
symbol table, and was then trying to expand the corresponding full symbol
table, but, due to some bug, the same symbol wasn't found in the full
symbol table.  This should never happen by design.  First questions would
be: which GDB version are you working with? --- try CVS HEAD; which debug
info format is this?  STABS? DWARF?  Prefer DWARF.  You can select
a format at compile time with -gstabs+ or -gdwarf-2 .

-- 
Pedro Alves