On Tue, Apr 03, 2007 at 07:31:09AM -0700, Nishanth Aravamudan wrote:
> On 03.04.2007 [09:01:34 -0500], Adam Litke wrote:
> > On Mon, 2007-04-02 at 18:27 -0700, Nishanth Aravamudan wrote:
> > > ppc: rework plt detection
> > > 
> > > We currently emit LONG(0) into the .plt section of relinked ppc binaries
> > > to make it appear in the filesz (on-disk) portion of the data/bss
> > > segment. This is a problem, however, for powerpc64, where the ABI
> > > specifies that the .plt section is NOBITS (x86 and x86_64 mark the .plt
> > > PROGBITS). Given that the program is being relinked to begin with,
> > > however, it seems logical to simply add a tag, similar to
> > > __executable_start, to make finding the "libhuge" filesz easy to find.
> > > Do exactly this, via __libhuge_filesz, and skip the extracopy detection
> > > if this symbol is defined. Tested on powerpc64.
> > 
> > Looks good to me... 
> > 
> > What do you think about adding some comments into the linker scripts
> > here so it will be easy to remember what this is for later?
> 
> Updated patch below:
> 
> 
> ppc: rework plt detection
> 
> We currently emit LONG(0) into the .plt section to make it appear in the
> filesz (on-disk) portion of the data/bss segment. This is a problem,
> however, for powerpc64, where the ABI specifies that the .plt section is
> NOBITS (x86 and x86_64 mark the .plt PROGBITS). Given that the program
> is being relinked to begin with, however, it seems logical to simply add
> a tag, similar to __executable_start, to make finding the "libhuge"
> filesz easy to find. Do exactly this, via __libhuge_filesz, and skip the
> extracopy detection if this symbol is defined. Tested on powerpc64.

Nice idea, definitely neater than the LONG(0) thing.  However, I don't
see how it safely lets up bypass extracopy detection - the stdin,
stdout variables that libc initializes will still lie in the BSS
section after the __libhuge_filesz symbol.

> diff --git a/elflink.c b/elflink.c
> index 5058248..00b403a 100644
> --- a/elflink.c
> +++ b/elflink.c
> @@ -414,6 +414,7 @@ static void get_extracopy(struct seg_info *seg, Elf_Phdr 
> *phdr, int phnum)
>       int ret, numsyms, found_sym = 0;
>       void *start, *end, *start_orig, *end_orig;
>       void *sym_start, *sym_end;
> +     extern void __libhuge_filesz __attribute__((weak));
>  
>       end_orig = seg->vaddr + seg->memsz;
>       start_orig = seg->vaddr + seg->filesz;
> @@ -422,6 +423,13 @@ static void get_extracopy(struct seg_info *seg, Elf_Phdr 
> *phdr, int phnum)
>       if (!minimal_copy)
>               goto bail2;
>  
> +     if (&__libhuge_filesz) {
> +             found_sym = 1;
> +             start = start_orig;
> +             end = &__libhuge_filesz;
> +             goto found;

Hrm... I don' think this is a reasonable use of a goto.  I'd prefer to
see the other logic in an else branch here.


-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel

Reply via email to