From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11662 invoked by alias); 2 Oct 2007 22:31:16 -0000 Received: (qmail 11654 invoked by uid 22791); 2 Oct 2007 22:31:16 -0000 X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.182) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 Oct 2007 22:31:12 +0000 Received: by wa-out-1112.google.com with SMTP id l35so5560922waf for ; Tue, 02 Oct 2007 15:31:11 -0700 (PDT) Received: by 10.114.196.1 with SMTP id t1mr2914014waf.1191364270752; Tue, 02 Oct 2007 15:31:10 -0700 (PDT) Received: by 10.115.17.20 with HTTP; Tue, 2 Oct 2007 15:31:10 -0700 (PDT) Message-ID: Date: Tue, 02 Oct 2007 22:31:00 -0000 From: shrimpx@gmail.com To: gdb@sourceware.org Subject: trying to understand some BFD code MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-10/txt/msg00028.txt.bz2 Hi all, I've asked a similar question before, but I'm still trying to understand some stuff in how BFD works, for a research project I'm working on. Help would be much appreciated! In include/aout/aout64.h there is this type declaration: struct reloc_std_external { bfd_byte r_address[BYTES_IN_WORD]; /* Offset of of data to relocate. */ bfd_byte r_index[3] ; /* Symbol table index of symbol. */ bfd_byte r_type[1]; /* Relocation type. */ }; It seems that most uses of this struct in the code are guarded by a bfd_header_big_endian(...) check. E.g. line 420 in bfd/aout-arm.c. If bfd_header_big_endian() is true, it's assumed that the three bytes in r_index are laid out right-to-left. When it's false, they are left-to-right. Also, depending on the value of bfd_header_big_endian(), the *bits* in r_type[0] are laid out differently -- right to left vs left to right. Could someone explain why this is the case? Is it fundamentally tied to the endianness of binary formats? If so, why are the *bits* inside r_type[0] reversed? To my knowledge, bfd_header_big_endian() indicates the byte-endianness of the format. Or is it a high-level programming pattern that helps GDB programmers work with this code in a way that is harder otherwise? Thanks very much! -m