I investigated and discovered this is a genuine bug in the patched
convert_addresses which now expects an additional argument; I never
noticed this upstream change:
2007-04-06 Olivier Hainque <hain...@adacore.com>
* adaint.c:
(convert_addresses): Adjust prototype and dummy definition to expect
an
extra file_name argument.
* gmem.c (__gnat_convert_addresses): Wrapper to convert_addresses,
filling the now expected file_name argument with the appropriate
argv[0] expansion.
(__gnat_gmem_a2l_initialize, __gnat_gmem_read_next_frame): Use it.
(tracebk): Array of void * instead of char *, corresponding to what
convert_addresses expects.
(exename): New static global, to hold the executable file name to be
used in all convert_addresses invocations.
(gmem_read_backtrace, __gnat_gmem_symbolic): Account for tracebk type
change.
(__gnat_gmem_a2l_initialize): Resolve exename.
(__gnat_convert_addresses): Use exename as the convert_addresses
file_name argument.
* g-trasym.adb (Symbolic_Traceback): Adjust signature of imported
"convert_addresses", now expecting a filename argument. Import the
necessary entities to compute the filename to use and pass it to
convert_addresses.
(Subversion revision 123544 on the trunk). Consequently I never
adjusted convert_addresses.c accordingly.
This is quite embarrassing as it means that both gnat-4.3 and
gnat-4.4 are broken in this respect.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/247db3c7ce23fb8c2d0b71b5638e4...@localhost
