From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA/windows] cast of address to DWORD warning (handle_unload_dll)
Date: Wed, 14 Jan 2009 04:47:00 -0000 [thread overview]
Message-ID: <20090114044615.GA24105@adacore.com> (raw)
In-Reply-To: <20090114042345.GA4556@ednor.casa.cgf.cx>
[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]
> >2009-11-14 Joel Brobecker <brobecker@adacore.com>
> >
> > * windows-nat.c (handle_unload_dll): Use host_address to string
> > in order to print the base address of the DLL that was unloaded.
> >
> >This one is hard to test, because it's supposed to never happen.
> >So I tested it by, ahem, visual inspection (I learnt that expression
> >at my first job, where we were producing safety critical software).
>
> I guess this is ok. I just changed other similar occurrences to %p.
> Maybe all of those should also be changed for hobgoblinish consistency
> or this one should be %p too.
I don't mind changing the patch to using %p at all. The reason I avoided
%p is because I was still in this frame of mind that %p depends on
the implementation - to have consistent output, we have to be careful
to not use %p in the core code. However, I just realized that it's not
necessarily a problem to do so in nat files.
I did double-check what %p does on Windows, though, and apparently it
does not output the leading 0x (but that's only a detail), but also it
prints the hexa digits in capital letters. This may be from not
being used to seeing addresses printed with capital letters, but
I find it harder to read. On the other hand, I have seen this style
being used in stack dumps printed by Windows, so this may be the
usual style on this OS.
For now, I think it's important to be consistent, so here is a new
patch that uses %p (no leading 0x).
2009-01-14 Joel Brobecker <brobecker@adacore.com>
* windows-nat.c (handle_unload_dll): Use %p to print the DLL
base address instead of casting it to DWORD.
--
Joel
[-- Attachment #2: handle_unload.diff --]
[-- Type: text/plain, Size: 367 bytes --]
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 724c18f..7e43f87 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -761,7 +761,7 @@ handle_unload_dll (void *dummy)
return 1;
}
- error (_("Error: dll starting at 0x%lx not found."), (DWORD) lpBaseOfDll);
+ error (_("Error: dll starting at %p not found."), lpBaseOfDll);
return 0;
}
next prev parent reply other threads:[~2009-01-14 4:47 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-14 3:42 Joel Brobecker
2009-01-14 4:24 ` Christopher Faylor
2009-01-14 4:47 ` Joel Brobecker [this message]
2009-01-14 4:52 ` Christopher Faylor
2009-01-14 5:24 ` Joel Brobecker
2009-01-14 15:05 ` Christopher Faylor
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=20090114044615.GA24105@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/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