This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Fail in dw2-dos-drive.exp


The fail in dw2-dos-drive.exp on arm target leads me to looking into
this test case deeply,

 break 'z:file.c':func^M
 Cannot access memory at address 0x4^M
 (gdb) FAIL: gdb.dwarf2/dw2-dos-drive.exp: break 'z:file.c':func

some questions are raised, and the answers to them affect the scope of work,

The test isn't run on mingw32 target because dwarf2_support returns
false.  AFAIK, dwarf is supported on mingw32, do we want dwarf2_support
return true for mingw32 target (and cygwin target)?

If we tweak dwarf2_support to return true for mingw32 target, we'll get
errors like this, because '.4byte' isn't recognized by mingw32 gas.

  dw2-dos-drive.S:19: Error: unknown pseudo-op: `.4byte'

probably we can use '.long' if '.4byte' isn't supported, like

#ifdef __MINGW32__
       .long XXXX
#else
       .4byte XXX
#endif

the code in function 'func' is '.4byte 0', which can be interpreted as
different instructions (even invalid instructions) on different
architectures.  As the result, it causes the fail I mentioned above.  We
can use dwarf assembler to emit debug info for a .c file, so that the
function 'func' always has valid code instructions, including a prologue.
If we use dwarf assembler, we have to teach dwarf assembler to emit
.4byte/.long and .2byte/.short according to the capability of target
gas.  This needs some work too.

-- 
Yao (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]