This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC-v5] Fix .text section offset for windows DLL (was Calling __stdcall functions in the inferior)
- From: asmwarrior <asmwarrior at gmail dot com>
- Cc: Pierre Muller <pierre dot muller at ics-cnrs dot unistra dot fr>, 'Joel Brobecker' <brobecker at adacore dot com>, 'Eli Zaretskii' <eliz at gnu dot org>, gdb-patches at sourceware dot org
- Date: Sat, 08 Dec 2012 23:09:20 +0800
- Subject: Re: [RFC-v5] Fix .text section offset for windows DLL (was Calling __stdcall functions in the inferior)
- References: <20121024194517.GK3555@adacore.com> <011901cdb2ab$48076b90$d81642b0$@muller@ics-cnrs.unistra.fr> <20121105171121.GA2972@adacore.com> <50991f5f.8382440a.1100.ffff82abSMTPIN_ADDED@mx.google.com> <509ABA17.30507@redhat.com> <000301cdbd96$f5cd9f10$e168dd30$@muller@ics-cnrs.unistra.fr> <20121122173019.GF9964@adacore.com> <15690.5992342674$1353883881@news.gmane.org> <87624si9ur.fsf@fleche.redhat.com> <001501cdccaf$ad85e9b0$0891bd10$@muller@ics-cnrs.unistra.fr> <20121207071035.GG31477@adacore.com> <50C20A66.70002@gmail.com> <29545.4593528577$1354894901@news.gmane.org> <50C21696.7040006@gmail.com> <50c218e5.2850b40a.0281.ffffbef4SMTPIN_ADDED_BROKEN@mx.google.com> <50C34C75.3050803@gmail.com>
On 2012-12-8 22:19, asmwarrior wrote:
(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?
Also, see the frame 4's info:
(gdb) frame 4
#4 0x00563d2c in read_pe_exported_syms (objfile=0x5615090)
at ../../gdb/gdb/coff-pe-read.c:525
525 bfd_map_over_sections (dll, get_section_vmas, &pe_sections_info);
(gdb) p dll
$7 = (bfd *) 0x4caede8
(gdb) p *dll
$8 = {id = 49, filename = 0x5548238 "C:\\WINDOWS\\system32\\ntdll.dll",
xvec = 0x84a380 <i386pei_vec>, iostream = 0x77c5fda0 <msvcrt!_iob+288>,
iovec = 0x837480 <cache_iovec>, lru_prev = 0x4b66da8, lru_next = 0x4b02950,
where = 49758, mtime = 1291907709, ifd = 0, format = bfd_object,
direction = read_direction, flags = 65803, origin = 0, proxy_origin = 0,
section_htab = {table = 0x5549230,
newfunc = 0x64def8 <bfd_section_hash_newfunc>, memory = 0x54b0f40,
size = 251, count = 4, entsize = 184, frozen = 0}, sections = 0x5549630,
section_last = 0x5549858, section_count = 4, start_address = 2089885944,
symcount = 0, outsymbols = 0x0, dynsymcount = 0,
arch_info = 0x837700 <bfd_i386_arch>, arelt_data = 0x0, my_archive = 0x0,
archive_next = 0x0, archive_head = 0x0, nested_archives = 0x0,
link_next = 0x0, archive_pass = 0, tdata = {aout_data = 0x5548278,
aout_ar_data = 0x5548278, oasys_obj_data = 0x5548278,
oasys_ar_data = 0x5548278, coff_obj_data = 0x5548278,
pe_obj_data = 0x5548278, xcoff_obj_data = 0x5548278,
ecoff_obj_data = 0x5548278, ieee_data = 0x5548278,
ieee_ar_data = 0x5548278, srec_data = 0x5548278,
verilog_data = 0x5548278, ihex_data = 0x5548278, tekhex_data = 0x5548278,
elf_obj_data = 0x5548278, nlm_obj_data = 0x5548278,
bout_data = 0x5548278, mmo_data = 0x5548278, sun_core_data = 0x5548278,
sco5_core_data = 0x5548278, trad_core_data = 0x5548278,
som_data = 0x5548278, hpux_core_data = 0x5548278,
hppabsd_core_data = 0x5548278, sgi_core_data = 0x5548278,
lynx_core_data = 0x5548278, osf_core_data = 0x5548278,
cisco_core_data = 0x5548278, versados_data = 0x5548278,
netbsd_core_data = 0x5548278, mach_o_data = 0x5548278,
mach_o_fat_data = 0x5548278, plugin_data = 0x5548278,
pef_data = 0x5548278, pef_xlib_data = 0x5548278, sym_data = 0x5548278,
any = 0x5548278}, usrdata = 0x5548258, memory = 0x54b0df8, cacheable = 1,
target_defaulted = 1, opened_once = 1, mtime_set = 0, no_export = 0,
output_has_begun = 0, has_armap = 0, is_thin_archive = 0,
selective_search = 0}
(gdb)
So, it crashed on reading the ntdll.dll?