* [PATCH v2] Rebase executable to match relocated base address [not found] <20200213181430.11259-1-ssbssa.ref@yahoo.de> @ 2020-02-13 18:14 ` Hannes Domani via gdb-patches 2020-02-14 11:02 ` Luis Machado 2020-03-03 5:46 ` Simon Marchi 0 siblings, 2 replies; 7+ messages in thread From: Hannes Domani via gdb-patches @ 2020-02-13 18:14 UTC (permalink / raw) To: gdb-patches Windows executables linked with -dynamicbase get a new base address when loaded, which makes debugging impossible if the executable isn't also rebased in gdb. The new base address is read from the Process Environment Block. --- v2: This version now no longer needs the fake auxv entry. --- gdb/windows-tdep.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c index 6eef3fbd96..29c0a828a7 100644 --- a/gdb/windows-tdep.c +++ b/gdb/windows-tdep.c @@ -34,6 +34,9 @@ #include "solib.h" #include "solib-target.h" #include "gdbcore.h" +#include "coff/internal.h" +#include "libcoff.h" +#include "solist.h" /* Windows signal numbers differ between MinGW flavors and between those and Cygwin. The below enumeration was gleaned from the @@ -812,6 +815,50 @@ windows_get_siginfo_type (struct gdbarch *gdbarch) return siginfo_type; } +/* Implement the "solib_create_inferior_hook" target_so_ops method. */ + +static void +windows_solib_create_inferior_hook (int from_tty) +{ + CORE_ADDR exec_base = 0; + + /* Find base address of main executable in + TIB->process_environment_block->image_base_address. */ + struct gdbarch *gdbarch = target_gdbarch (); + enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); + int ptr_bytes; + int peb_offset; /* Offset of process_environment_block in TIB. */ + int base_offset; /* Offset of image_base_address in PEB. */ + if (gdbarch_ptr_bit (gdbarch) == 32) + { + ptr_bytes = 4; + peb_offset = 48; + base_offset = 8; + } + else + { + ptr_bytes = 8; + peb_offset = 96; + base_offset = 16; + } + CORE_ADDR tlb; + gdb_byte buf[8]; + if (target_get_tib_address (inferior_ptid, &tlb) + && !target_read_memory (tlb + peb_offset, buf, ptr_bytes)) + { + CORE_ADDR peb = extract_unsigned_integer (buf, ptr_bytes, byte_order); + if (!target_read_memory (peb + base_offset, buf, ptr_bytes)) + exec_base = extract_unsigned_integer (buf, ptr_bytes, byte_order); + } + + if (symfile_objfile && exec_base) + { + CORE_ADDR vmaddr = pe_data (exec_bfd)->pe_opthdr.ImageBase; + if (vmaddr != exec_base) + objfile_rebase (symfile_objfile, exec_base - vmaddr); + } +} + /* To be called from the various GDB_OSABI_CYGWIN handlers for the various Windows architectures and machine types. */ @@ -830,6 +877,8 @@ windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch) set_gdbarch_gdb_signal_to_target (gdbarch, windows_gdb_signal_to_target); + solib_target_so_ops.solib_create_inferior_hook + = windows_solib_create_inferior_hook; set_solib_ops (gdbarch, &solib_target_so_ops); set_gdbarch_get_siginfo_type (gdbarch, windows_get_siginfo_type); -- 2.25.0 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] Rebase executable to match relocated base address 2020-02-13 18:14 ` [PATCH v2] Rebase executable to match relocated base address Hannes Domani via gdb-patches @ 2020-02-14 11:02 ` Luis Machado 2020-02-14 12:32 ` Hannes Domani via gdb-patches 2020-03-03 5:46 ` Simon Marchi 1 sibling, 1 reply; 7+ messages in thread From: Luis Machado @ 2020-02-14 11:02 UTC (permalink / raw) To: Hannes Domani, gdb-patches Hi, On 2/13/20 3:14 PM, Hannes Domani via gdb-patches wrote: > Windows executables linked with -dynamicbase get a new base address > when loaded, which makes debugging impossible if the executable isn't > also rebased in gdb. > > The new base address is read from the Process Environment Block. > --- > v2: > This version now no longer needs the fake auxv entry. > --- > gdb/windows-tdep.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 49 insertions(+) > Thanks. This version looks better. > diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c > index 6eef3fbd96..29c0a828a7 100644 > --- a/gdb/windows-tdep.c > +++ b/gdb/windows-tdep.c > @@ -34,6 +34,9 @@ > #include "solib.h" > #include "solib-target.h" > #include "gdbcore.h" > +#include "coff/internal.h" > +#include "libcoff.h" > +#include "solist.h" > > /* Windows signal numbers differ between MinGW flavors and between > those and Cygwin. The below enumeration was gleaned from the > @@ -812,6 +815,50 @@ windows_get_siginfo_type (struct gdbarch *gdbarch) > return siginfo_type; > } > > +/* Implement the "solib_create_inferior_hook" target_so_ops method. */ > + > +static void > +windows_solib_create_inferior_hook (int from_tty) > +{ > + CORE_ADDR exec_base = 0; > + > + /* Find base address of main executable in > + TIB->process_environment_block->image_base_address. */ > + struct gdbarch *gdbarch = target_gdbarch (); > + enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); > + int ptr_bytes; > + int peb_offset; /* Offset of process_environment_block in TIB. */ > + int base_offset; /* Offset of image_base_address in PEB. */ > + if (gdbarch_ptr_bit (gdbarch) == 32) > + { > + ptr_bytes = 4; > + peb_offset = 48; > + base_offset = 8; > + } > + else > + { > + ptr_bytes = 8; > + peb_offset = 96; > + base_offset = 16; > + } How about stashing the above offsets in windows_gdbarch_data, and then using them here? > + CORE_ADDR tlb; > + gdb_byte buf[8]; > + if (target_get_tib_address (inferior_ptid, &tlb) > + && !target_read_memory (tlb + peb_offset, buf, ptr_bytes)) > + { > + CORE_ADDR peb = extract_unsigned_integer (buf, ptr_bytes, byte_order); > + if (!target_read_memory (peb + base_offset, buf, ptr_bytes)) > + exec_base = extract_unsigned_integer (buf, ptr_bytes, byte_order); > + } > + > + if (symfile_objfile && exec_base) > + { > + CORE_ADDR vmaddr = pe_data (exec_bfd)->pe_opthdr.ImageBase; > + if (vmaddr != exec_base) > + objfile_rebase (symfile_objfile, exec_base - vmaddr); > + } I'd add a comment to the above conditional block on why we're doing this relocation now, if you think it is worth mentioning. It seems to me the behavior has changed now, hence why it seems worthwhile adding some information. Otherwise this LGTM. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] Rebase executable to match relocated base address 2020-02-14 11:02 ` Luis Machado @ 2020-02-14 12:32 ` Hannes Domani via gdb-patches 2020-02-14 13:50 ` Luis Machado 0 siblings, 1 reply; 7+ messages in thread From: Hannes Domani via gdb-patches @ 2020-02-14 12:32 UTC (permalink / raw) To: Gdb-patches Am Freitag, 14. Februar 2020, 12:02:03 MEZ hat Luis Machado <luis.machado@linaro.org> Folgendes geschrieben: > Hi, > > On 2/13/20 3:14 PM, Hannes Domani via gdb-patches wrote: > > Windows executables linked with -dynamicbase get a new base address > > when loaded, which makes debugging impossible if the executable isn't > > also rebased in gdb. > > > > The new base address is read from the Process Environment Block. > > --- > > v2: > > This version now no longer needs the fake auxv entry. > > --- > > gdb/windows-tdep.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 49 insertions(+) > > > > Thanks. This version looks better. > > > diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c > > index 6eef3fbd96..29c0a828a7 100644 > > --- a/gdb/windows-tdep.c > > +++ b/gdb/windows-tdep.c > > @@ -34,6 +34,9 @@ > > #include "solib.h" > > #include "solib-target.h" > > #include "gdbcore.h" > > +#include "coff/internal.h" > > +#include "libcoff.h" > > +#include "solist.h" > > > > /* Windows signal numbers differ between MinGW flavors and between > > those and Cygwin. The below enumeration was gleaned from the > > @@ -812,6 +815,50 @@ windows_get_siginfo_type (struct gdbarch *gdbarch) > > return siginfo_type; > > } > > > > +/* Implement the "solib_create_inferior_hook" target_so_ops method. */ > > + > > +static void > > +windows_solib_create_inferior_hook (int from_tty) > > +{ > > + CORE_ADDR exec_base = 0; > > + > > + /* Find base address of main executable in > > + TIB->process_environment_block->image_base_address. */ > + struct gdbarch *gdbarch = target_gdbarch (); > > + enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); > > + int ptr_bytes; > > + int peb_offset; /* Offset of process_environment_block in TIB. */ > > + int base_offset; /* Offset of image_base_address in PEB. */ > > + if (gdbarch_ptr_bit (gdbarch) == 32) > > + { > > + ptr_bytes = 4; > > + peb_offset = 48; > > + base_offset = 8; > > + } > > + else > > + { > > + ptr_bytes = 8; > > + peb_offset = 96; > > + base_offset = 16; > > + } > > How about stashing the above offsets in windows_gdbarch_data, and then > using them here? To be honest, that would seem a bit weird for me, since they are just these simple numbers, and aren't used anywhere else. > > + CORE_ADDR tlb; > > + gdb_byte buf[8]; > > + if (target_get_tib_address (inferior_ptid, &tlb) > > + && !target_read_memory (tlb + peb_offset, buf, ptr_bytes)) > > + { > > + CORE_ADDR peb = extract_unsigned_integer (buf, ptr_bytes, byte_order); > > + if (!target_read_memory (peb + base_offset, buf, ptr_bytes)) > > + exec_base = extract_unsigned_integer (buf, ptr_bytes, byte_order); > > + } > > + > > + if (symfile_objfile && exec_base) > > + { > > + CORE_ADDR vmaddr = pe_data (exec_bfd)->pe_opthdr.ImageBase; > > + if (vmaddr != exec_base) > > + objfile_rebase (symfile_objfile, exec_base - vmaddr); > > > + } > > I'd add a comment to the above conditional block on why we're doing this > relocation now, if you think it is worth mentioning. > > It seems to me the behavior has changed now, hence why it seems > worthwhile adding some information. Something like?: /* Rebase executable if the base address changed because of ASLR. */ Regards Hannes Domani ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] Rebase executable to match relocated base address 2020-02-14 12:32 ` Hannes Domani via gdb-patches @ 2020-02-14 13:50 ` Luis Machado 2020-02-14 14:07 ` Hannes Domani via gdb-patches 0 siblings, 1 reply; 7+ messages in thread From: Luis Machado @ 2020-02-14 13:50 UTC (permalink / raw) To: Hannes Domani, Gdb-patches On 2/14/20 9:32 AM, Hannes Domani via gdb-patches wrote: > Am Freitag, 14. Februar 2020, 12:02:03 MEZ hat Luis Machado <luis.machado@linaro.org> Folgendes geschrieben: > >> Hi, >> >> On 2/13/20 3:14 PM, Hannes Domani via gdb-patches wrote: >>> Windows executables linked with -dynamicbase get a new base address >>> when loaded, which makes debugging impossible if the executable isn't >>> also rebased in gdb. >>> >>> The new base address is read from the Process Environment Block. >>> --- >>> v2: >>> This version now no longer needs the fake auxv entry. >>> --- >>>  gdb/windows-tdep.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++ >>>  1 file changed, 49 insertions(+) >>> >> >> Thanks. This version looks better. >> >>> diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c >>> index 6eef3fbd96..29c0a828a7 100644 >>> --- a/gdb/windows-tdep.c >>> +++ b/gdb/windows-tdep.c >>> @@ -34,6 +34,9 @@ >>>  #include "solib.h" >>>  #include "solib-target.h" >>>  #include "gdbcore.h" >>> +#include "coff/internal.h" >>> +#include "libcoff.h" >>> +#include "solist.h" >>> >>>  /* Windows signal numbers differ between MinGW flavors and between >>>      those and Cygwin. The below enumeration was gleaned from the >>> @@ -812,6 +815,50 @@ windows_get_siginfo_type (struct gdbarch *gdbarch) >>>    return siginfo_type; >>>  } >>> >>> +/* Implement the "solib_create_inferior_hook" target_so_ops method. */ >>> + >>> +static void >>> +windows_solib_create_inferior_hook (int from_tty) >>> +{ >>> + CORE_ADDR exec_base = 0; >>> + >>> + /* Find base address of main executable in >>> +   TIB->process_environment_block->image_base_address. */ > + struct gdbarch *gdbarch = target_gdbarch (); >>> + enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); >>> + int ptr_bytes; >>> + int peb_offset; /* Offset of process_environment_block in TIB. */ >>> + int base_offset; /* Offset of image_base_address in PEB. */ >>> + if (gdbarch_ptr_bit (gdbarch) == 32) >>> +   { >>> +     ptr_bytes = 4; >>> +     peb_offset = 48; >>> +     base_offset = 8; >>> +   } >>> + else >>> +   { >>> +     ptr_bytes = 8; >>> +     peb_offset = 96; >>> +     base_offset = 16; >>> +   } >> >> How about stashing the above offsets in windows_gdbarch_data, and then >> using them here? > > To be honest, that would seem a bit weird for me, since they are just these > simple numbers, and aren't used anywhere else. > > Fair enough. I don't have a strong opinion on this, but i usually try to avoid having these magic numbers in the code without some pointers to where those came from. Folks dealing with this code in the future may try to understand what it is doing and how they came to be. Having them at a single place, with some explanation, helps with that. That's my take on it, at least. >>> + CORE_ADDR tlb; >>> + gdb_byte buf[8]; >>> + if (target_get_tib_address (inferior_ptid, &tlb) >>> +     && !target_read_memory (tlb + peb_offset, buf, ptr_bytes)) >>> +   { >>> +     CORE_ADDR peb = extract_unsigned_integer (buf, ptr_bytes, byte_order); >>> +     if (!target_read_memory (peb + base_offset, buf, ptr_bytes)) >>> +   exec_base = extract_unsigned_integer (buf, ptr_bytes, byte_order); >>> +   } >>> + >>> + if (symfile_objfile && exec_base) >>> +   { >>> +     CORE_ADDR vmaddr = pe_data (exec_bfd)->pe_opthdr.ImageBase; >>> +     if (vmaddr != exec_base) >>> +   objfile_rebase (symfile_objfile, exec_base - vmaddr); >> >>> +   } >> >> I'd add a comment to the above conditional block on why we're doing this >> relocation now, if you think it is worth mentioning. >> >> It seems to me the behavior has changed now, hence why it seems >> worthwhile adding some information. > > Something like?: > /* Rebase executable if the base address changed because of ASLR. */ Sounds good to me. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] Rebase executable to match relocated base address 2020-02-14 13:50 ` Luis Machado @ 2020-02-14 14:07 ` Hannes Domani via gdb-patches 2020-02-14 14:41 ` Luis Machado 0 siblings, 1 reply; 7+ messages in thread From: Hannes Domani via gdb-patches @ 2020-02-14 14:07 UTC (permalink / raw) To: Gdb-patches Am Freitag, 14. Februar 2020, 14:50:07 MEZ hat Luis Machado <luis.machado@linaro.org> Folgendes geschrieben: > On 2/14/20 9:32 AM, Hannes Domani via gdb-patches wrote: > > Am Freitag, 14. Februar 2020, 12:02:03 MEZ hat Luis Machado <luis.machado@linaro.org> Folgendes geschrieben: > > > >> Hi, > >> > >> On 2/13/20 3:14 PM, Hannes Domani via gdb-patches wrote: > >>> Windows executables linked with -dynamicbase get a new base address > >>> when loaded, which makes debugging impossible if the executable isn't > >>> also rebased in gdb. > >>> > >>> The new base address is read from the Process Environment Block. > >>> --- > >>> v2: > >>> This version now no longer needs the fake auxv entry. > >>> --- > >>> gdb/windows-tdep.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++ > >>> 1 file changed, 49 insertions(+) > >>> > >> > >> Thanks. This version looks better. > >> > >>> diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c > >>> index 6eef3fbd96..29c0a828a7 100644 > >>> --- a/gdb/windows-tdep.c > >>> +++ b/gdb/windows-tdep.c > >>> @@ -34,6 +34,9 @@ > >>> #include "solib.h" > >>> #include "solib-target.h" > >>> #include "gdbcore.h" > >>> +#include "coff/internal.h" > >>> +#include "libcoff.h" > >>> +#include "solist.h" > >>> > >>> /* Windows signal numbers differ between MinGW flavors and between > >>> those and Cygwin. The below enumeration was gleaned from the > >>> @@ -812,6 +815,50 @@ windows_get_siginfo_type (struct gdbarch *gdbarch) > >>> return siginfo_type; > >>> } > >>> > >>> +/* Implement the "solib_create_inferior_hook" target_so_ops method. */ > >>> + > >>> +static void > >>> +windows_solib_create_inferior_hook (int from_tty) > >>> +{ > >>> + CORE_ADDR exec_base = 0; > >>> + > >>> + /* Find base address of main executable in > >>> + TIB->process_environment_block->image_base_address. */ > >>> + struct gdbarch *gdbarch = target_gdbarch (); > >>> + enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); > >>> + int ptr_bytes; > >>> + int peb_offset; /* Offset of process_environment_block in TIB. */ > >>> + int base_offset; /* Offset of image_base_address in PEB. */ > >>> + if (gdbarch_ptr_bit (gdbarch) == 32) > >>> + { > >>> + ptr_bytes = 4; > >>> + peb_offset = 48; > >>> + base_offset = 8; > >>> + } > >>> + else > >>> + { > >>> + ptr_bytes = 8; > >>> + peb_offset = 96; > >>> + base_offset = 16; > >>> + } > >> > >> How about stashing the above offsets in windows_gdbarch_data, and then > >> using them here? > > > > To be honest, that would seem a bit weird for me, since they are just these > > simple numbers, and aren't used anywhere else. > > > > > > Fair enough. I don't have a strong opinion on this, but i usually try to > avoid having these magic numbers in the code without some pointers to > where those came from. Folks dealing with this code in the future may > try to understand what it is doing and how they came to be. > > Having them at a single place, with some explanation, helps with that. > That's my take on it, at least. Then I guess I need to make better comments than this: /* Find base address of main executable in TIB->process_environment_block->image_base_address. */ int peb_offset; /* Offset of process_environment_block in TIB. */ int base_offset; /* Offset of image_base_address in PEB. */ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] Rebase executable to match relocated base address 2020-02-14 14:07 ` Hannes Domani via gdb-patches @ 2020-02-14 14:41 ` Luis Machado 0 siblings, 0 replies; 7+ messages in thread From: Luis Machado @ 2020-02-14 14:41 UTC (permalink / raw) To: Hannes Domani, Gdb-patches On 2/14/20 11:07 AM, Hannes Domani via gdb-patches wrote: > Am Freitag, 14. Februar 2020, 14:50:07 MEZ hat Luis Machado <luis.machado@linaro.org> Folgendes geschrieben: > >> On 2/14/20 9:32 AM, Hannes Domani via gdb-patches wrote: >>>  Am Freitag, 14. Februar 2020, 12:02:03 MEZ hat Luis Machado <luis.machado@linaro.org> Folgendes geschrieben: >>> >>>> Hi, >>>> >>>> On 2/13/20 3:14 PM, Hannes Domani via gdb-patches wrote: >>>>> Windows executables linked with -dynamicbase get a new base address >>>>> when loaded, which makes debugging impossible if the executable isn't >>>>> also rebased in gdb. >>>>> >>>>> The new base address is read from the Process Environment Block. >>>>> --- >>>>> v2: >>>>> This version now no longer needs the fake auxv entry. >>>>> --- >>>>>    gdb/windows-tdep.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++ >>>>>    1 file changed, 49 insertions(+) >>>>> >>>> >>>> Thanks. This version looks better. >>>> >>>>> diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c >>>>> index 6eef3fbd96..29c0a828a7 100644 >>>>> --- a/gdb/windows-tdep.c >>>>> +++ b/gdb/windows-tdep.c >>>>> @@ -34,6 +34,9 @@ >>>>>    #include "solib.h". >>>>>    #include "solib-target.h" >>>>>    #include "gdbcore.h" >>>>> +#include "coff/internal.h" >>>>> +#include "libcoff.h" >>>>> +#include "solist.h" >>>>> >>>>>    /* Windows signal numbers differ between MinGW flavors and between >>>>>        those and Cygwin. The below enumeration was gleaned from the >>>>> @@ -812,6 +815,50 @@ windows_get_siginfo_type (struct gdbarch *gdbarch) >>>>>      return siginfo_type; >>>>>    } >>>>> >>>>> +/* Implement the "solib_create_inferior_hook" target_so_ops method. */ >>>>> + >>>>> +static void >>>>> +windows_solib_create_inferior_hook (int from_tty) >>>>> +{ >>>>> + CORE_ADDR exec_base = 0; >>>>> + >>>>> + /* Find base address of main executable in >>>>> +   TIB->process_environment_block->image_base_address. */ >>>>> + struct gdbarch *gdbarch = target_gdbarch (); >>>>> + enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); >>>>> + int ptr_bytes; >>>>> + int peb_offset; /* Offset of process_environment_block in TIB. */ >>>>> + int base_offset; /* Offset of image_base_address in PEB. */ >>>>> + if (gdbarch_ptr_bit (gdbarch) == 32) >>>>> +   { >>>>> +     ptr_bytes = 4; >>>>> +     peb_offset = 48; >>>>> +     base_offset = 8; >>>>> +   } >>>>> + else >>>>> +   { >>>>> +     ptr_bytes = 8; >>>>> +     peb_offset = 96; >>>>> +     base_offset = 16; >>>>> +   } >>>> >>>> How about stashing the above offsets in windows_gdbarch_data, and then >>>> using them here? >>> >>> To be honest, that would seem a bit weird for me, since they are just these >>> simple numbers, and aren't used anywhere else. >>> >>> >> >> Fair enough. I don't have a strong opinion on this, but i usually try to >> avoid having these magic numbers in the code without some pointers to >> where those came from. Folks dealing with this code in the future may >> try to understand what it is doing and how they came to be. >> >> Having them at a single place, with some explanation, helps with that. >> That's my take on it, at least. > > Then I guess I need to make better comments than this: >  /* Find base address of main executable in >     TIB->process_environment_block->image_base_address. */ > >  int peb_offset; /* Offset of process_environment_block in TIB. */ >  int base_offset; /* Offset of image_base_address in PEB. */ The comments are fine. It's just the location of those, in local variables in a particular function, that seemed to me could be improved. But like i said, I'm fine keeping it this way if it is deemed appropriate for the windows target. I have no further comments on the patch. I'll defer to the maintainers for approvals. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v2] Rebase executable to match relocated base address 2020-02-13 18:14 ` [PATCH v2] Rebase executable to match relocated base address Hannes Domani via gdb-patches 2020-02-14 11:02 ` Luis Machado @ 2020-03-03 5:46 ` Simon Marchi 1 sibling, 0 replies; 7+ messages in thread From: Simon Marchi @ 2020-03-03 5:46 UTC (permalink / raw) To: Hannes Domani, gdb-patches On 2020-02-13 1:14 p.m., Hannes Domani via gdb-patches wrote: > Windows executables linked with -dynamicbase get a new base address > when loaded, which makes debugging impossible if the executable isn't > also rebased in gdb. > > The new base address is read from the Process Environment Block. > --- > v2: > This version now no longer needs the fake auxv entry. Thanks, hopefully that way of finding the base address is sufficient for what you need. I like it, it's much more self-contained. > --- > gdb/windows-tdep.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 49 insertions(+) > > diff --git a/gdb/windows-tdep.c b/gdb/windows-tdep.c > index 6eef3fbd96..29c0a828a7 100644 > --- a/gdb/windows-tdep.c > +++ b/gdb/windows-tdep.c > @@ -34,6 +34,9 @@ > #include "solib.h" > #include "solib-target.h" > #include "gdbcore.h" > +#include "coff/internal.h" > +#include "libcoff.h" > +#include "solist.h" > > /* Windows signal numbers differ between MinGW flavors and between > those and Cygwin. The below enumeration was gleaned from the > @@ -812,6 +815,50 @@ windows_get_siginfo_type (struct gdbarch *gdbarch) > return siginfo_type; > } > > +/* Implement the "solib_create_inferior_hook" target_so_ops method. */ > + > +static void > +windows_solib_create_inferior_hook (int from_tty) > +{ > + CORE_ADDR exec_base = 0; > + > + /* Find base address of main executable in > + TIB->process_environment_block->image_base_address. */ > + struct gdbarch *gdbarch = target_gdbarch (); > + enum bfd_endian byte_order = gdbarch_byte_order (gdbarch); > + int ptr_bytes; > + int peb_offset; /* Offset of process_environment_block in TIB. */ > + int base_offset; /* Offset of image_base_address in PEB. */ > + if (gdbarch_ptr_bit (gdbarch) == 32) > + { > + ptr_bytes = 4; > + peb_offset = 48; > + base_offset = 8; > + } > + else > + { > + ptr_bytes = 8; > + peb_offset = 96; > + base_offset = 16; > + } > + CORE_ADDR tlb; > + gdb_byte buf[8]; > + if (target_get_tib_address (inferior_ptid, &tlb) > + && !target_read_memory (tlb + peb_offset, buf, ptr_bytes)) > + { > + CORE_ADDR peb = extract_unsigned_integer (buf, ptr_bytes, byte_order); > + if (!target_read_memory (peb + base_offset, buf, ptr_bytes)) > + exec_base = extract_unsigned_integer (buf, ptr_bytes, byte_order); > + } > + > + if (symfile_objfile && exec_base) Use explicit comparison operators when comparing pointers and integers (except those that are really meant to represent boolean values and haven't been converted to `bool` yet). So, if (symfile_objfile != nullptr && exec_base != 0) > + { > + CORE_ADDR vmaddr = pe_data (exec_bfd)->pe_opthdr.ImageBase; > + if (vmaddr != exec_base) > + objfile_rebase (symfile_objfile, exec_base - vmaddr); > + } > +} > + > /* To be called from the various GDB_OSABI_CYGWIN handlers for the > various Windows architectures and machine types. */ > > @@ -830,6 +877,8 @@ windows_init_abi (struct gdbarch_info info, struct gdbarch *gdbarch) > > set_gdbarch_gdb_signal_to_target (gdbarch, windows_gdb_signal_to_target); > > + solib_target_so_ops.solib_create_inferior_hook > + = windows_solib_create_inferior_hook; I don't think this bit is right. Some other architecture/target could be using solib_target_so_ops, and you force that solib_create_inferior_hook value for them too. I mean, it won't matter for you in practice when debugging a single process on Windows, but still let's do it right. Ideally, all this would be a C++ class hierarchy and you would extend the solib_target_so_ops class to implement the solib_create_inferior_hook method. But here, we have a structure with function pointers, so you need to copy solib_target_so_ops into a windows-specific version, and assign the solib_create_inferior_hook pointer in that one. Check how mips_linux_init_abi does it, it's not very complicated. Simon ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-03-03 5:46 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20200213181430.11259-1-ssbssa.ref@yahoo.de> 2020-02-13 18:14 ` [PATCH v2] Rebase executable to match relocated base address Hannes Domani via gdb-patches 2020-02-14 11:02 ` Luis Machado 2020-02-14 12:32 ` Hannes Domani via gdb-patches 2020-02-14 13:50 ` Luis Machado 2020-02-14 14:07 ` Hannes Domani via gdb-patches 2020-02-14 14:41 ` Luis Machado 2020-03-03 5:46 ` Simon Marchi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).