From: Eli Zaretskii <eliz@gnu.org>
To: Gabriel Ravier <gabravier@gmail.com>
Cc: gcc@hazardy.de, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org
Subject: Re: [PATCH 3/4] libbacktrace: work with aslr on windows
Date: Fri, 20 Jan 2023 21:19:53 +0200 [thread overview]
Message-ID: <83k01hm2sm.fsf@gnu.org> (raw)
In-Reply-To: <e1e2342c-27f1-7cec-787e-23b4c6dfee6b@gmail.com> (message from Gabriel Ravier on Fri, 20 Jan 2023 17:46:59 +0100)
> Date: Fri, 20 Jan 2023 17:46:59 +0100
> Cc: gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org
> From: Gabriel Ravier <gabravier@gmail.com>
>
> On 1/20/23 14:39, Eli Zaretskii via Gcc wrote:
> >> From: Björn Schäpers <gcc@hazardy.de>
> >> Date: Fri, 20 Jan 2023 11:54:08 +0100
> >>
> >> @@ -856,7 +870,12 @@ coff_add (struct backtrace_state *state, int descriptor,
> >> + (sections[i].offset - min_offset));
> >> }
> >>
> >> - if (!backtrace_dwarf_add (state, /* base_address */ 0, &dwarf_sections,
> >> +#ifdef HAVE_WINDOWS_H
> >> + module_handle = (uintptr_t) GetModuleHandleW (NULL);
> >> + base_address = module_handle - image_base;
> >> +#endif
> >> +
> >> + if (!backtrace_dwarf_add (state, base_address, &dwarf_sections,
> >> 0, /* FIXME: is_bigendian */
> >> NULL, /* altlink */
> >> error_callback, data, fileline_fn,
> > Why do you force using the "wide" APIs here? Won't GetModuleHandle do
> > the job, whether it resolves to GetModuleHandleA or GetModuleHandleW?
>
> I would expect the reason to be either that:
>
> - using wide APIs with Windows is generally considered to be a best
> practice, even when not strictly needed (and in this case I can't see
> any problem with doing so, unless maybe we want to code to work with
> Windows 95 or something like that...)
There's no reason to forcibly break GDB on platforms where wide APIs
are not available.
> - using the narrow API somehow has an actual drawback, for example maybe
> it might not work if the name of the exe file the NULL will tell it to
> get a handle to contains wide characters
Native Windows port of GDB doesn't support Unicode file names anyway,
which is why you used the *A APIs elsewhere in the patch, and
rightfully so. So there's no reason to use "wide" APIs in this one
place, and every reason not to.
next prev parent reply other threads:[~2023-01-20 19:19 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-20 10:54 [PATCH 1/4] libbacktrace: change all pc related variables to uintptr_t Björn Schäpers
2023-01-20 10:54 ` [PATCH 2/4] libbacktrace: detect executable path on windows Björn Schäpers
2023-01-23 23:00 ` Ian Lance Taylor
2023-01-24 13:11 ` Eli Zaretskii
2023-01-24 14:35 ` Ian Lance Taylor
2023-01-24 16:52 ` Eli Zaretskii
2023-01-24 17:58 ` Ian Lance Taylor
2023-01-24 18:11 ` Eli Zaretskii
2023-01-24 18:32 ` Ian Lance Taylor
2023-02-05 9:20 ` Björn Schäpers
2023-02-06 0:22 ` Ian Lance Taylor
2023-11-20 19:56 ` Björn Schäpers
2023-11-29 22:05 ` Ian Lance Taylor
2023-01-24 21:00 ` Björn Schäpers
2023-01-20 10:54 ` [PATCH 3/4] libbacktrace: work with aslr " Björn Schäpers
2023-01-20 13:39 ` Eli Zaretskii
2023-01-20 16:46 ` Gabriel Ravier
2023-01-20 19:19 ` Eli Zaretskii [this message]
2023-01-20 20:39 ` Gabriel Ravier
2023-01-21 4:05 ` Eli Zaretskii
2023-01-21 9:18 ` LIU Hao
2023-01-21 9:25 ` Eli Zaretskii
2023-01-21 10:47 ` Gabriel Ravier
2023-01-21 11:42 ` Eli Zaretskii
2023-11-20 19:57 ` Björn Schäpers
2023-11-20 20:07 ` Eli Zaretskii
2023-11-21 19:35 ` Björn Schäpers
2023-11-22 1:13 ` LIU Hao
2023-11-30 19:25 ` Ian Lance Taylor
2023-01-20 10:54 ` [PATCH 4/4] libbacktrace: get debug information for loaded dlls Björn Schäpers
2023-11-30 19:53 ` Ian Lance Taylor
2023-11-30 20:16 ` Eli Zaretskii
2024-01-02 23:12 ` Björn Schäpers
2024-01-04 22:33 ` [PATCH 5/4] libbacktrace: improve getting " Björn Schäpers
2024-01-06 22:15 ` [PATCH 6/4] libbacktrace: Add loaded dlls after initialize Björn Schäpers
2024-01-07 6:50 ` Eli Zaretskii
[not found] ` <4cb3a2a5-c0b3-40c8-b460-f21d65a9aea2@hazardy.de>
2024-01-07 14:46 ` Eli Zaretskii
2024-01-07 16:07 ` Björn Schäpers
2024-01-07 17:03 ` Eli Zaretskii
2024-01-09 20:02 ` Björn Schäpers
2024-01-10 12:34 ` Eli Zaretskii
2024-03-15 20:41 ` Björn Schäpers
2024-01-23 22:37 ` [PATCH 5/4] libbacktrace: improve getting debug information for loaded dlls Ian Lance Taylor
2024-01-25 19:53 ` Björn Schäpers
2024-01-25 22:04 ` Ian Lance Taylor
2024-03-15 20:40 ` Björn Schäpers
2024-04-25 20:14 ` Björn Schäpers
2024-04-28 18:16 ` Ian Lance Taylor
2024-05-02 19:23 ` Björn Schäpers
2024-05-03 22:27 ` Ian Lance Taylor
2024-01-23 21:24 ` [PATCH 4/4] libbacktrace: get " Björn Schäpers
2023-01-20 22:25 ` [PATCH 1/4] libbacktrace: change all pc related variables to uintptr_t Ian Lance Taylor
2023-01-23 20:17 ` Björn Schäpers
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=83k01hm2sm.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gabravier@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gcc@gcc.gnu.org \
--cc=gcc@hazardy.de \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).