This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [patch/peflags] Allow to change PE header stack and heap sizes
On 8/10/2011 4:12 AM, Corinna Vinschen wrote:
> In that case I prefer to use the offsetof macro on all hosts. That's
> much simpler, right?
Sure, that's fine.
>
> That's right, it just looks a bit convoluted. Maybe the logic when to
> print something in peflags might need some revamping.
Yeah, reminds me of zork: a maze of twisty little passages, all alike...
> Apart from that, here's a question. If the --verbose flag is given,
> should peflags print the sizeof values as well? That's not the case
> right now. I think changing the sizeof values is just a side job of
> peflags, so personally I'm not really sure I want to see the sizes on
> -v. It would be a simple patch, of course:
>
> for (i = 0; i < NUM_SIZEOF_VALUES; ++i)
> {
> - if (sizeof_vals[i].handle != DONT_HANDLE)
> + if (verbose || sizeof_vals[i].handle != DONT_HANDLE)
I agree. If you're really that interested in printing ALL of the
stack/heap values for some .exe, you can either explicitly list them on
the cmd line: -X -x -Y -y -z --- or use objdump.
>>> + if (option_index == 0 && c != long_options[0].val)
>
> Good thinking. Done in the patch below.
Ack.
>> I'm just wondering if, to avoid warnings, we need to explicitly cast the
>> RHS to ULONG.
>
> In fact there are no warnings emitted by gcc, neither with Cygwin's nor
> with Ming64's gcc 4.5.3. Keep in mind we're using -g -O2 -Wall -Werror
> all the time. Everything's sufficently casted.
Oh, yeah, you're right. I should have trusted the compiler rather than
my eyes. :-)
> Apart from the warnings, there *is* the issue that the user can enter
> something like --stack-reserve=0x1234567890 even if the executable is a
> 32 bit executable, and the value just gets truncated.
>
> On second thought, the get_and_set_size function should emit a warning
> if somebody tries to change a 32 bit field to a 64 bit value. I added
> that functionality to the below patch.
OK.
>> DO_READ doesn't have the same issue, because we're assigning a smaller
>> type to a larger storage, in that case; it just gets sign-extended.
>
> Well, no. The values are all unsigned, so there's no sign extension ;)
Right; unsigned types get zero-extended on promotion.
> New patch below,, with these additions to the ChangeLog:
Fine by me, with one addition:
+#include <stddef.h>
For some reason, the mingw.org headers don't include it automatically
via the other std*.h -- so you're missing the definition of the offsetof
macro without explicitly including stddef.
--
Chuck