Pelles C forum
Pelles C => Bug reports => Topic started by: iZzz32 on November 11, 2011, 11:14:59 PM
-
C:\>podump C:\1.obj
Dump of C:\1.obj
File type: OBJ
PODUMP: fatal error: Access denied.
It tries to SetEndOfFile on the input file for some reason even though the file is opened with GENERIC_READ access. It fails, of course. PODUMP v6.50.1 (from the Pelles C 6.50 RC4) under Windows XP SP3 (32-bit).
-
Hello,
Can you attach the object file? I can repeat the test for you.
-
echo int i; > test.c && pocc /c test.c && podump test.obj
-
echo int i; > test.c && pocc /c test.c && podump test.obj
Are you sure that echo is a C command?
pocc /c test.c
test.c(1): warning #2099: Missing type specifier; assuming 'int'.
test.c(1): error #2001: Syntax error: expected ';' but found 'int'.
-
Are you joking? It's a shell command, it overwrites test.c with int i;, then compiles it and dumps the resulting .obj.
Ok, try to dump any .obj file with podump.
PS: trying to dump an empty file also produces a funny error message.
-
Are you joking? It's a shell command, it overwrites test.c with int i;, then compiles it and dumps the resulting .obj.
echo is a MS-DOS shell command and not a native C command. My question was a simple one...
-
Yes it seems a bug. Probably the *podump* code try to read beyond the file end.
If you try:
echo int i; > test.c && pocc /c test.c && podump /ALL test.obj
Podump produce requested output then stops with the error.
-
Yes it seems a bug. Probably the *podump* code try to read beyond the file end.
If you try:
echo int i; > test.c && pocc /c test.c && podump /ALL test.obj
Podump produce requested output then stops with the error.
FWIW... I found out the hard way that .C and .H files need at least one CR/LF pair at the end.
The "cheap and dirty" method by shell command does not necessarily add this for you.
-
CommonTater, newline at the end of file is required by the C standard, but Pelles C (as the most of the other compilers) can handle .c files without newline too (however there's a warning at /W1). And anyway echo command always puts a newline at the end of a string (at least in Windows).
-
Podump dumps *object* files (so don't care of source files newlines).
Pocc compile anyway the source .c file (the newline request is only a warning).
The behaviour of podump is the same with other object files.
-
Hi iZzz32,
If you have the Masm32 package or Visual Studio installed, can you try dumpbin?
\masm32\bin\dumpbin /all test.obj
-
Vortex, I'm very sorry about that PM.
Dumpbin from MASM32 v10 works just fine:Microsoft (R) COFF Binary File Dumper Version 5.12.8078
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Dump of file foo.obj
File Type: COFF OBJECT
FILE HEADER VALUES
14C machine (i386)
2 number of sections
4EC244D7 time date stamp Tue Nov 15 14:54:15 2011
74 file pointer to symbol table
7 number of symbols
0 size of optional header
100 characteristics
32 bit word machine
SECTION HEADER #1
.bss name
0 physical address
0 virtual address
0 size of raw data
0 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
C0300080 flags
Uninitialized Data
4 byte align
Read Write
SECTION HEADER #2
.drectve name
0 physical address
0 virtual address
10 size of raw data
64 file pointer to raw data
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
A00 flags
Info
Remove
(no align specified)
RAW DATA #2
00000000: 20 2D 64 65 66 61 75 6C 74 6C 69 62 3A 63 72 74 -defaultlib:crt
Linker Directives
-----------------
-defaultlib:crt
COFF SYMBOL TABLE
000 00000000 DEBUG notype Filename | .file
foo.c
002 00000000 SECT1 notype Static | .bss
Section length 0, #relocs 0, #linenums 0, checksum 0
004 00000004 UNDEF notype External | _foo
005 00000000 SECT2 notype Static | .drectve
Section length 10, #relocs 0, #linenums 0, checksum 0
String Table Size = 0x0 bytes
Summary
0 .bss
10 .drectve
Anyway, podump behaves the same on different machines, with or without AV software, so it is obviously a bug in podump. Something wrong with cleanup code, I think.
-
Hi iZzz32,
There is nothing to be sorry about the PM. Everything is fine and no any problem. As you said, there is probably a bug related to podump.exe