Mail Archives: djgpp/2015/05/24/16:37:09
On 05/24/2015 12:24 PM, Eli Zaretskii (eliz AT gnu DOT org) wrote:
>> Date: Sun, 24 May 2015 11:17:27 +0300
>> From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi)" <djgpp AT delorie DOT com>
>>
>>> So what and how goes wrong in the DJGPP build of GDB? Can someone
>>> with enough free time step through the go32 initialization, and see
>>> what's wrong there?
>> Perhaps at least some hint could give GDB commit which caused that DJGPP port stopped to work (with
>> symptoms described earlier)
>>
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=9b409511d07fe375284701af34909fb539029caf
> Thanks!
>
> Actually, it seems bd265cd0bde9e045ab5946532449430b66fe91ad, which is
> a followup to the one you mentioned, is the bad commit. It seems a
> simple case of misunderstanding the API conventions of our read_child
> and write_child.
>
> Can you try the patch below? If it fixes the problem, I will push it.
>
> diff --git a/gdb/go32-nat.c b/gdb/go32-nat.c
> index f3966cd..852473b 100644
> --- a/gdb/go32-nat.c
> +++ b/gdb/go32-nat.c
> @@ -587,6 +587,13 @@
> else
> res = read_child (memaddr, readbuf, len);
>
> + /* read_child and write_child return zero on success, non-zero on
> + failure; adjust the result value to that. */
> + if (res == 0)
> + res = len;
> + else
> + res = -1;
> +
> if (res <= 0)
> return TARGET_XFER_E_IO;
>
>
>
I can confirm that with this patch applied I git current GIT master version of GDB to work for DJGPP:
- same example program cc1.exe from my earlier gcc-4.8.4 build used
- no error messages about accessing process memory
- backtrace somewhat unreliable but mostly works
Some small build problems:
- perhaps it would be best to kill dos_noop() in gdb-ser32.c and add appropriate static functions
instead (proptype of of one of them has changed in master branch, which caused compile error)
- got also DJGPP related compile error which is potentially related to latest changes, but I did
not have time to check whether it so
Also: Tried also cc1.exe from my last gcc-5.1.0 build with about the same results as with gcc-4.8.4
except that backtrace works sligthly worse.
Also: fails to read debug info from cc1.exe from gcc-6.0.0 20150506 snapshot build and complains
about dwarf error (could not find abbrev number 115 ....)
cc1.exe used from each tests were from stage 3 compile which is built by stage2 compiler of the
same version.
Andris
- Raw text -