Experiences building and using gdb 6.8 on Solaris

Experiences building and using gdb 6.8 on Solaris

[Frank Middleton]

Not sure if this is the correct list, but maybe someone here is interested
in some Solaris issues

This is on snv103 (SunOS 5.11) for SPARC, with make aliased to gmake.

Biggest problem is that make distclean doesn't remove any of the cache
files, so the make fails miserably if, for example, you change LDFLAGS.

In order to get it to build, it was necessary to get the latest ncurses,
and to build that --with-shared, and, as usual, remember not to use
Solaris /bin/sh.

The motivation to build the latest gdb is the following error with
GNU gdb 6.3.50_2004-11-23-cvs
...
elfread.c:366: internal-error: sect_index_data not initialized
...

but, alas, it still fails with GNU gdb 6.8
...
elfread.c:424: internal-error: sect_index_data not initialized
A problem internal to GDB has been detected,
further debugging may prove unreliable.

Aside from the optimism of the last line (further debugging appears
to be impossible), is this a known problem? It is proving to be rather
difficult to make a simple test case, and extensive Googling found
little other than that something similar had been fixed a while ago.

Gdb runs simple executables just fine. The problem comes when linking
and running an executable containing a mix of libraries compiled using
Sun cc (i.e. the system libraries), some 3rd party libraries, probably
compiled using a relatively old gcc (3.4.2), and a relatively new
gcc (4.3.2) locally. Truss shows that the last library to be opened
was /usr/lib/libXau.so.6. Both versions of gdb emit this warning:
warning: Lowest section in /usr/lib/libdl.so.1 is .SUNW_syminfo at 00000094
AFAIK Sun ld was used for linking throughout. The application actually
run properly if you run it without gdb.

Any insights much appreciated...

Re: Experiences building and using gdb 6.8 on Solaris

[Paul Pluzhnikov]

On Sun, Apr 26, 2009 at 1:52 PM, Frank Middleton
<f.middleton@apogeect.com> wrote:
> Not sure if this is the correct list, but maybe someone here is interested
> in some Solaris issues
>
> This is on snv103 (SunOS 5.11) for SPARC, with make aliased to gmake.
>
> Biggest problem is that make distclean doesn't remove any of the cache
> files, so the make fails miserably if, for example, you change LDFLAGS.
>
> In order to get it to build, it was necessary to get the latest ncurses,
> and to build that --with-shared, and, as usual, remember not to use
> Solaris /bin/sh.
>
> The motivation to build the latest gdb is the following error with
> GNU gdb 6.3.50_2004-11-23-cvs
> ...
> elfread.c:366: internal-error: sect_index_data not initialized
> ...
>
> but, alas, it still fails with GNU gdb 6.8
> ...
> elfread.c:424: internal-error: sect_index_data not initialized
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
>
> Aside from the optimism of the last line (further debugging appears
> to be impossible), is this a known problem? It is proving to be rather
> difficult to make a simple test case, and extensive Googling found
> little other than that something similar had been fixed a while ago.
>
> Gdb runs simple executables just fine. The problem comes when linking
> and running an executable containing a mix of libraries compiled using
> Sun cc (i.e. the system libraries), some 3rd party libraries, probably
> compiled using a relatively old gcc (3.4.2), and a relatively new
> gcc (4.3.2) locally. Truss shows that the last library to be opened
> was /usr/lib/libXau.so.6. Both versions of gdb emit this warning:
> warning: Lowest section in /usr/lib/libdl.so.1 is .SUNW_syminfo at 00000094
> AFAIK Sun ld was used for linking throughout. The application actually
> run properly if you run it without gdb.
>
> Any insights much appreciated...

First, you should verify that it is indeed libXau.so.6 that is causing
the problem.
Steps:

echo "int main() { return 0; }" > junk.c
cc -g -c junk.c
cc -g junk.o -lX11  # resulting a.out should not produce the error
cc -g junk.o -lXau  # resulting a.out should trigger the problem

If libXau is indeed the problem, you've now got a trivial test case.
If not, do this:

  gdb -ex 'set verbose on' /path/to/app

This should provide a better clue what GDB was doing when the internal
error fired.

The other thing that may help figuring out the problem is to run gdb
under itself:

gdb -ex 'set prompt (top) ' --args gdb /path/to/app
(top) break internal_error
# Should set breakpoint 1 in the inferior GDB
(top) run
(gdb) run
# Should stop at breakpoint 1
(top) where full



-- 
Paul Pluzhnikov

Re: Experiences building and using gdb 6.8 on Solaris

[Frank Middleton]

On 04/26/09 20:43, Paul Pluzhnikov wrote:

> First, you should verify that it is indeed libXau.so.6 that is causing
> the problem.

It would seem that it is

> /usr/local/bin/gdb a.out
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.11"...
(gdb) r
Starting program: /tmp/a.out
elfread.c:424: internal-error: sect_index_data not initialized
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

> The other thing that may help figuring out the problem is to run gdb
> under itself:
>
> gdb -ex 'set prompt (top) ' --args gdb /path/to/app
> (top) break internal_error
> # Should set breakpoint 1 in the inferior GDB
> (top) run
> (gdb) run
> # Should stop at breakpoint 1
> (top) where full
>
Breakpoint 1, 0x000738d8 in internal_error ()
(top) where full
#0  0x000738d8 in internal_error ()
No symbol table info available.
#1  0x00128cf4 in ?? ()
No symbol table info available.
#2  0x00128cf4 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Would it help if I rebuilt gdb with symbols and reran this test, or maybe
it should be submitted as a bug to the Solaris maintainers? It is quite
conceivable that upgrading from snv103 to snv112 might fix this problem,
so does anyone at gdb want to work on this before I do so?

Re: Experiences building and using gdb 6.8 on Solaris

[Paul Pluzhnikov]

On Mon, Apr 27, 2009 at 6:18 AM, Frank Middleton
<f.middleton@apogeect.com> wrote:

>> (top) where full

I assumed you'd be using a "normal" CVS build (with "-g -O2"), not a
stripped binary.

> Breakpoint 1, 0x000738d8 in internal_error ()
> (top) where full
> #0  0x000738d8 in internal_error ()
> No symbol table info available.
> #1  0x00128cf4 in ?? ()
> No symbol table info available.
> #2  0x00128cf4 in ?? ()
> No symbol table info available.
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> Would it help if I rebuilt gdb with symbols and reran this test

Possibly. You shouldn't need to rebuild anything; just don't strip the
resulting GDB.

> or maybe
> it should be submitted as a bug to the Solaris maintainers?

I am not sure there *are* any Solaris maintainers.

> It is quite
> conceivable that upgrading from snv103 to snv112 might fix this problem,
> so does anyone at gdb want to work on this before I do so?

I'd say you should get the "full" stack trace first. This may give enough
clues to someone. If you want to upgrade your machine to snv112, it would
probably be wise to save the offending libXau first (just in case someone
desires to look at the problem later).

Cheers,
-- 
Paul Pluzhnikov

Re: Experiences building and using gdb 6.8 on Solaris

[Frank Middleton]

[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]

On 04/29/09 14:02, Paul Pluzhnikov wrote:
> I assumed you'd be using a "normal" CVS build (with "-g -O2"), not a
> stripped binary.

Of course, What was I thinking? Output from unstripped binary attached.

> I am not sure there *are* any Solaris maintainers.

 From my perspective, this is a regression from Solaris 9, where gdb
(6.0) didn't have this problem with libXau. gdb 6.0 and later do,
probably as of Solaris 10. I really meant Solaris libXau maintainers,
if there are any. They have accepted it as a bug, so I suppose they
will (eventually) fix libXau. As you suggest, they probably won't
address gdb since unsurprisingly they mostly use dbx. Personally I
find gdb much easier to use and it does everything I need it to.
Having said that, they do ship gdb with Solaris Nevada, in /usr/bin
no less. To get dbx is an extra download...

>> It is quite
>> conceivable that upgrading from snv103 to snv112 might fix this problem,
>> so does anyone at gdb want to work on this before I do so?
>
> I'd say you should get the "full" stack trace first. This may give enough
> clues to someone. If you want to upgrade your machine to snv112, it would
> probably be wise to save the offending libXau first (just in case someone
> desires to look at the problem later).

OK, no problem; I will save the offending libXau somewhere. It obviously
won't be (isn't) fixed in snv112 but I'll save this one as baseline anyway.

Cheers -- Frank

[-- Attachment #2: gdb-where --]
[-- Type: text/plain, Size: 11961 bytes --]


Breakpoint 1, internal_error (file=0x27bdd0 "elfread.c", line=424, 
    string=0x27be00 "sect_index_data not initialized") at utils.c:805
805	  va_start (ap, string);
(top) where full
#0  internal_error (file=0x27bdd0 "elfread.c", line=424, 
    string=0x27be00 "sect_index_data not initialized") at utils.c:805
	ap = (va_list) 0x2
#1  0x000b44c0 in elf_symtab_read (objfile=0x3fb510, type=0, number_of_symbols=93, 
    symbol_table=<value optimized out>) at elfread.c:421
	max_index = <value optimized out>
	size = <value optimized out>
	special_local_sect = 13
	msym = <value optimized out>
	sym = (asymbol *) 0x401f30
	i = 34
	symaddr = 4281735380
	offset = 4281729024
	ms_type = <value optimized out>
	sectinfo = (struct stab_section_info *) 0x0
	filesym = (asymbol *) 0x401ee8
	filesymname = 0x4009f8 "values-Xa.c"
	dbx = (struct dbx_symfile_info *) 0x3e0ae0
#2  0x000b45b0 in elf_symfile_read (objfile=0x3fb510, mainline=0) at elfread.c:593
	abfd = (bfd *) 0x3e1c30
	ei = {stabsect = 0x0, stabindexsect = 0x0, mdebugsect = 0x0}
	back_to = (struct cleanup *) 0x361960
	symcount = 93
	dynsymcount = <value optimized out>
	synthcount = <value optimized out>
	storage_needed = <value optimized out>
	symbol_table = (asymbol **) 0x3dac50
	dyn_symbol_table = <value optimized out>
	synthsyms = <value optimized out>
#3  0x000f8640 in syms_from_objfile (objfile=0x3fb510, addrs=0x3e0940, offsets=0x0, num_offsets=0, 
    mainline=0, verbo=19) at symfile.c:947
	local_addr = <value optimized out>
	old_chain = (struct cleanup *) 0x361948
	__PRETTY_FUNCTION__ = "syms_from_objfile"
#4  0x000f8994 in symbol_file_add_with_addrs_or_offsets (abfd=<value optimized out>, from_tty=0, 
    addrs=0x3e0940, offsets=0x0, num_offsets=0, mainline=0, flags=8) at symfile.c:1059
	objfile = (struct objfile *) 0x3fb510
	psymtab = <value optimized out>
	debugfile = <value optimized out>
	orig_addrs = (struct section_addr_info *) 0x3e1d08
	my_cleanups = (struct cleanup *) 0x0
	name = 0x388930 "/usr/lib/libXau.so.6"
#5  0x000f9364 in symbol_file_add_from_bfd (abfd=0x3e1c30, from_tty=0, addrs=0x3e0940, mainline=0, 
    flags=8) at symfile.c:1161
No locals.
#6  0x0007f18c in symbol_add_stub (arg=0x3c3ed0) at solib.c:421
	sap = (struct section_addr_info *) 0x3e0940
#7  0x0011134c in catch_errors (func=0x7f114 <symbol_add_stub>, func_args=0x3c3ed0, 
    errstring=0x2692b0 "Error while reading shared library symbols:\n", mask=6) at exceptions.c:513
	val = 0
	exception = {reason = 0, error = GDB_NO_ERROR, message = 0x0}
#8  0x0007eefc in solib_read_symbols (so=0x3c3ed0, from_tty=0) at solib.c:447
No locals.
#9  0x0007f6f0 in solib_add (pattern=0x0, from_tty=0, target=<value optimized out>, readsyms=1)
    at solib.c:698
	any_matches = 1
	loaded_any_symbols = 0
	gdb = (struct so_list *) 0x3c3ed0
#10 0x00107680 in handle_inferior_event (ecs=0xffbfdbc0) at infrun.c:2266
	jmp_buf_pc = <value optimized out>
	what = {main_action = BPSTAT_WHAT_CHECK_SHLIBS, call_dummy = 0}
	stepped_after_stopped_by_watchpoint = 0
	__PRETTY_FUNCTION__ = "handle_inferior_event"
#11 0x001092e4 in wait_for_inferior (treat_exec_as_sigtrap=0) at infrun.c:1042
	old_cleanups = (struct cleanup *) 0x3615e8
	ecss = {ws = {kind = TARGET_WAITKIND_STOPPED, value = {integer = 5, sig = TARGET_SIGNAL_TRAP, 
      related_pid = 5, execd_pathname = 0x5 <Address 0x5 out of bounds>, syscall_id = 5}}, 
  wp = 0xffbfdbc0, stepping_over_breakpoint = 0, random_signal = 0, stop_func_start = 4282148104, 
  stop_func_end = 4282148184, stop_func_name = 0x3db4b8 "rtld_db_dlactivity", sal = {symtab = 0x0, 
    section = 0x0, line = 0, pc = 4282092360, end = 0, explicit_pc = 0, explicit_line = 0}, 
  current_line = 0, current_symtab = 0x0, handling_longjmp = 0, ptid = {pid = 26446, lwp = 1, 
    tid = 0}, saved_inferior_ptid = {pid = -4203400, lwp = 1086580, tid = 2528312}, 
  step_after_step_resume_breakpoint = 0, stepping_through_solib_after_catch = 0, 
  stepping_through_solib_catchpoints = 0x0, new_thread_event = 0, tmpstatus = {
    kind = TARGET_WAITKIND_EXITED, value = {integer = 0, sig = TARGET_SIGNAL_0, related_pid = 0, 
      execd_pathname = 0x0, syscall_id = 0}}, infwait_state = infwait_normal_state, waiton_ptid = {
    pid = -1, lwp = 0, tid = 0}, wait_some_more = 1}
#12 0x0010965c in proceed (addr=<value optimized out>, siggnal=TARGET_SIGNAL_0, step=0)
    at infrun.c:844
	oneproc = 0
#13 0x00103784 in run_command_1 (args=0x0, from_tty=1, tbreak_at_main=<value optimized out>)
    at infcmd.c:563
	exec_file = 0x361498 "/tmp/a.out"
#14 0x000a3148 in do_cfunc (c=0x34b360, args=0x0, from_tty=1) at .././gdb/cli/cli-decode.c:60
No locals.
#15 0x000a3310 in cmd_func (cmd=0x34b360, args=0x0, from_tty=1) at .././gdb/cli/cli-decode.c:1663
No locals.
#16 0x0006fd88 in execute_command (p=0x329a89 "", from_tty=1) at top.c:449
	arg = 0x0
	c = (struct cmd_list_element *) 0x34b360
	flang = <value optimized out>
	line = 0x329a88 ""
	warned = 0
#17 0x00114dcc in command_handler (command=0x329a88 "") at event-top.c:518
	old_chain = (struct cleanup *) 0x0
	time_at_cmd_start = 192203
	space_at_cmd_start = 0
#18 0x00115da0 in command_line_handler (rl=<value optimized out>) at event-top.c:804
	p = <value optimized out>
	p1 = 0x382c48 "r"
	linebuffer = 0x382c48 "r"
	linelength = 80
#19 0x001cdbb4 in rl_callback_read_char () at callback.c:205
	line = 0x3627b0 "r"
	eof = <value optimized out>
	olevel = {3, -4202680, 1813908, -4202560, 1891596, 0 <repeats 11 times>, -12582912, 8388608,   0}
#20 0x00115078 in rl_callback_read_char_wrapper (client_data=0x0) at event-top.c:177
No locals.
#21 0x0011558c in stdin_event_handler (error=0, client_data=0x0) at event-top.c:431
No locals.
#22 0x001149e0 in handle_file_event (event_file_desc=0) at event-loop.c:728
	file_ptr = (file_handler *) 0x32a1d0
	mask = <value optimized out>
	error_mask_returned = 0
#23 0x00113bf0 in process_event () at event-loop.c:341
	event_ptr = <value optimized out>
	proc = (event_handler_func *) 0x114938 <handle_file_event>
	fd = <value optimized out>
#24 0x00114658 in gdb_do_one_event (data=<value optimized out>) at event-loop.c:378
No locals.
#25 0x0011134c in catch_errors (func=0x114434 <gdb_do_one_event>, func_args=0x0, 
    errstring=0x27bfb8 "", mask=6) at exceptions.c:513
	val = 0
	exception = {reason = 0, error = GDB_NO_ERROR, message = 0x0}
#26 0x000b4fa8 in tui_command_loop (data=0x0) at .././gdb/tui/tui-interp.c:153
	result = <value optimized out>
#27 0x00111938 in current_interp_command_loop () at interps.c:276
No locals.
#28 0x00068830 in captured_command_loop (data=0x1) at .././gdb/main.c:99
No locals.
#29 0x0011134c in catch_errors (func=0x68824 <captured_command_loop>, func_args=0x0, 
    errstring=0x261de8 "", mask=6) at exceptions.c:513
	val = 0
	exception = {reason = 0, error = GDB_NO_ERROR, message = 0x0}
#30 0x00067e24 in captured_main (data=<value optimized out>) at .././gdb/main.c:882
	argc = 2
	argv = <value optimized out>
	symarg = 0xffbfeacf "./a.out"
	execarg = 0xffbfeacf "./a.out"
	pidarg = 0x0
	corearg = 0x0
	pid_or_core_arg = 0x0
	cdarg = 0x0
	ttyarg = 0x0
	cmdarg = (struct cmdarg *) 0x3296a8
	cmdsize = <value optimized out>
	ncmd = 0
	dirarg = (char **) 0x3296b8
	dirsize = <value optimized out>
	ndir = 0
	homebuf = {st_dev = 0, st_pad1 = {0, 0, 0}, st_ino = 0, st_mode = 0, st_nlink = 0, 
  st_uid = 0, st_gid = 0, st_rdev = 0, st_pad2 = {0, 0}, st_size = 0, st_pad3 = 0, st_atim = {
    tv_sec = 0, tv_nsec = 0}, st_mtim = {tv_sec = 0, tv_nsec = 0}, st_ctim = {tv_sec = 0, 
    tv_nsec = 0}, st_blksize = 0, st_blocks = 0, st_fstype = '\0' <repeats 15 times>, st_pad4 = {0, 
    0, 0, 0, 0, 0, 0, 0}}
	cwdbuf = {st_dev = 0, st_pad1 = {0, 0, 0}, st_ino = 0, st_mode = 0, st_nlink = 0, st_uid = 0, 
  st_gid = 0, st_rdev = 0, st_pad2 = {0, 0}, st_size = 0, st_pad3 = 0, st_atim = {tv_sec = 0, 
    tv_nsec = 0}, st_mtim = {tv_sec = 0, tv_nsec = 0}, st_ctim = {tv_sec = 0, tv_nsec = 0}, 
  st_blksize = 0, st_blocks = 0, st_fstype = '\0' <repeats 15 times>, st_pad4 = {0, 0, 0, 0, 0, 0, 0, 
    0}}
	homedir = 0xffbff9a8 "/home/frank"
	i = <value optimized out>
	time_at_startup = 145070
	quiet = 0
	batch = 0
	set_args = 0
	print_help = 0
	print_version = 0
	long_options = {{name = 0x262948 "tui", has_arg = 0, flag = 0x0, val = 14}, {
    name = 0x262950 "xdb", has_arg = 0, flag = 0x310284, val = 1}, {name = 0x262958 "dbx", 
    has_arg = 0, flag = 0x310288, val = 1}, {name = 0x262960 "readnow", has_arg = 0, flag = 0x328530, 
    val = 1}, {name = 0x262968 "r", has_arg = 0, flag = 0x328530, val = 1}, {name = 0x262970 "quiet", 
    has_arg = 0, flag = 0x3102a8, val = 1}, {name = 0x262978 "q", has_arg = 0, flag = 0x3102a8, 
    val = 1}, {name = 0x262980 "silent", has_arg = 0, flag = 0x3102a8, val = 1}, {
    name = 0x262988 "nx", has_arg = 0, flag = 0x31033c, val = 1}, {name = 0x262990 "n", has_arg = 0, 
    flag = 0x31033c, val = 1}, {name = 0x262998 "batch-silent", has_arg = 0, flag = 0x0, val = 66}, {
    name = 0x2629a8 "batch", has_arg = 0, flag = 0x3102a4, val = 1}, {name = 0x2629b0 "epoch", 
    has_arg = 0, flag = 0x3287b4, val = 1}, {name = 0x2629b8 "fullname", has_arg = 0, flag = 0x0, 
    val = 102}, {name = 0x2629c8 "f", has_arg = 0, flag = 0x0, val = 102}, {
    name = 0x2629d0 "annotate", has_arg = 1, flag = 0x0, val = 12}, {name = 0x2629e0 "help", 
    has_arg = 0, flag = 0x31029c, val = 1}, {name = 0x2629e8 "se", has_arg = 1, flag = 0x0, 
    val = 10}, {name = 0x2629f0 "symbols", has_arg = 1, flag = 0x0, val = 115}, {name = 0x2629f8 "s", 
    has_arg = 1, flag = 0x0, val = 115}, {name = 0x262a00 "exec", has_arg = 1, flag = 0x0, 
    val = 101}, {name = 0x262a08 "e", has_arg = 1, flag = 0x0, val = 101}, {name = 0x262a10 "core", 
    has_arg = 1, flag = 0x0, val = 99}, {name = 0x262a18 "c", has_arg = 1, flag = 0x0, val = 99}, {
    name = 0x262a20 "pid", has_arg = 1, flag = 0x0, val = 112}, {name = 0x262a28 "p", has_arg = 1, 
    flag = 0x0, val = 112}, {name = 0x262a30 "command", has_arg = 1, flag = 0x0, val = 120}, {
    name = 0x262a38 "eval-command", has_arg = 1, flag = 0x0, val = 88}, {name = 0x262a48 "version", 
    has_arg = 0, flag = 0x310298, val = 1}, {name = 0x262a50 "x", has_arg = 1, flag = 0x0, 
    val = 120}, {name = 0x262a58 "ex", has_arg = 1, flag = 0x0, val = 88}, {name = 0x262a60 "ui", 
    has_arg = 1, flag = 0x0, val = 105}, {name = 0x262a68 "interpreter", has_arg = 1, flag = 0x0, 
    val = 105}, {name = 0x262a78 "i", has_arg = 1, flag = 0x0, val = 105}, {
    name = 0x262a80 "directory", has_arg = 1, flag = 0x0, val = 100}, {name = 0x262a90 "d", 
    has_arg = 1, flag = 0x0, val = 100}, {name = 0x262a98 "cd", has_arg = 1, flag = 0x0, val = 11}, {
    name = 0x262aa0 "tty", has_arg = 1, flag = 0x0, val = 116}, {name = 0x262aa8 "baud", has_arg = 1, 
    flag = 0x0, val = 98}, {name = 0x262ab0 "b", has_arg = 1, flag = 0x0, val = 98}, {
    name = 0x262ab8 "nw", has_arg = 0, flag = 0x0, val = 15}, {name = 0x262ac0 "nowindows", 
    has_arg = 0, flag = 0x0, val = 15}, {name = 0x262ad0 "w", has_arg = 0, flag = 0x0, val = 16}, {
    name = 0x262ad8 "windows", has_arg = 0, flag = 0x0, val = 16}, {name = 0x262ae0 "statistics", 
    has_arg = 0, flag = 0x0, val = 13}, {name = 0x262af0 "write", has_arg = 0, flag = 0x3102bc, 
    val = 1}, {name = 0x262af8 "args", has_arg = 0, flag = 0x3102a0, val = 1}, {name = 0x262b00 "l", 
    has_arg = 1, flag = 0x0, val = 108}, {name = 0x262b08 "return-child-result", has_arg = 0, 
    flag = 0x310294, val = 1}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
#31 0x0011134c in catch_errors (func=0x67720 <captured_main>, func_args=0xffbfe860, 
    errstring=0x261de8 "", mask=6) at exceptions.c:513
	val = 0
	exception = {reason = 0, error = GDB_NO_ERROR, message = 0x0}
#32 0x00067718 in gdb_main (args=<value optimized out>) at .././gdb/main.c:891
No locals.
#33 0x000676e0 in main (argc=2, argv=0xffbfe8e4) at gdb.c:33
	args = {argc = 2, argv = 0xffbfe8e4, use_windows = 0, interpreter_p = 0x261de0 "console"}
(top) 

Re: Experiences building and using gdb 6.8 on Solaris

[Paul Pluzhnikov]

On Wed, Apr 29, 2009 at 5:12 PM, Frank Middleton
<f.middleton@apogeect.com> wrote:

>> I am not sure there *are* any Solaris maintainers.
>
> From my perspective, this is a regression from Solaris 9, where gdb
> (6.0) didn't have this problem with libXau. gdb 6.0 and later do,
> probably as of Solaris 10. I really meant Solaris libXau maintainers,

Oh, I meant "GDB maintainers for Solaris". Sorry for the confusion.

> OK, no problem; I will save the offending libXau somewhere. It obviously
> won't be (isn't) fixed in snv112 but I'll save this one as baseline anyway.

What does 'readelf -S libXau.so.6' say?

Looking at the GDB source, I think the problem may be triggered if there is
'Ddata.data' section, but no '.data' section.

Thanks,
-- 
Paul Pluzhnikov

Re: Experiences building and using gdb 6.8 on Solaris

[Frank Middleton]

On 04/29/09 20:34, Paul Pluzhnikov wrote:

> What does 'readelf -S libXau.so.6' say?

%readelf -S /usr/lib/libXau.so.6
There are 28 section headers, starting at offset 0x4c68:

Section Headers:
   [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
   [ 0]                   NULL            00000000 000000 000000 00      0   0  0
   [ 1] .hash             HASH            000000b4 0000b4 000134 04   A  3   0  4
   [ 2] .SUNW_ldynsym     LOOS+ffffff3    000001e8 0001e8 000120 10   A  4  18  4
   [ 3] .dynsym           DYNSYM          00000308 000308 000260 10   A  4   1  4
   [ 4] .dynstr           STRTAB          00000568 000568 000419 00  AS  0   0  1
   [ 5] .SUNW_version     VERNEED         00000984 000984 000020 01   A  4   1  4
   [ 6] .SUNW_version     VERDEF          000009a4 0009a4 000054 01   A  4   3  4
   [ 7] .SUNW_versym      VERSYM          000009f8 0009f8 00004c 02   A  3   0  4
   [ 8] .SUNW_dynsymsort  LOOS+ffffff1    00000a44 000a44 000044 04   A  2   0  4
   [ 9] .SUNW_reloc       RELA            00000a88 000a88 000060 0c   A  3   0  4
   [10] .rela.plt         RELA            00000ae8 000ae8 000120 0c  AI  3  17  4
   [11] .text             PROGBITS        00000c08 000c08 000cb4 00  AX  0   0  4
   [12] .init             PROGBITS        000018bc 0018bc 00000c 00  AX  0   0  4
   [13] .fini             PROGBITS        000018c8 0018c8 00000c 00  AX  0   0  4
   [14] .rodata           PROGBITS        000018d4 0018d4 000004 00   A  0   0  4
   [15] .rodata1          PROGBITS        000018d8 0018d8 00003b 00   A  0   0  4
   [16] .got              PROGBITS        00012000 002000 000024 04  WA  0   0 8192
   [17] .plt              PROGBITS        00012024 002024 000154 0c WAX  0   0  4
   [18] .dynamic          DYNAMIC         00012178 002178 000168 08  WA  4   0  4
   [19] .bss              NOBITS          00020000 0022e0 000008 00  WA  0   0  4
   [20] .symtab           SYMTAB          00000000 0022e0 0005e0 10     21  57  4
   [21] .strtab           STRTAB          00000000 0028c0 00023f 00   S  0   0  1
   [22] .debug_info       PROGBITS        00000000 002aff 00199c 01      0   0  1
   [23] .debug_line       PROGBITS        00000000 00449b 000400 01      0   0  1
   [24] .debug_abbrev     PROGBITS        00000000 00489b 0000b0 01      0   0  1
   [25] .comment          PROGBITS        00000000 00494b 000119 00      0   0  1
   [26] .shstrtab         STRTAB          00000000 004a64 0000f6 00   S  0   0  1
   [27] .SUNW_signature   GNU_HASH        00000000 004b5a 00010e 00   p  0   0  1
Key to Flags:
   W (write), A (alloc), X (execute), M (merge), S (strings)
   I (info), L (link order), G (group), x (unknown)
   O (extra OS processing required) o (OS specific), p (processor specific)

Re: Experiences building and using gdb 6.8 on Solaris

[Hui Zhu]

Hi Frank,

Could you try your issue with gdb-cvs-head version?
You can get it in ftp://sourceware.org/pub/gdb/snapshots/current/ .

Thanks,
Hui

On Mon, Apr 27, 2009 at 04:52, Frank Middleton <f.middleton@apogeect.com> wrote:
> Not sure if this is the correct list, but maybe someone here is interested
> in some Solaris issues
>
> This is on snv103 (SunOS 5.11) for SPARC, with make aliased to gmake.
>
> Biggest problem is that make distclean doesn't remove any of the cache
> files, so the make fails miserably if, for example, you change LDFLAGS.
>
> In order to get it to build, it was necessary to get the latest ncurses,
> and to build that --with-shared, and, as usual, remember not to use
> Solaris /bin/sh.
>
> The motivation to build the latest gdb is the following error with
> GNU gdb 6.3.50_2004-11-23-cvs
> ...
> elfread.c:366: internal-error: sect_index_data not initialized
> ...
>
> but, alas, it still fails with GNU gdb 6.8
> ...
> elfread.c:424: internal-error: sect_index_data not initialized
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.
>
> Aside from the optimism of the last line (further debugging appears
> to be impossible), is this a known problem? It is proving to be rather
> difficult to make a simple test case, and extensive Googling found
> little other than that something similar had been fixed a while ago.
>
> Gdb runs simple executables just fine. The problem comes when linking
> and running an executable containing a mix of libraries compiled using
> Sun cc (i.e. the system libraries), some 3rd party libraries, probably
> compiled using a relatively old gcc (3.4.2), and a relatively new
> gcc (4.3.2) locally. Truss shows that the last library to be opened
> was /usr/lib/libXau.so.6. Both versions of gdb emit this warning:
> warning: Lowest section in /usr/lib/libdl.so.1 is .SUNW_syminfo at 00000094
> AFAIK Sun ld was used for linking throughout. The application actually
> run properly if you run it without gdb.
>
> Any insights much appreciated...
>
>
>

Re: Experiences building and using gdb 6.8 on Solaris

[Frank Middleton]

On 04/30/09 01:44, Hui Zhu wrote:
> Hi Frank,
>
> Could you try your issue with gdb-cvs-head version?
> You can get it in ftp://sourceware.org/pub/gdb/snapshots/current/ .
>
> Thanks,
> Hui

Still seems to fail...

gdb a.out
GNU gdb (GDB) 6.8.50.20090427-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.11".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) r
Starting program: /tmp/a.out
elfread.c:433: internal-error: sect_index_data not initialized
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)

Re: Experiences building and using gdb 6.8 on Solaris

[Paul Pluzhnikov]

[-- Attachment #1: Type: text/plain, Size: 285 bytes --]

On Thu, Apr 30, 2009 at 7:51 AM, Frank Middleton
<f.middleton@apogeect.com> wrote:

> Still seems to fail...
> elfread.c:433: internal-error: sect_index_data not initialized

I misread the exact location where it fails.
Does attached patch fix it for you?

Cheers,
-- 
Paul Pluzhnikov

[-- Attachment #2: gdb.sect_index_data.20090430.txt --]
[-- Type: text/plain, Size: 823 bytes --]

Index: elfread.c
===================================================================
RCS file: /cvs/src/src/gdb/elfread.c,v
retrieving revision 1.76
diff -u -p -u -r1.76 elfread.c
--- elfread.c	3 Jan 2009 05:57:51 -0000	1.76
+++ elfread.c	30 Apr 2009 15:03:41 -0000
@@ -427,10 +427,11 @@ elf_symtab_read (struct objfile *objfile
 			  int max_index;
 			  size_t size;
 
-			  max_index 
-			    = max (SECT_OFF_BSS (objfile),
-				   max (SECT_OFF_DATA (objfile),
-					SECT_OFF_RODATA (objfile)));
+			  max_index = SECT_OFF_BSS (objfile);
+			  if (objfile->sect_index_data > max_index)
+			    max_index = objfile->sect_index_data;
+			  if (objfile->sect_index_rodata > max_index)
+			    max_index = objfile->sect_index_rodata;
 
 			  /* max_index is the largest index we'll
 			     use into this array, so we must

Re: Experiences building and using gdb 6.8 on Solaris

[Frank Middleton]

On 04/30/09 11:41, Paul Pluzhnikov wrote:
> On Thu, Apr 30, 2009 at 7:51 AM, Frank Middleton

> Does attached patch fix it for you?

Yes, it appears that it does. Thank you so much! What should I tell
the OpenSolaris folks?

gdb /tmp/a.out
GNU gdb (GDB) 6.8.50.20090427-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.11".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) r
Starting program: /tmp/a.out
[Thread debugging using libthread_db enabled]

Program exited normally.
(gdb)

Re: Experiences building and using gdb 6.8 on Solaris

[Paul Pluzhnikov]

On Thu, Apr 30, 2009 at 9:17 AM, Frank Middleton
<f.middleton@apogeect.com> wrote:

> On 04/30/09 11:41, Paul Pluzhnikov wrote:
>> Does attached patch fix it for you?
>
> Yes, it appears that it does. Thank you so much! What should I tell
> the OpenSolaris folks?

Probably nothing: this looks like unwarranted assumption on GDB part.
I'll submit this patch to gdb-patches@sourceware.org for review, and will
CC you so you'll know whether this is the right fix.

Cheers,
-- 
Paul Pluzhnikov