From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Lipe To: Eric Raskin Cc: egcs@egcs.cygnus.com Subject: Re: DG/UX Port - Giving Up!! Date: Mon, 10 May 1999 13:00:00 -0000 Message-id: <19990510150003.S14813@rjlhome.sco.com> References: <19990510122355.I14813@rjlhome.sco.com> <078601be9b1a$64c43db0$65c8c8c8@ehrpc.listworks.com> <078601be9b1a$64c43db0$65c8c8c8@ehrpc.listworks.com> X-SW-Source: 1999-05/msg00280.html > > Actually, I doubt that GDB had to know any _debugging_ information to > > set the breakpoint. I could have gotten all the info it needed just > > from the symbol table. > > My assumption was since that gdb knew the source code file and line, that it > must be able to read something in the debugging info. Is that in the symbol OK, good point. The line number isn't "knowable" without debugging info. The address of the symbol can be determined via the symbol table but you do indeed have evidence that it can read at least some of the debugging info. > I got errors in the following tests: > > gcc.c-torture/compile/981001-2.c > dg.special/eeprof-1.c > > These went away when I switched to GNU as (as well as the compare > succeeding). They seem to have to do with weak symbols. Correct. I see these failures, too. This means you have an assembler that implements weak the way the original designers of weak symbols in ELF intended. (There is some debate as to whether or not that's what they actually *wrote* in the spec, though. :-) As I remember, these cases try to "retroactively" make a symbol weak after they've marked it global. Jeff and I have been working on a patch to cure this. It isn't unique to DG/UX. I think many SVR4-based systems that aren't using GAS will share these failures. RJL From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Lipe To: Eric Raskin Cc: egcs@egcs.cygnus.com Subject: Re: DG/UX Port - Giving Up!! Date: Mon, 31 May 1999 21:36:00 -0000 Message-ID: <19990510150003.S14813@rjlhome.sco.com> References: <19990510122355.I14813@rjlhome.sco.com> <078601be9b1a$64c43db0$65c8c8c8@ehrpc.listworks.com> X-SW-Source: 1999-05n/msg00279.html Message-ID: <19990531213600.lG4M-ZDJF6e7I-uQ-bffWGdGyfDUAGWwFfvJRQz6Z0k@z> > > Actually, I doubt that GDB had to know any _debugging_ information to > > set the breakpoint. I could have gotten all the info it needed just > > from the symbol table. > > My assumption was since that gdb knew the source code file and line, that it > must be able to read something in the debugging info. Is that in the symbol OK, good point. The line number isn't "knowable" without debugging info. The address of the symbol can be determined via the symbol table but you do indeed have evidence that it can read at least some of the debugging info. > I got errors in the following tests: > > gcc.c-torture/compile/981001-2.c > dg.special/eeprof-1.c > > These went away when I switched to GNU as (as well as the compare > succeeding). They seem to have to do with weak symbols. Correct. I see these failures, too. This means you have an assembler that implements weak the way the original designers of weak symbols in ELF intended. (There is some debate as to whether or not that's what they actually *wrote* in the spec, though. :-) As I remember, these cases try to "retroactively" make a symbol weak after they've marked it global. Jeff and I have been working on a patch to cure this. It isn't unique to DG/UX. I think many SVR4-based systems that aren't using GAS will share these failures. RJL