Re: [PATCH] Add dll trampoline code handling for windows 64bit

[Joel Brobecker <brobecker@adacore.com>]

> There is a script called gdb_indent.sh in gdb's root dir. I applied
> it on amd64-windows-nat.c ahead of getting out my patch thinking
> that this would be the correct way. Some misunderstanding as it
> produced most of your indention concerns.

That is very odd, the script should indeed indent the sources
in a way that follows the GNU Coding Standards. Perhaps we are
missing some parameters in the call to that script that override
certain defaults that may no longer match our standards. But FWIW,
we have rarely used that script in the past few years. I think
that this is because GNU indent, the tool that it uses underneath,
isn't very smart and often produces a layout that's worse than
what a human would produce.

I should also say that we have a lot of violations to the GCS
spread around the code, and it's very common for someone to
copy/paste them, or introduce new ones on their own. I know
I do, occasionally. I have observed that we have been trying harder
in the recent past to be stricter and more aware of them. It's
a bit of a pain both for the contributor and the reviewer, but
it's easy to fix, and I think it's for the best in the end.

> Before doing it "my" way I already played around with both
> read_memory_typed_address and read_memory_unsigned_integer
> but did not get the correct CORE_ADDR. The bytes were always
> in the wrong order believing that these are endianess issues. Will
> reinvestigate that when back at the office. Anyhow my approach
> appears to be working, too. I succesfully single stepped thru
> many dlls using my patch on win64 which was not possible before.

That's odd, particulary if you tested with a native GDB? Perhaps
the address is stored in a different way, but that would also
be very surprising. Good luck with the hunting!

-- 
Joel