PR27716, build failure for msdosdjgpp: PATH_MAX undeclared

We shouldn't be using arbitrary limits like PATH_MAX in GNU programs.
This patch also fixes some memory leaks in readelf when processing
separate debug info.

	PR 27716
binutils/
	* objdump.c (show_line): Don't limit paths to PATH_MAX.
	* readelf.c (struct filedata): Change program_interpreter from
	a char array to a char pointer.
	(process_program_headers): Sanity check PT_INTERP p_filesz.
	Malloc program_interpreter using p_filesz and read directly from
	file.
	(process_dynamic_section): Check program_interpreter is non-NULL.
	(free_filedata): New function, split out from..
	(process_object): ..here.
	(close_debug_file): Call free_filedata.
	* sysdep.h: Don't include sys/param.h.
	(PATH_MAX): Don't define.
	* configure.ac: Don't check for sys/param.h.
	* configure: Regenerate.
gprof/
	* gprof.h (PATH_MAX): Don't define.
	* corefile.c (core_create_line_syms): Don't use PATH_MAX for initial
	file name size.
	* source.c (annotate_source): Malloc file name buffer.  Always
	trim off "-ann" when dos 8.3 annotate file matches original.
	* utils.c (print_name_only): Malloc file name buffer.

1 files changed, 2 insertions, 2 deletions

diff --git a/gprof/corefile.c b/gprof/corefile.c
index 831d589f29c..b5e716dcbf4 100644
--- a/gprof/corefile.c
+++ b/gprof/corefile.c
@@ -781,8 +781,8 @@ core_create_line_syms (void)
 
      Of course, this is rather slow and it would be better if
      BFD would provide an iterator for enumerating all line infos.  */
-  prev_name_len = PATH_MAX;
-  prev_filename_len = PATH_MAX;
+  prev_name_len = 1024;
+  prev_filename_len = 1024;
   prev_name = (char *) xmalloc (prev_name_len);
   prev_filename = (char *) xmalloc (prev_filename_len);
   ltab.len = 0;