Re: Need information about data and bss segment address access in cygwin

[Sudhahar <jsudha80 at gmail dot com>]

Brian,
      From your comments I understand that dll data/bss segment
address is same as that of process data/bss segment
address(data_start, data_end, bss_start and bss_end) when the process
is loaded. Is that right

Sudha



----------------------------
   * From: Brian Dessent <brian at dessent dot net>
    * To: cygwin at cygwin dot com
    * Date: Mon, 23 Jan 2006 22:35:20 -0800
    * Subject: Re: Need information about data and bss segment address
access in cygwin
    * References: <43D0D06C.3010906@hones.org.uk>
<SERRANOIv6EybqfAj810000023c@SERRANO.CAM.ARTIMI.COM>
<46ca01fa0601232209i54db2a6dg159b822e025da446@mail.gmail.com>
    * Reply-to: cygwin at cygwin dot com

Sudhahar wrote:

> Thanks Cliff/Dave. I could not find the code where the dll data/bss
> segments address are updated in cygwin. But in the fork code we are
> doing a copy for all linked and loaded dlls data/bss segments by
> giving the address as

There is no code to update them.  As the other replies have already
said, they act like labels and are established by the linker via the
linker script.  When the program runs, they contain the address, that's
it.  The values in the per_process struct are filled in by the startup
code in _cygwin_crt0_common.cc.

> And also please let me know if there exist any document which gives
> some idea about this.

The 'ld' manual, section 3.5.3.

Brian

On 1/24/06, Sudhahar <jsudha80@gmail.com> wrote:
> Thanks Cliff/Dave. I could not find the code where the dll data/bss
> segments address are updated in cygwin. But in the fork code we are
> doing a copy for all linked and loaded dlls data/bss segments by
> giving the address as
> for (dll *d = dlls.istart (DLL_LINK); d; d = dlls.inext ())
>     {
>       debug_printf ("copying data/bss of a linked dll");
>       if (!fork_copy (pi, "linked dll data/bss", d->p.data_start, d->p.data_end,
>                                                  d->p.bss_start, d->p.bss_end,
>                                                  NULL))
>         goto cleanup;
>     }
> and
>  for (dll *d = dlls.istart (DLL_LOAD); d; d = dlls.inext ())
>         {
>           debug_printf ("copying data/bss for a loaded dll");
>           if (!fork_copy (pi, "loaded dll data/bss", d->p.data_start, d->p.data_end,
>                                                      d->p.bss_start, d->p.bss_end,
>                                                      NULL))
>             goto cleanup;
>         }
>
> And also please let me know if there exist any document which gives
> some idea about this.
>
> Thanks
> Sudha
>
>
> On 1/20/06, Dave Korn <dave.korn@artimi.com> wrote:
> > Cliff Hones wrote:
> > > Sudhahar wrote:
> > >> Thanks Dave your reply answered the question where they declared. But
> > >> how does these variables get the segment address of data and bss for a
> > >> running process to make a copy to the child process? This is the
> > >> questions which is a puzzle to me.
> > >
> > > The linker places these variables at the start and end of the data and
> > > bss segments.  The application can then find the addresses of the segments
> > > by taking the address of the variables (eg &__data_start__).  They aren't
> > > strictly variables in the C sense, inasmuch as trying to read or assign
> > > to them may corrupt your application or cause a segmentation error.
> >
> >   Indeed; they aren't variables at all, they are merely symbols that point to
> > whatever item of code or data happens to be at the start or end of the section
> > concerned.
> >
> >   And the final part of the answer is that the linker also emits relocs
> > against any references to their addresses, which are fixed up by the runtime
> > loader at image-mapping time, and that's how they get the actual final real
> > address at runtime.
> >
> > > Look in winsup/cygwin/lib/_cygwin_crt0_common.cc
> >
> >   Indeed.
> >
> >
> >     cheers,
> >       DaveK
> > --
> > Can't think of a witty .sigline today....
> >
> >
> > --
> > Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> > Problem reports:       http://cygwin.com/problems.html
> > Documentation:         http://cygwin.com/docs.html
> > FAQ:                   http://cygwin.com/faq/
> >
> >
>

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