public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] Handle TLS variable lookups when using separate debug files.
@ 2022-04-01 22:17 John Baldwin
  2022-04-04 14:38 ` Tom Tromey
  2022-04-04 22:15 ` John Baldwin
  0 siblings, 2 replies; 4+ messages in thread
From: John Baldwin @ 2022-04-01 22:17 UTC (permalink / raw)
  To: gdb-patches

Commit df22c1e5d53c38f38bce6072bb46de240f9e0e2b handled the case that
a separate debug file was passed as the objfile for a shared library
to svr4_fetch_objfile_link_map.  However, a separate debug file can
also be passed for TLS variables in the main executable.  In addition,
frv_fetch_objfile_link_map also expects to be passed the original
objfile rather than a separate debug file, so pull the code to resolve
a separate debug file to the main objfile up into
target_translate_tls_address.
---
 gdb/solib-svr4.c | 5 -----
 gdb/target.c     | 5 +++++
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index 2624ec286a0..ca98a812f36 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -1453,11 +1453,6 @@ svr4_fetch_objfile_link_map (struct objfile *objfile)
   if (objfile == current_program_space->symfile_object_file)
     return info->main_lm_addr;
 
-  /* If OBJFILE is a separate debug object file, look for the
-     original object file.  */
-  if (objfile->separate_debug_objfile_backlink != NULL)
-    objfile = objfile->separate_debug_objfile_backlink;
-
   /* The other link map addresses may be found by examining the list
      of shared libraries.  */
   for (struct so_list *so : current_program_space->solibs ())
diff --git a/gdb/target.c b/gdb/target.c
index 928f5583a30..f33bf345cfa 100644
--- a/gdb/target.c
+++ b/gdb/target.c
@@ -1296,6 +1296,11 @@ target_translate_tls_address (struct objfile *objfile, CORE_ADDR offset)
   struct target_ops *target = current_inferior ()->top_target ();
   struct gdbarch *gdbarch = target_gdbarch ();
 
+  /* If OBJFILE is a separate debug object file, look for the
+     original object file.  */
+  if (objfile->separate_debug_objfile_backlink != NULL)
+    objfile = objfile->separate_debug_objfile_backlink;
+
   if (gdbarch_fetch_tls_load_module_address_p (gdbarch))
     {
       ptid_t ptid = inferior_ptid;
-- 
2.34.1


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Handle TLS variable lookups when using separate debug files.
  2022-04-01 22:17 [PATCH] Handle TLS variable lookups when using separate debug files John Baldwin
@ 2022-04-04 14:38 ` Tom Tromey
  2022-04-04 22:15 ` John Baldwin
  1 sibling, 0 replies; 4+ messages in thread
From: Tom Tromey @ 2022-04-04 14:38 UTC (permalink / raw)
  To: John Baldwin; +Cc: gdb-patches

>>>>> "John" == John Baldwin <jhb@FreeBSD.org> writes:

John> Commit df22c1e5d53c38f38bce6072bb46de240f9e0e2b handled the case that
John> a separate debug file was passed as the objfile for a shared library
John> to svr4_fetch_objfile_link_map.  However, a separate debug file can
John> also be passed for TLS variables in the main executable.  In addition,
John> frv_fetch_objfile_link_map also expects to be passed the original
John> objfile rather than a separate debug file, so pull the code to resolve
John> a separate debug file to the main objfile up into
John> target_translate_tls_address.

Looks good to me.  Thank you.

Tom

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Handle TLS variable lookups when using separate debug files.
  2022-04-01 22:17 [PATCH] Handle TLS variable lookups when using separate debug files John Baldwin
  2022-04-04 14:38 ` Tom Tromey
@ 2022-04-04 22:15 ` John Baldwin
  2022-04-10 19:22   ` Joel Brobecker
  1 sibling, 1 reply; 4+ messages in thread
From: John Baldwin @ 2022-04-04 22:15 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

On 4/1/22 3:17 PM, John Baldwin wrote:
> Commit df22c1e5d53c38f38bce6072bb46de240f9e0e2b handled the case that
> a separate debug file was passed as the objfile for a shared library
> to svr4_fetch_objfile_link_map.  However, a separate debug file can
> also be passed for TLS variables in the main executable.  In addition,
> frv_fetch_objfile_link_map also expects to be passed the original
> objfile rather than a separate debug file, so pull the code to resolve
> a separate debug file to the main objfile up into
> target_translate_tls_address.

Is this ok to merge to the gdb-12-branch?  This patch fixes a regression
present in both GDB 10 (I think) and GDB 11 (I've verified this).  I have
not opened a PR for the regression.

> ---
>   gdb/solib-svr4.c | 5 -----
>   gdb/target.c     | 5 +++++
>   2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
> index 2624ec286a0..ca98a812f36 100644
> --- a/gdb/solib-svr4.c
> +++ b/gdb/solib-svr4.c
> @@ -1453,11 +1453,6 @@ svr4_fetch_objfile_link_map (struct objfile *objfile)
>     if (objfile == current_program_space->symfile_object_file)
>       return info->main_lm_addr;
>   
> -  /* If OBJFILE is a separate debug object file, look for the
> -     original object file.  */
> -  if (objfile->separate_debug_objfile_backlink != NULL)
> -    objfile = objfile->separate_debug_objfile_backlink;
> -
>     /* The other link map addresses may be found by examining the list
>        of shared libraries.  */
>     for (struct so_list *so : current_program_space->solibs ())
> diff --git a/gdb/target.c b/gdb/target.c
> index 928f5583a30..f33bf345cfa 100644
> --- a/gdb/target.c
> +++ b/gdb/target.c
> @@ -1296,6 +1296,11 @@ target_translate_tls_address (struct objfile *objfile, CORE_ADDR offset)
>     struct target_ops *target = current_inferior ()->top_target ();
>     struct gdbarch *gdbarch = target_gdbarch ();
>   
> +  /* If OBJFILE is a separate debug object file, look for the
> +     original object file.  */
> +  if (objfile->separate_debug_objfile_backlink != NULL)
> +    objfile = objfile->separate_debug_objfile_backlink;
> +
>     if (gdbarch_fetch_tls_load_module_address_p (gdbarch))
>       {
>         ptid_t ptid = inferior_ptid;


-- 
John Baldwin

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Handle TLS variable lookups when using separate debug files.
  2022-04-04 22:15 ` John Baldwin
@ 2022-04-10 19:22   ` Joel Brobecker
  0 siblings, 0 replies; 4+ messages in thread
From: Joel Brobecker @ 2022-04-10 19:22 UTC (permalink / raw)
  To: John Baldwin; +Cc: Joel Brobecker, gdb-patches

> > Commit df22c1e5d53c38f38bce6072bb46de240f9e0e2b handled the case that
> > a separate debug file was passed as the objfile for a shared library
> > to svr4_fetch_objfile_link_map.  However, a separate debug file can
> > also be passed for TLS variables in the main executable.  In addition,
> > frv_fetch_objfile_link_map also expects to be passed the original
> > objfile rather than a separate debug file, so pull the code to resolve
> > a separate debug file to the main objfile up into
> > target_translate_tls_address.
> 
> Is this ok to merge to the gdb-12-branch?  This patch fixes a regression
> present in both GDB 10 (I think) and GDB 11 (I've verified this).  I have
> not opened a PR for the regression.

OK to backport, John.

For the .1, no need for a PR, so we're OK (we'll start needing one
for the .2 release).

> > ---
> >   gdb/solib-svr4.c | 5 -----
> >   gdb/target.c     | 5 +++++
> >   2 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
> > index 2624ec286a0..ca98a812f36 100644
> > --- a/gdb/solib-svr4.c
> > +++ b/gdb/solib-svr4.c
> > @@ -1453,11 +1453,6 @@ svr4_fetch_objfile_link_map (struct objfile *objfile)
> >     if (objfile == current_program_space->symfile_object_file)
> >       return info->main_lm_addr;
> > -  /* If OBJFILE is a separate debug object file, look for the
> > -     original object file.  */
> > -  if (objfile->separate_debug_objfile_backlink != NULL)
> > -    objfile = objfile->separate_debug_objfile_backlink;
> > -
> >     /* The other link map addresses may be found by examining the list
> >        of shared libraries.  */
> >     for (struct so_list *so : current_program_space->solibs ())
> > diff --git a/gdb/target.c b/gdb/target.c
> > index 928f5583a30..f33bf345cfa 100644
> > --- a/gdb/target.c
> > +++ b/gdb/target.c
> > @@ -1296,6 +1296,11 @@ target_translate_tls_address (struct objfile *objfile, CORE_ADDR offset)
> >     struct target_ops *target = current_inferior ()->top_target ();
> >     struct gdbarch *gdbarch = target_gdbarch ();
> > +  /* If OBJFILE is a separate debug object file, look for the
> > +     original object file.  */
> > +  if (objfile->separate_debug_objfile_backlink != NULL)
> > +    objfile = objfile->separate_debug_objfile_backlink;
> > +
> >     if (gdbarch_fetch_tls_load_module_address_p (gdbarch))
> >       {
> >         ptid_t ptid = inferior_ptid;



-- 
Joel

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-04-10 19:22 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-01 22:17 [PATCH] Handle TLS variable lookups when using separate debug files John Baldwin
2022-04-04 14:38 ` Tom Tromey
2022-04-04 22:15 ` John Baldwin
2022-04-10 19:22   ` Joel Brobecker

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).