Defaulting to stabs debug output from AS Cygwin64

Defaulting to stabs debug output from AS Cygwin64

[Michael Enright]

I am working on a little compiler for fun, which generates assembly
code. At this point I manually invoke as and ld.

For debugging I added the -g option to the invocation of as, but then
ld failed with

 t.o:t.s:1:(.stab+0x14): relocation truncated to fit: R_X86_64_32
against `.text'

Looking into this on Stack Overflow I was taught that stabs is
obsolete. I think 'obsolete' may not be quite the right
interpretation, but 'wrong for Cygwin64' could be the right story.
Practically speaking, without thinking about it too critically,
-gdwarf2 in place of -g is the solution.

I'm trying to find authority for saying anything exact about the situation:
1) Is there a reason why stabs is the default for '-g' with Cygwin64?
1a) Is a patch desired to make dwarf2 the default?
2) Is there a way within Cygwin64 that a .o file with stabs can be
properly processed by ld to give proper input to gdb?
3) Is stabs fatally flawed for the purposes of Cygwin64 or could it be
upgraded, within the existing meaning of the stabs specification, so
that it would work?
3a) To put it another way, is this just a stabs bug that could be
fixed for Cygwin64?

Above when I say Cygwin64, I'm talking about straightforward native
use of as, ld, and gdb, not cross-compiling to some other platform.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Defaulting to stabs debug output from AS Cygwin64

[cyg Simple]

On 5/15/2018 12:17 AM, Michael Enright wrote:
> I am working on a little compiler for fun, which generates assembly
> code. At this point I manually invoke as and ld.
> 
> For debugging I added the -g option to the invocation of as, but then
> ld failed with
> 

Years of work tells me to not trust the default of any option.  You
should be specific.

<quote src="https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html">
-g
Produce debugging information in the operating system’s native format
(stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging
information.

On most systems that use stabs format, -g enables use of extra debugging
information that only GDB can use; this extra information makes
debugging work better in GDB but probably makes other debuggers crash or
refuse to read the program. If you want to control for certain whether
to generate the extra information, use -gstabs+, -gstabs, -gxcoff+,
-gxcoff, or -gvms (see below)
</quote>

>  t.o:t.s:1:(.stab+0x14): relocation truncated to fit: R_X86_64_32
> against `.text'
> 
> Looking into this on Stack Overflow I was taught that stabs is
> obsolete. I think 'obsolete' may not be quite the right
> interpretation, but 'wrong for Cygwin64' could be the right story.
> Practically speaking, without thinking about it too critically,
> -gdwarf2 in place of -g is the solution.
> 

The dwarf format isn't supported by native tools.  I think COFF should
be the default but that is just me and I don't maintain the distribution
of GCC.

> I'm trying to find authority for saying anything exact about the situation:
> 1) Is there a reason why stabs is the default for '-g' with Cygwin64?

I gave one above.

> 1a) Is a patch desired to make dwarf2 the default?

It would have to be at the upstream source level but I don't think so.

> 2) Is there a way within Cygwin64 that a .o file with stabs can be
> properly processed by ld to give proper input to gdb?

Does -gstabs+ help?

> 3) Is stabs fatally flawed for the purposes of Cygwin64 or could it be
> upgraded, within the existing meaning of the stabs specification, so
> that it would work?

That should be asked at the GCC upstream.

> 3a) To put it another way, is this just a stabs bug that could be
> fixed for Cygwin64?

I haven't looked at the source for the compiler to answer that.

> 
> Above when I say Cygwin64, I'm talking about straightforward native
> use of as, ld, and gdb, not cross-compiling to some other platform.

I question your use of Cygwin instead of MinGW for your compiler but
that is just a musing.

-- 
cyg Simple

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Defaulting to stabs debug output from AS Cygwin64

[Michael Enright]

On Tue, May 15, 2018 at 5:58 AM, cyg Simple <cygsimple@gmail.com> wrote:
>
> Years of work tells me to not trust the default of any option.  You
> should be specific.

I have a few years under my belt (come to think of it they are
threatening to engulf my belt). For work, I'd do what's necessary to
integrate the little thing into the big thing. For this I don't want
to work too hard on side issues unless I decide they are interesting
side issues.

>
> The dwarf format isn't supported by native tools.  I think COFF should
> be the default but that is just me and I don't maintain the distribution
> of GCC.

The GCC driver uses -gdwarf2 if you do 'gcc -g' on a .s file. Using
-gdwarf2 with assembly code manually or through gcc is successful in
producing a Cygwin64 executable that Cygwin64 GDB can work with. This
combination of circumstances led me to wonder how stabs was chosen for
Cygwin64.

>
> I question your use of Cygwin instead of MinGW for your compiler but
> that is just a musing.
>

When I cobble together an I/O system for the language's runtime, I
will probably switch the project to Linux-only. I/O is one of the
interesting side issues I wish to tackle.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Defaulting to stabs debug output from AS Cygwin64

[Hans-Bernhard Bröker]

Am 15.05.2018 um 19:17 schrieb Michael Enright:

> The GCC driver uses -gdwarf2 if you do 'gcc -g' on a .s file. Using
> -gdwarf2 with assembly code manually or through gcc is successful in
> producing a Cygwin64 executable that Cygwin64 GDB can work with. This
> combination of circumstances led me to wonder how stabs was chosen for
> Cygwin64.

Basically because it was not chosen.  It's not even actually supported, 
as evidenced by those relocation failures: not how those occurred in the 
.stab section.

"The" default of Cygwin is whatever the compiler uses, i.e. Dwarf2, and 
was indeed chosen, because none of the older formats stand a chance of 
really handling the amount and complexity of debug information needed 
for modern-day C++.

On to of that, making '-gdwarf-2' the default -g mode for 'as' would be 
an exercise in futility anyway, because that option is essentially a 
no-op.  That's because Dwarf-2 debug information is _not_ actually 
created by the -g flag to begin with: it's spelled out by the compiler 
as reams of data and reloc statements, to go into specially named 
sections like '.debug_info'.  GCC doesn't even pass any '-g' flag to the 
assembler in its default -gdwarf-2 mode.

It makes sense that "as -g" equals "as -gstabs" because unlike the other 
ones, that one at least does something: it causes .def pseudo-ops to put 
data into the .stab section, which also is automatically created by that 
option.

In a nutshell: you don't want to use either of "as -g" or "as -gstabs"


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple