Re: dbxout.c stabs output problem

[Henry Sobotka <sobotka at axess dot com>]

Jim Wilson wrote:
> 
> What exactly is failing?  The linker?  Is this something we might be able to
> fix, such as GNU ld?  Or is this someone else's program that we can't fix?

The program that's failing is emxomf, a utility which converts .o to OMF
.obj files when the special emx+gcc -Zomf option is used. The conversion
is fine. The failures occur when -g is combined with -Zomf, in which
case emxomf also reads the stabs from the .s file and converts them to
"HLL version 3" (about which I haven't been able to find any info other
than the comments and what I can deduce from the conversion process in
stabshll.c, the rc.) The reason for the failure is simply that the parse
function is no longer getting the stabs it expects, and essentially what
I've been trying to find out is: 1) Are the "new" stabs correct or a
bug? and 2) If new, what are the rules/syntax now?

stabshll.c was easy enough to fix quick&dirty. It now expects "ar0" and
will read past the second "=" (it was dying with "unexpected symbol at
end of stabs: ="). So far it appears to working fine, with the only
side-effect being a slew of warnings about e.g. "undefined type 110",
with the number always the middle forward reference in, e.g.
"t109=110=*2" coming from gcc's dbxout.c. Rather than muffle the
warnings, I want to get the parsing right, and starts by looking at the
input string coming from gcc.

With gcc 2.7, new types only get a new number if they are a type that
has not yet been defined, most of which prove to be points and structs
after the core set. Thus we would get (in pseudostabs):

foo:t1;
bar:t2=*1;
pfoo:t2;
FOO:t1;
BAR:t2;
PBAR:t3=*2;

On the other hand, starting at line 3, gcc 2.8 produces:

pfoo:t3=2;
rashlyFOO:t4=1;
BAR:t5=2;
PBAR:t6=7=*2;

Since my original posting, it has become clear to me that what appears
to be the forward reference (the 7) is really what used to be the
increment upon encountering the new type. If I'm not mistaken, forward
references with 2.7 are all prefixed by 'x' (and stabshll.c was written
to expect those).

Now looking at your example, which is particularly interesting because
it encompasses the array typing issue as well:

On system A, size_t is long; on system B long long. And for arrays, the
digit following "ar" accurately represents the type.

gcc 2.7 would produce:

long:t1;
long long:t2;
size_t:t1;     // system A  ||  size_t:t2;     // system B
array:t2=ar1;  // system A  ||  array:t2=ar2;  // system B

so gcc 2.8 is intended to do:

long:t1;
long long:t2;
size_t:t3=1;     // system A  ||  size_t:t3=2;   // system B
array:t4=ar3;

I clearly see how this provides better bugging info. But in that case,
doesn't the second number assigned to PBAR in my example become
unnecessary? PBAR is clearly type 6 or pointer to 2, and marked as
different by its type number, so there's no more need for the old
differentiating increment (new type number 7) which now ends up
resembling a forward reference.

Looking at it from another angle, if we describe

plong:t6=*3;

as

name:type_ref=type_def;

the syntax (ignoring the special case of true forward references where a
type is defined in another file) has changed from gcc 2.7's

NEW TYPE	DEFINED TYPE		NEW TYPE OF DEFINED TYPE
name:type_ref  || name:type_def  ||  name:type_ref=type_def

to 2.8's simpler, clearer, consistent

ALL NON-FORWARD-REF TYPES
name:type_ref=type_def

which makes the occurrences of

name:type_ref=[type_ref || type_def?]=type_def

ambiguous and wrong. It's not a true forward reference although it looks
like one as the increment of the type_ref, yet is a forward reference
because that type_ref has not yet been defined. What appears to have
happened is that, in giving each new name its own type_ref, someone
forgot to get rid of the old mechanism that produced
name:type_ref=type_def (or have the new one skip those cases because its
job was already done).

Does that make sense?

***

The new C++ stabs kill emxomf completely. They're not easy to decipher,
even after demangling; docs and people who know about them are scarce;
the stabs manual appears to be 2.7 info; and I haven't yet walked
through their construction (this whole issue is phase 2 of my efforts to
get emxomf running properly). But in comparing and trying to analyze the
2.7 vs. 2.8 versions, I was left wondering if the new C++ stabs are all
"new, improved debugger info", or any of the above type of redundancy
might not have leaked through into the strings.

Could you or do you know of anyone who could tell me more about the 2.8
C++ stabs? As I notice the manual comes from Cygnus Support, I'd be glad
to repay the info and assistance in understanding them by doing an
update (if no one else is).

Henry