RE: [RFC-v5] Fix .text section offset for windows DLL (was Calling __stdcall functions in the inferior)

["Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>]

  Hi Yuanhui,

thanks again for trying to debug that problem...

> -----Message d'origine-----
> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de asmwarrior
> Envoyà : samedi 8 dÃcembre 2012 15:20
> Ã : Pierre Muller
> Cc : 'Joel Brobecker'; 'Eli Zaretskii'; gdb-patches@sourceware.org
> Objet : Re: [RFC-v5] Fix .text section offset for windows DLL (was Calling
> __stdcall functions in the inferior)
> 
> On 2012-12-8 0:27, Pierre Muller wrote:
> >
> >> -----Message d'origine-----
> >> De : gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> >> owner@sourceware.org] De la part de asmwarrior
> >> Envoyà : vendredi 7 dÃcembre 2012 17:17
> >> Ã : Pierre Muller
> >> Cc : 'Joel Brobecker'; 'Eli Zaretskii'; gdb-patches@sourceware.org
> >> Objet : Re: [RFC-v5] Fix .text section offset for windows DLL (was
> Calling
> >> __stdcall functions in the inferior)
> >>
> >> On 2012-12-7 23:40, Pierre Muller wrote:
> >>>     Hi Yuanhui,
> >>> thanks for trying to debug this...
> >>>
> >>>     First, concerning the optimized out problems,
> >>> it would be easier if you would recompile
> >>> GDB without optimization:
> >>>
> >>> make clean all CFLAGS="-gdwarf-2 -O0"
> >>>
> >>> After that, you should get optimized out variables...
> >> I will did this if I have more time.
> >>
> >>
> >>>     I also installed CodeBlocks to test if I can reproduce your crash,
> >>> but I never got any ...
> >> The codeblocks.exe was built myself, which has debug information in it.
> >   I tried to recompile the sources, but
> > compilation fails on not found wxWorks headers...
> > Despite the fact that I compiled wxWorks 2.9.4 without problems.
> Note: Codeblocks currently can build against wxWidgets 2.8.12 library. I
> think it was not stable to build against wxWidgets 2.9.x.
 Thanks for the information.
 
> >>>     Could it be that some weird DLL's have unnamed
> >>> sections?
> >>>     Could you try to insert
> >>>       if (sections[i] && section[i].name)
> >>> before
> >>>>        if (strcmp (sections[i].section_name, section_name) == 0)
> >>>>          return i;
> >>> to confirm that the problem originates here?
> >>>
> >> I add a line:
> >> static int
> >> get_pe_section_index (const char *section_name,
> >> 		      struct read_pe_section_data *sections,
> >> 		      int nb_sections)
> >> {
> >>     int i;
> >>     for (i = 0; i < nb_sections; i++)
> >>       if (section_name && (&sections[i]) && sections[i].section_name)
> >>       if (strcmp (sections[i].section_name, section_name) == 0)
> >>         return i;
> >>     return PE_SECTION_INDEX_INVALID;
> >> }
> >>
> >>
> >> But still the same crash in strcmp().
> >    Could you try to check that section_name ansd sections array are
> valid...
> > It will probably require that you recompile GDB :(
> Hi, today, I build gdb with "-O0 -g", here is the variables I see when it
> crashed.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x77c47784 in strcmp () from C:\WINDOWS\system32\msvcrt.dll
> (gdb) bt
> #0  0x77c47784 in strcmp () from C:\WINDOWS\system32\msvcrt.dll
> #1  0x00562eb9 in get_pe_section_index (section_name=0x5548638 ".data",
>      sections=0x4b33b38, nb_sections=5) at ../../gdb/gdb/coff-pe-read.c:113
> #2  0x00562f08 in get_section_vmas (abfd=0x4caede8, sectp=0x55496e8,
>      context=0x285f5ec) at ../../gdb/gdb/coff-pe-read.c:134
> #3  0x0064e7ee in bfd_map_over_sections (abfd=0x4caede8,
>      operation=0x562ed5 <get_section_vmas>, user_storage=0x285f5ec)
>      at ../../gdb/bfd/section.c:1329
> #4  0x00563d2c in read_pe_exported_syms (objfile=0x5615090)
>      at ../../gdb/gdb/coff-pe-read.c:525
> #5  0x00560887 in coff_symtab_read (symtab_offset=0, nsyms=0,
>      objfile=0x5615090) at ../../gdb/gdb/coffread.c:1127
> #6  0x0055f660 in coff_symfile_read (objfile=0x5615090, symfile_flags=8)
>      at ../../gdb/gdb/coffread.c:610
> #7  0x004f1cc4 in read_symbols (objfile=0x5615090, add_flags=8)
>      at ../../gdb/gdb/symfile.c:885
> #8  0x004f203b in syms_from_objfile (objfile=0x5615090, addrs=0x2e04398,
>      offsets=0x0, num_offsets=0, add_flags=8) at
> ../../gdb/gdb/symfile.c:1020
> #9  0x004f2206 in symbol_file_add_with_addrs_or_offsets (abfd=0x4caede8,
>      add_flags=8, addrs=0x2e04398, offsets=0x0, num_offsets=0, flags=2,
>      parent=0x0) at ../../gdb/gdb/symfile.c:1123
> #10 0x004f23bf in symbol_file_add_from_bfd (abfd=0x4caede8, add_flags=8,
>      addrs=0x2e04398, flags=2, parent=0x0) at ../../gdb/gdb/symfile.c:1213
> #11 0x0060ef33 in solib_read_symbols (so=0x4bdb6b0, flags=8)
>      at ../../gdb/gdb/solib.c:608
> #12 0x0060f50d in solib_add (pattern=0x0, from_tty=0,
>      target=0x9ec6c0 <current_target>, readsyms=1) at
> ../../gdb/gdb/solib.c:919
> #13 0x0050146f in post_create_inferior (target=0x9ec6c0 <current_target>,
>      from_tty=0) at ../../gdb/gdb/infcmd.c:477
> #14 0x0050175b in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=0)
>      at ../../gdb/gdb/infcmd.c:631
> #15 0x005017b0 in run_command (args=0x0, from_tty=1)
>      at ../../gdb/gdb/infcmd.c:645
> #16 0x00447794 in do_cfunc (c=0x2d65ed0, args=0x0, from_tty=1)
>      at ../../gdb/gdb/cli/cli-decode.c:114
> #17 0x0044a0ce in cmd_func (cmd=0x2d65ed0, args=0x0, from_tty=1)
>      at ../../gdb/gdb/cli/cli-decode.c:1859
> #18 0x005f6ebf in execute_command (p=0x294321 "", from_tty=1)
>      at ../../gdb/gdb/top.c:491
> #19 0x00524cda in command_handler (command=0x294320 "")
>      at ../../gdb/gdb/event-top.c:429
> #20 0x0052524e in command_line_handler (rl=0x2e29fe0 "r")
>      at ../../gdb/gdb/event-top.c:630
> #21 0x00630133 in rl_callback_read_char ()
>      at ../../gdb/readline/callback.c:220
> #22 0x0052481f in rl_callback_read_char_wrapper (client_data=0x0)
>      at ../../gdb/gdb/event-top.c:163
> #23 0x00524c04 in stdin_event_handler (error=0, client_data=0x0)
>      at ../../gdb/gdb/event-top.c:369
> #24 0x00523df9 in handle_file_event (data=...)
>      at ../../gdb/gdb/event-loop.c:827
> #25 0x0052353d in process_event () at ../../gdb/gdb/event-loop.c:401
> #26 0x00523602 in gdb_do_one_event () at ../../gdb/gdb/event-loop.c:465
> #27 0x00523654 in start_event_loop () at ../../gdb/gdb/event-loop.c:490
> #28 0x00524848 in cli_command_loop () at ../../gdb/gdb/event-top.c:176
> #29 0x0051cdcf in current_interp_command_loop ()
>      at ../../gdb/gdb/interps.c:332
> #30 0x0051d6e9 in captured_command_loop (data=0x0) at
> ../../gdb/gdb/main.c:256
> #31 0x0051be8c in catch_errors (func=0x51d6d4 <captured_command_loop>,
>      func_args=0x0, errstring=0x7af593 <__PRETTY_FUNCTION__.13689+121> "",
>      mask=6) at ../../gdb/gdb/exceptions.c:546
> #32 0x0051e8c7 in captured_main (data=0x285fee0) at
> ../../gdb/gdb/main.c:1032
> #33 0x0051be8c in catch_errors (func=0x51d923 <captured_main>,
>     func_args=0x285fee0,
>      errstring=0x7af593 <__PRETTY_FUNCTION__.13689+121> "", mask=6)
>      at ../../gdb/gdb/exceptions.c:546
> #34 0x0051e8fd in gdb_main (args=0x285fee0) at ../../gdb/gdb/main.c:1041
> #35 0x00401737 in main (argc=1, argv=0x293ea0) at ../../gdb/gdb/gdb.c:34
> (gdb) frame 1
> #1  0x00562eb9 in get_pe_section_index (section_name=0x5548638 ".data",
>      sections=0x4b33b38, nb_sections=5) at ../../gdb/gdb/coff-pe-read.c:113
> 113         if (strcmp (sections[i].section_name, section_name) == 0)
> (gdb) p section_name
> $1 = 0x5548638 ".data"
> (gdb) p i
> $2 = 2
> (gdb) p sections[i].section_name
> $3 = 0xabababab <Address 0xabababab out of bounds>
> (gdb) print *sections@nb_sections
> $4 = {{vma_offset = 2089811968, rva_start = 4096, rva_end = 515802,
>      ms_type = mst_text, section_name = 0x7cd4a0 <coff_sym_fns+64> ".text"},
> {
>      vma_offset = 2868903936, rva_start = 2880154539, rva_end = 2880154539,
>      ms_type = mst_unknown, section_name = 0x0}, {vma_offset = 393221,
>      rva_start = 35784515, rva_end = 1920168494, ms_type = 2880110691,
>      section_name = 0xabababab <Address 0xabababab out of bounds>}, {
>      vma_offset = 0, rva_start = 536576, rva_end = 716408, ms_type =
> mst_data,
>      section_name = 0x4b33b68 ".rsrc"}, {vma_offset = 0, rva_start = 716800,
>      rva_end = 728800, ms_type = mst_data, section_name = 0x4b33be0
> ".reloc"}}
> 
> 
> 
> Look, the value "0xabababab", I'm not sure why gdb report: out of bounds,
> where does this value come from?
  This memory corruption is rather odd...
it seems that the rva_end of index=2 seems to contains the same data
as the section_name for index 4...
  This array is really created only inside read_pe_exported_syms
so that it would be worth trying to add a breakpoint at that function,
and step over it for ntdll.dll to understand when the data gets corrupted...

  Would it be possible for you to upload the codeblocks executable that triggers
the problem somewhere so I could
check if I get the same errors and debug further?

  I have no idea what is going on...


Pierre Muller