Searched hist:11392 (Results 1 - 17 of 17) sorted by relevance
| /gem5/src/base/loader/ | ||
| H A D | dtb_object.hh | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | dtb_object.cc | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | ecoff_object.hh | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | aout_object.hh | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | raw_object.hh | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | raw_object.cc | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | aout_object.cc | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | ecoff_object.cc | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | elf_object.hh | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | object_file.hh | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | elf_object.cc | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| /gem5/src/arch/arm/freebsd/ | ||
| H A D | system.cc | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| /gem5/src/arch/sparc/ | ||
| H A D | system.cc | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| /gem5/src/arch/arm/linux/ | ||
| H A D | system.cc | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| /gem5/src/sim/ | ||
| H A D | process.hh | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | syscall_emul.hh | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
| H A D | process.cc | 11392:5967db4cff04 Thu Mar 17 13:34:00 EDT 2016 Brandon Potter <brandon.potter@amd.com> base: add symbol support for dynamic libraries Libraries are loaded into the process address space using the mmap system call. Conveniently, this happens to be a good time to update the process symbol table with the library's incoming symbols so we handle the table update from within the system call. This works just like an application's normal symbols. The only difference between a dynamic library and a main executable is when the symbol table update occurs. The symbol table update for an executable happens at program load time and is finished before the process ever begins executing. Since dynamic linking happens at runtime, the symbol loading happens after the library is first loaded into the process address space. The library binary is examined at this time for a symbol section and that section is parsed for symbol types with specific bindings (global, local, weak). Subsequently, these symbols are added to the table and are available for use by gem5 for things like trace generation. Checkpointing should work just as it did previously. The address space (and therefore the library) will be recorded and the symbol table will be entirely recorded. (It's not possible to do anything clever like checkpoint a program and then load the program back with different libraries with LD_LIBRARY_PATH, because the library becomes part of the address space after being loaded.) |
Completed in 168 milliseconds