Mail Archives: djgpp/2012/11/18/15:40:22
Am 18.11.2012 19:20, schrieb Eli Zaretskii:
>> Date: Sun, 18 Nov 2012 19:00:59 +0100
>> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
>>
>> To debug this issue I have tried to start ld.exe from gdb.exe.
>> The goal is to create an .exe file from the .o file produced by
>> the assembler. The .o file produced by the assembler is all OK.
>> The sample file is still the same as posted elsewhere.
>> To do this I start gdb with this control file:
>> ----------------------- start -----------------------
>> b main
>> b bfdio.c:124
>> # b _open.c:24
>> b crt1.c:__crt1_startup
>> r c:/djgpp-2.04/lib/crt0.o -Lc:/djgpp-2.04/bin/../lib/gcc/djgpp/4.72 -Lc:/djgpp-2.04/bin/../lib/gcc -Lc:/djgpp-2.04/lib -Lc:/djgpp-2.04/lib -Lc:/djgpp-2.04/bin/../lib/gcc/djgpp/4.72/../../.. 1.o -lgcc -lc -lgcc
>> ----------------------- end -----------------------
>>
>> Because of the __crt1_startup breakpoint, gdb shows how ld.exe
>> is initialized and djgpp.env is loaded and parsed. The issue
>> is that if I try to quit gdb at that breakpoint, NTVDM crashes
>> with the following output:
>>
>> Speicherzuordnungsfehler (memory allocation error)
>> COMMAND kann nicht geladen werden, System angehalten (COMMAND cannot be loaded, system halted)
>>
>>
>> It is my translation. I do not have a english OS version so I do not
>> know the english error message versions would sound.
>> The important issue is that NTVDM crashes no mather where I leave gdb
>> after having passed this point.
>> The above message is issued by WinXP Prof SP3. If I do the same on
>> Win98SE (from inside the GUI), no message is displayed at all because
>> the command prompt window is inmediately closed. This is not a gdb
>> issue. I have tried almost all version and they behave in the same
>> way.
>>
>> If I replace the r line with this one:
>> r 1.o -lgcc -lc -lgcc
>> no crash at all happens. Of course now the arguments to the linker
>> are incomplete and the linker cannot create an executable file anymore
>> and complains accordingly. But that is another story.
>> The original r line is as produced by gcc with the -v option.
>>
>> I know that __crt1_startup is called by crt0.S. Unfortunately my
>> assembler skills and my DPMI skills are very rudimentary. I do not
>> understood the code and its purpose. I assume that somewhere a buffer
>> overrun happens. The question is where and can it be fixed?
> __crt1_startup does this:
>
> void
> __crt1_startup(void)
> {
> __bss_count ++;
> __crt0_argv = 0;
> setup_os_version();
> setup_core_selector();
> setup_screens();
> setup_go32_info_block();
> __djgpp_exception_setup();
> setup_environment();
> __environ_changed++;
> __setup_file_rec_list();
> /* Make so rest of startup could use LFN. */
> (void)_USE_LFN;
> setup_pname();
> __crt0_load_environment_file(prog_name);
> (void)_USE_LFN; /* DJGPP.ENV might have set $LFN */
> free(prog_name);
> __crt0_setup_arguments();
> _npxsetup(__crt0_argv ? __crt0_argv[0] : __dos_argv0);
> _crt0_init_mcount();
> __main();
> errno = 0; /* ANSI says errno should be zero at program startup */
> exit(main(__crt0_argc, __crt0_argv, _environ));
> }
>
> My guess is that without going at least till after
> __djgpp_exception_setup, the DJGPP environment is not set up (e.g.,
> setup_core_selector and setup_go32_info_block sound very important...)
> for the program to survive the kill.
>
> Remember: DJGPP debug support makes it so that the debugger and the
> debuggee form a single process, as far as the OS is concerned. To
> start the debuggee, we actually load it with code that is very similar
> to the stub loader, the differences are due to a different setup of
> the segments and hooking some interrupts and exceptions. Running the
> debuggee and getting control back to the debugger is implemented as
> longjmp between the two code sections that live in the same process.
>
> So therefore questions:
>
> . does NTVDM still crash if you step until just before the call to
> main, and then quit?
Yes
>
> . what happens if you set a breakpoint not at entry to
> __crt1_startup, but on the line that calls 'setup_environment'?
> You can still see how djgpp.env is parsed, but all the critical
> setup should be already done, so maybe you won't crash NTVDM.
It crashes always no matter what I do.
If I set the breakpoint at setup_environment();
and quit then, it crashes.
If I stop there and continue one line more and quit
then, it crashes.
If I set the breakpoint at exit(main(__crt0_argc, __crt0_argv, _environ));
and quit then, it crashes.
>
> . did you try older GDB versions, like 6.8?
>
I have tried all GDB versions that I have found at /beta/v2gnu.
These are gdb53b and gdb64b. They all fail in the same way.
They have some difficulties to identify the lines in crt1.c but
as soon as they are inside the debuggee they work OK
Regards,
Juan M. Guerrero
- Raw text -