Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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;
 }

  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