* more long long problems "objdump --debugging"
@ 2008-01-11 1:20 Greg McGary
2008-01-11 11:21 ` Andreas Schwab
2008-01-11 16:38 ` Alan Modra
0 siblings, 2 replies; 4+ messages in thread
From: Greg McGary @ 2008-01-11 1:20 UTC (permalink / raw)
To: binutils; +Cc: amodra
stabs.c uses bfd_vma to hold enum members. That doesn't work when
bfd_vma is 32-bits but the enum member needs 64. This is a general
problem that applies to debug readers of all formats. Debug info needs
to express integer values sized according to the source language, but
binutils ties the internal representation to bfd_vma, which is
determined by target machine arch.
dwarf.h makes an effort by defining dwarf_vma:
#if __STDC_VERSION__ >= 199901L || (defined(__GNUC__) && __GNUC__ >= 2)
/* We can't use any bfd types here since readelf may define BFD64 and
objdump may not. */
typedef unsigned long long dwarf_vma;
typedef unsigned long long dwarf_size_type;
#else
typedef unsigned long dwarf_vma;
typedef unsigned long dwarf_size_type;
#endif
I'd like to make invent a universal longest-int type used by all
debug-info readers, and standardize on a conditional. Is there any
reason we shouldn't replace the test above with "#if
BFD_HOST_64BIT_LONG_LONG" ??
G
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: more long long problems "objdump --debugging"
2008-01-11 1:20 more long long problems "objdump --debugging" Greg McGary
@ 2008-01-11 11:21 ` Andreas Schwab
2008-01-11 16:22 ` Greg McGary
2008-01-11 16:38 ` Alan Modra
1 sibling, 1 reply; 4+ messages in thread
From: Andreas Schwab @ 2008-01-11 11:21 UTC (permalink / raw)
To: Greg McGary; +Cc: binutils, amodra
Greg McGary <greg@mcgary.org> writes:
> stabs.c uses bfd_vma to hold enum members. That doesn't work when bfd_vma
> is 32-bits but the enum member needs 64.
Enumeration constants can only be in the range of an int.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, MaxfeldstraÃe 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: more long long problems "objdump --debugging"
2008-01-11 11:21 ` Andreas Schwab
@ 2008-01-11 16:22 ` Greg McGary
0 siblings, 0 replies; 4+ messages in thread
From: Greg McGary @ 2008-01-11 16:22 UTC (permalink / raw)
To: Andreas Schwab; +Cc: binutils, amodra
Andreas Schwab wrote:
> Greg McGary <greg@mcgary.org> writes:
>
>
>> stabs.c uses bfd_vma to hold enum members. That doesn't work when bfd_vma
>> is 32-bits but the enum member needs 64.
>>
>
> Enumeration constants can only be in the range of an int.
>
This is a GNU extension. The only complaint comes with -pedantic:
warning: ISO C restricts enumerator values to range of 'int'
If GCC generates debug info for enumerator constants bigger than int,
binutils ought to support them.
G
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: more long long problems "objdump --debugging"
2008-01-11 1:20 more long long problems "objdump --debugging" Greg McGary
2008-01-11 11:21 ` Andreas Schwab
@ 2008-01-11 16:38 ` Alan Modra
1 sibling, 0 replies; 4+ messages in thread
From: Alan Modra @ 2008-01-11 16:38 UTC (permalink / raw)
To: Greg McGary; +Cc: binutils
On Wed, Jan 09, 2008 at 07:12:41PM -0800, Greg McGary wrote:
> I'd like to make invent a universal longest-int type used by all
> debug-info readers, and standardize on a conditional. Is there any
> reason we shouldn't replace the test above with "#if
> BFD_HOST_64BIT_LONG_LONG" ??
That should work. You could also just use bfd_int64_t.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-01-11 1:16 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-11 1:20 more long long problems "objdump --debugging" Greg McGary
2008-01-11 11:21 ` Andreas Schwab
2008-01-11 16:22 ` Greg McGary
2008-01-11 16:38 ` Alan Modra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).