From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19057 invoked by alias); 7 Jan 2003 13:11:47 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 19018 invoked from network); 7 Jan 2003 13:11:44 -0000 Received: from unknown (HELO main.gmane.org) (80.91.224.249) by 209.249.29.67 with SMTP; 7 Jan 2003 13:11:44 -0000 Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18VtUy-0005rG-00 for ; Tue, 07 Jan 2003 14:10:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gdb-patches@sources.redhat.com Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 18VtUx-0005r5-00 for ; Tue, 07 Jan 2003 14:10:27 +0100 Path: not-for-mail From: "Raoul Gough" Subject: Re: coffread.c extension for DLLs without debugging symbols Date: Tue, 07 Jan 2003 13:11:00 -0000 Message-ID: References: <20030104044408.GA7364@redhat.com> <20030104205130.GA9784@redhat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004C_01C2B64E.32B34930" X-Complaints-To: usenet@main.gmane.org X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-SW-Source: 2003-01/txt/msg00270.txt.bz2 This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C2B64E.32B34930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-length: 1702 "Christopher Faylor" wrote in message news:20030104205130.GA9784@redhat.com... > On Sat, Jan 04, 2003 at 04:25:16PM -0000, Raoul Gough wrote: > >"Christopher Faylor" wrote in message > >news:20030104044408.GA7364@redhat.com... > >> P.S. Assuming that this works as advertised, I assume that you will > >> have no objections to my releasing a new version of gdb for windows > >> with this patch in it before the patch makes its way into the official > >> gdb repository, right? I think there are a few users in the cygwin > >> mailing list that would appreciate this change. > > > >By all means - please do. You may as well use the new diff for the > >comment fixes and the strncmp business. > > Ok. Coming soon to a cygwin mirror near you. Chris, I've done some more testing and discovered a problem with the virtual memory address determination mechanism. I've been using bfd_get_section_vma to find out where each section is in memory, but this is not always correct. BFD returns the DLL's *preferred* load address, but it may actually have been relocated during loading because of address space clashes. It seems obvious now, but BFD is not the right place to get the needed information. I'm looking into the win32-nat code that handles DLL load events, which *does* know about the real load address. Unfortunately, this really will make the code win32 specific. Unless someone else can suggest anything better? Actually, this seems like a generic bug in GDB's DLL handling - by compiling with debugging symbols, the problem is even visible without my patch. Have a look at the attached example, which shows GDB 5.2.1 getting it wrong. Regards, Raoul Gough. ------=_NextPart_000_004C_01C2B64E.32B34930 Content-Type: text/plain; name="example2.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="example2.txt" Content-length: 2894 $ cat dlleg.c __attribute((__dllexport__)) void fn () { } __attribute((__dllexport__)) char hello[] =3D "Hello world"; __attribute((__dllexport__)) int init_data =3D 42; __attribute((__dllexport__)) int uninit_data; $ cat dlleg2.c __attribute((__dllexport__)) void fn2 () { } __attribute((__dllexport__)) char hello2[] =3D "Hello again"; __attribute((__dllexport__)) int init_data2 =3D 44; __attribute((__dllexport__)) int uninit_data2; $ cat dllegmain.c __attribute((__dllimport__)) void fn (); __attribute((__dllimport__)) char hello[]; __attribute((__dllimport__)) int init_data; __attribute((__dllimport__)) int uninit_data; __attribute((__dllimport__)) void fn2 (); __attribute((__dllimport__)) char hello2[]; __attribute((__dllimport__)) int init_data2; __attribute((__dllimport__)) int uninit_data2; int main () { fn(); uninit_data =3D init_data; fn2(); uninit_data2 =3D init_data2; return 0; } $ gcc -g -c dlleg.c $ gcc -g -c dlleg2.c $ gcc -g -c dllegmain.c $ # $ # Note - by omitting the --enable-auto-image-base linker flag, both $ # DLLs get the same load address by default (0x1000000). At load $ # time, one of them gets relocated $ # $ gcc -shared -o dlleg.dll dlleg.o $ gcc -shared -o dlleg2.dll dlleg2.o $ gcc -o dllegmain dllegmain.o dlleg.dll dlleg2.dll $ gdb dllegmain GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "mingw32"... (gdb) break main Breakpoint 1 at 0x401050: file dllegmain.c, line 13. (gdb) run Starting program: f:\Users\Raoul\gdb/dllegmain.exe=20 Breakpoint 1, main () at dllegmain.c:13 13 fn(); (gdb) x/s &hello 0x10002000 : "Hello again" (gdb) # (gdb) # Uh oh. The symbol "hello" should point to the string (gdb) # "Hello world", and hello2 should be "Hello again" (gdb) # (see dlleg.c and dlleg2.c above) (gdb) # (gdb) x/s &hello2 0x10002000 : "Hello again" (gdb) # (gdb) # win32-nat.c knows the real load addresses: (gdb) # (gdb) info dll DLL Name Load Address F:\cygwin\bin\cygwin1.dll 61001000 F:\WINNT\system32\kernel32.dll 77e81000 f:\Users\Raoul\gdb\dlleg2.dll 10001000 f:\Users\Raoul\gdb\dlleg.dll 00331000 F:\WINNT\system32\advapi32.dll 77db1000 F:\WINNT\system32\rpcrt4.dll 77d41000 F:\WINNT\system32\user32.dll 77e11000 F:\WINNT\system32\gdi32.dll 77f41000 (gdb) # (gdb) # Using this information, we can find the other string (gdb) # manually. dlleg2.dll got loaded at it's preferred (gdb) # address, but dlleg.dll was relocated. (gdb) # (gdb) x/s 0x332000 0x332000: "Hello world" (gdb) quit The program is running. Exit anyway? (y or n) y $=20= ------=_NextPart_000_004C_01C2B64E.32B34930--