From: Andrew Cagney <ac131313@ges.redhat.com>
To: Jim Blandy <jimb@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFC: initial TLS patch
Date: Wed, 03 Jul 2002 08:28:00 -0000 [thread overview]
Message-ID: <3D23129A.8070207@ges.redhat.com> (raw)
In-Reply-To: <npr8imnogv.fsf@zwingli.cygnus.com>
> + else if (is_thread_local)
> + {
> + SYMBOL_CLASS (sym) = LOC_THREAD_LOCAL_STATIC;
> + SYMBOL_OBJFILE (sym) = objfile;
> + SYMBOL_VALUE_ADDRESS (sym) = addr;
> + }
Can I suggest awarding this mechanism a new LOC name. That way the past
history of LOC_THREAD_LOCAL_STATIC won't flow into this new mechanism.
As for thread local static, looks like a separate pass can purge GDB of it.
> ! TD_NOTALLOC /* TLS memory not yet allocated. */
Suggest TLS -> Thread [Local] memory
> + extern struct so_list *get_solib_by_objfile (struct objfile *OBJFILE);
Tipo OBJFILE -> objfile.
> Index: gdb/target.c
> ===================================================================
> RCS file: /cvs/src/src/gdb/target.c,v
> retrieving revision 1.36
> diff -c -r1.36 target.c
> *** gdb/target.c 15 Jun 2002 21:07:58 -0000 1.36
> --- gdb/target.c 29 Jun 2002 03:38:48 -0000
> ***************
> *** 610,615 ****
> --- 610,616 ----
> INHERIT (to_async_mask_value, t);
> INHERIT (to_find_memory_regions, t);
> INHERIT (to_make_corefile_notes, t);
> + INHERIT (to_get_thread_local_value, t);
> INHERIT (to_magic, t);
Does this also need some debug stuff added?
> #undef INHERIT
> Index: gdb/target.h
> +
> + /* Return the thread-local value of type TYPE at OFFSET in the
> + thread-local storage for the thread PTID and the shared library
> + or executable file given by OBJFILE. If that block of
> + thread-local storage hasn't been allocated yet, this function
> + may return an error, or try to concoct an appropriate
> + (non-lvalue) value based on the initialization image. */
> + struct value *(*to_get_thread_local_value) (ptid_t PTID,
> + struct objfile *OBJFILE,
> + CORE_ADDR OFFSET,
Per other [discussion] thread. I understand that at this time all that
this needs to compute / return are: thread storage base address;
conversion status - not allocated, readonly, read-write. Having it
return something more complicated like a ``struct value'' can be left to
the person that actually needs the mechanism - I figure they will be in
a better position to determine exactly what mechanism is needed.
Perhaphs there should be a separate ``struct location'' object?
> ***************
> *** 1021,1026 ****
> --- 1038,1050 ----
>
> #define target_make_corefile_notes(BFD, SIZE_P) \
> (current_target.to_make_corefile_notes) (BFD, SIZE_P)
> +
> +
> + /* Thread-local values. */
> + #define target_get_thread_local_value \
> + (current_target.to_get_thread_local_value)
> + #define target_has_get_thread_local_value() \
> + (target_get_thread_local_value != 0)
``_has_'' in the target vector appears to be used when testing
attributes such as ``the target has memory'' so
target_get_thread_local_value_p() would be better. Suggest ``!= NULL''.
> + if (! so)
> + error ((objfile_is_library
> + ? ("Cannot find shared library `%s' in dynamic linker's "
> + "module list")
> + : ("Cannot find executable file `%s' in dynamic linker's "
> + "module list")),
> + objfile->name);
Can I suggest writing these as:
if (objfile_is_library)
error (...)
else
error (...)
it is going to make checking and for correct i18n much easier. All
errors will match:
error[[:space:]]\(_\"[A-Z]
> + #ifdef THREAD_DB_DEFINES_TD_NOTALLOC
I suspect you mean THREAD_DB_HAS_TD_NOTALLOC, if it were a #define,
#ifdef TD_NOTALLOC would work :-)
enjoy,
Andrew
next prev parent reply other threads:[~2002-07-03 15:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-02 8:23 Jim Blandy
2002-07-02 10:08 ` Daniel Berlin
2002-07-03 2:39 ` Michael Snyder
2002-07-03 13:10 ` Jim Blandy
2002-07-03 8:28 ` Andrew Cagney [this message]
2002-07-03 11:30 ` Jim Blandy
2002-07-08 19:19 ` Andrew Cagney
2002-07-08 20:48 ` Jim Blandy
2002-07-08 20:06 ` Andrew Cagney
2002-07-08 20:15 ` Jim Blandy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D23129A.8070207@ges.redhat.com \
--to=ac131313@ges.redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox